The following tabs are available:
You can use the default name or replace it with a name of your choice.
Provide information about the adapter service that you want stored in the project. The field is optional.
Select the transport to be used by the run-time adapter, JMS or TIBCO Rendezvous. After selecting the transport, the transport-specific configuration fields display.
The transport can be configured to use a trusted store and identity resource for use in SSL (Secure Sockets Layer) configurations. TIBCO Rendezvous sessions and JMS topics have an SSL configuration field which uses a dialog to perform SSL configuration.
To enable and configure SSL, in the Project
panel, expand the Advanced
folder, then expand the Sessions
folder. Select the TIBCO Rendezvous session or JMS topic and click Use SSL?
. The SSL configuration options are explained in the online help associated with the session dialog. Click the question mark to display the online help.
You can control how the service component of the adapter confirms RVCM, by setting the message confirm behavior. A particular behavior can be selected by setting the messageConfirmBehavior
extended property on an RVCM subscriber, when you are configuring the service instance in the project file.
This property is not available for RV subscribers (since RV messages do not require confirmation) or RV/RVCM RPC Servers (since certified messaging is typically not used in RPC).
Confirm Always
This is the default behavior. The service component of the adapter always confirms the RVCM message, without regard to whether it can instantiate the instance of the COM coclass or what the HRESULT
returned by the method call is.
Confirm on Instantiation
If the service component of the adapter cannot instantiate the instance of the COM coclass, it does not confirm the message. Otherwise, it confirms the message, regardless of the HRESULT
returned by the method call.
Confirm on Success
If the service component of the adapter cannot instantiate the instance of the COM coclass or receives an unsuccessful HRESULT
back from the method call, it does not confirm the message. Otherwise, it confirms the message.
This field displays only if TIBCO Rendezvous
is selected in the Transport Type
field (under the Configuration
tab).
By default a service uses a message subject that is generated using the Domain
and Deployment
global variables, the adapter acronym, the adapter instance name and the service name. If you use this default subject, make sure the values for Domain
and Deployment
are not empty. You can type a TIBCO Rendezvous subject name different from the default in this field. See TIBCO Rendezvous Concepts for information about specifying subject names.
This field displays only if JMS
is selected in the Transport Type
field (under the Configuration
tab).
By default a service uses a dynamic destination that is generated using the Domain
and Deployment
global variables, the adapter acronym, the adapter instance name and the service name. If you use this default dynamic destination, make sure the values for Domain
and Deployment
are not empty. You can override the default dynamic destination by specifying the static destination in this field. The static destination must be defined on the JMS server before it can be used by the run-time adapter. See the TIBCO Enterprise for JMS User’s Guide for information about destinations.
If TIBCO Rendezvous is selected as the transport type, select:
Reliable
Ensures that each multicast or broadcast message is received as long as the physical network and packet recipients are working, and that the loss of a message is detected. This choice can compensate for brief network failures because it can retransmit a message on request if the first attempt failed. This choice is appropriate when message delivery is expected but some loss can be tolerated.
Certified
Guarantees that every certified message reaches its intended recipient in the order sent. The message can be sent across network boundaries, and if a network fails, delivery attempts continue until delivery succeeds or until the message's time limit expires. This is often called certified message delivery.
If certified message delivery is used, data is stored in a ledger file. The size of the ledger depends on several factors, the most important of which is the retention rate of stored data. That is, the ledger grows fastest in response to the cumulative length of undeliverable messages. You must ensure that sufficient disk space is available for the expected size of the ledger.
Distributed Queue
Distributed queue includes a group of cooperating transport objects, each in a separate process. Each transport object is called a member. To balance the transmission load among servers, the adapter can use distributed queues for one-of-n delivery of messages to a group of servers. Each member of a distributed queue listens for the same subject using the TIBCO Rendezvous Distributed Queue listener objects. Even though many members listen for each inbound message (or task), only one member processes the message. For details on distributed queues, see TIBCO Rendezvous Concepts.
Load balancing for the processing of TIBCO Rendezvous certified messages is supported by using distributed queuing. The messages from TIBCO Rendezvous are distributed equally among all instances that belong to the same group. This distributes the message load over several adapter instances. However, the order in which messages are sent to the application is not guaranteed.
Services must use the same wire format to exchange data.
TIBCO Rendezvous Message
(TIBCO Rendezvous only)Control information for validation is not sent in the message. If you use this format, the adapter is compatible with adapters not developed with TIBCO Adapter SDK.
ActiveEnterprise Message
(TIBCO Rendezvous only)Control information for validation is sent in the message. If no control information is included, an exception is returned to the subscriber. ActiveEnterprise standard wire format provides class information and packing rules for the TIBCO Adapter SDK set of data types. This format allows ActiveEnterprise components to perform extra validation on messages sent or received.
See the TIBCO Adapter SDK Programmer’s Guide for details about the control information generated and sent with ActiveEnterprise messages.
XML Message
(TIBCO Rendezvous or JMS)
The XML Message
wire format conforms to specifically constructed and fully compliant XML Schema (XSD) based on the existing definition of the ActiveEnterprise schema.
Queue
(JMS only)A message sent to a queue is consumed by one and only one receiver. Each message has only one receiver though multiple receivers may connect to the queue. The first receiver to access the queue gets the message. The other receivers do not. This messaging model is known as point-to-point.
Topic
(JMS only)A message published to a topic is broadcast to one or more subscribers. All messages published to the topic are received by all services that have subscribed to the topic. This messaging model is known as publish-subscribe.
Non-durable
(JMS only)If a subscription service is marked non-durable, it indicates that messages will not be resent on the configured topic or queue, if the JMS server goes down.
Durable
(JMS only)If a subscription service is marked durable, it indicates that messages need to be resent on the configured topic or queue, if the JMS server goes down.
Messages sent with the persistent delivery mode are always written to persistent storage, except when they are published to a topic that has no durable subscribers. When a topic has no durable subscribers, there are no subscribers that need messages resent in the event of a server failure. Therefore, messages do not need to be saved, and performance is improved because disk I/O is not required.
The semantics for these fields are somewhat more complex than the explanation given here. See the TIBCO Enterprise for JMS User’s Guide for more information.
Every adapter instance can have one or more sessions configured for it. Sessions encapsulate stateful connections to TIBCO Rendezvous and other messaging sources. The session object shown in this field is initially supplied by the adapter, depending on the Quality of Service selected. You can change the session by browsing for it in the project panel.
You can go to the referenced endpoint to edit its properties. Endpoint reference objects are explained in the TIBCO Designer Palette Reference.
This view displays all the operation classes available under the AESchemas
folder. Select an operation class from the list to attach a schema to the service. Attempting to validate the configuration by clicking Project > Validate for Deployment before attaching a schema to the service may result in an error.
Once the schema has been specified for a service, you can view its attributes by selecting the AESchemas
folder in the project panel. You can expand the field names to view the data types and field attributes. For more information about schema, see the TIBCO Designer User’s Guide.
After you have selected a schema in the SchemaView
tab, this field is populated. This field is predefined and cannot be changed.
TIBCO Adapter™ for COM User’s Guide Software Release 5.3, September 2005 Copyright © TIBCO Software Inc. All rights reserved www.tibco.com |