A Transport SDK UML Sequence Diagrams

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

This chapter includes the following sections:

A.1 Oracle Service Bus Runtime Inbound Messages

The sequence diagram in Figure A-1 describes the flow of inbound messages through Oracle Service Bus 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 Oracle 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 Oracle Service Bus runtime for processing. The Oracle Service Bus 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 A-1 Inbound Messages at Runtime

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

A.2 Oracle Service Bus Runtime Outbound Messages

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

The Oracle 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 A-2 Outbound Messages at Runtime

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

A.3 Design Time Service Registration

During service registration, a wizard guides you through a number of Oracle Service Bus Administration Console pages. Figure A-3 describes the service registration process. The basic steps include:

  • Specifying the name of the service, the service binding type, and other information.

  • Selecting from a list of transport providers (protocols). The Oracle Service Bus Administration Console calls the transport manager to retrieve an object for each one of these entries in the list and gets a UI binding from each transport provider. This binding answers questions that the Administration Console requests, such as what is or is not supported. This step allows the Administration Console page to be populated with appropriate information.

  • Entering transport-specific information. A transport provider specific form is generated automatically. The transport provider controls the contents of the page.

  • Reviewing a summary page.

Finally, the transport provider is contacted and asked to validate the endpoint configuration and register the new endpoint. The endpoint is only created after activation occurs.

Figure A-3 Service Registration

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