E Transport SDK UML Sequence Diagrams

This appendix contains UML sequence diagrams that describe the flow of method calls through the Service Bus runtime.

This appendix includes the following sections:

E.1 Service Bus Runtime Inbound Messages

The sequence diagram in Figure E-1 describes the flow of inbound messages through Service Bus at runtime.

First, an inbound artifact, such as an HTTP Servlet, intercepts a client request. The transport provider creates a data structure called InboundTransportMessageContext. The message context packages headers from the request into a metadata object, converting the payload from an HTTP stream into a specific Service Bus source object. The transport provider calls the transport manager to receive the message. The transport manager preprocesses the message and passes the message to the Service Bus runtime for processing. The runtime asks for the message context's service, service version, and other information. It also asks about the metadata and payload, which are required for processing. The runtime asks the MessageContext to create the response metadata and the response payload, and then calls close(). The response is sent back to the client.

Figure E-1 Inbound Messages at Runtime

Description of Figure E-1 follows
Description of "Figure E-1 Inbound Messages at Runtime"

E.2 Service Bus Runtime Outbound Messages

The sequence diagram shown in Figure E-2 describes the flow of outbound messages through the Service Bus runtime.

The Service Bus runtime routes the message to an external service. The transport provider creates metadata for the request and creates a TransportSender object, which includes information about the payload and quality of service and retry information. Next, the provider calls TransportManager (the central hub for the transport subsystem) to send the message asynchronously. TransportManager calls the transport provider to send the message. The transport provider creates an OutboundTransportMessageContext. The transport provider then asks about the metadata and payload and other information and takes appropriate action. For example, for a JMS message, the transport provider uses the JMS API to populate the headers and the payload and calls the protocol-specific send operation.

When a response comes in, the transport provider calls the TransportSendListener object. Eventually the transport manager invokes the response pipeline. After pipeline actions are executed, the outbound endpoint is closed.

Figure E-2 Outbound Messages at Runtime

Description of Figure E-2 follows
Description of "Figure E-2 Outbound Messages at Runtime"

E.3 Design Time Service Registration

When you create a service, a wizard guides you through a number of Oracle Service Bus Console pages. When you select a transport type, the Oracle Service Bus Console calls the transport manager to retrieve an object for each one of these entries in the list and gets a binding from each transport provider. This binding answers questions requested by the console, such as what is or is not supported. This step allows the console page to be populated with appropriate information. Figure E-3 describes the service creation process. Below are the basic steps for a transport-based service:

  1. Specify the name of the service.
  2. Select from a list of transport providers (protocols).
  3. Select and optionally configure the service type.
  4. Create the service.
  5. Review the configuration and save any changes you make. If you created a proxy service, you must specify a target service, which can be a pipeline or another proxy service.

Figure E-3 Service Registration

Description of Figure E-3 follows
Description of "Figure E-3 Service Registration "