| As discussed earlier, JAXM can be used by an application and by message providers. Let's first take a look at the different JAXM client types. JAXM Client Types An application that uses JAXM APIs is called a JAXM client. There are two types of JAXM client: those that use a JAXM messaging provider and those that do not. An application that does not use a message provider is typically a standalone J2SE application. It implements only the client view of the JAXM. A JAXM client that does not use a messaging provider establishes a direct connection with the Web service using a URL, sends its request, and then has to wait until it gets a response back from the Web service. Therefore, a standalone client can only send messages synchronously. On the other hand, a JAXM client that uses a messaging provider is capable of both synchronous and asynchronous messaging. Also, when a messaging provider is used, the JAXM client is typically deployed in a container, such as a J2EE Web Container or a J2EE EJB container. A JAXM client maintains a connection with the JAXM message provider, and all messages sent or received by the client are sent through it. The JAXM clients have a peer-to-peer relationship with each other. This implies that, depending on the context, a JAXM client can act either as a server or a client. For example, consider three businesses: Alpha, Gamma, and Delta, all of which are JAXM clients. Alpha creates a purchase order and sends it to Gamma, which is a purchase order validation service. Gamma validates the purchase order and then sends the validated purchase order to Delta, which is a wholesaler. In this example, Alpha acts as a client when it sends the purchase order to Gamma. Gamma, which acts as the server role for Alpha, acts as a client when it sends the validated purchase order to Delta. Therefore, a JAXM client acts as a client whenever it requests a service, and as a server whenever it performs a service. It is important to remember that whether a JAXM client can act as both client and server depends on whether the client is using a JAXM messaging provider. If a client is not using a JAXM messaging provider, it can only send messages synchronously, and therefore act only as a client. On the other hand, a client that uses the JAXM messaging provider can act as both client and server. However, for a JAXM client to act as a server, it needs to adhere to the following requirements: -
A JAXM client must be capable of processing all messages that conform to SOAP 1.1 and SOAP with Attachments specifications. This ensures that even non-JAXM clients can also send requests to a Web service. -
The JAXM client acting as a server must be implemented to handle either request-response or one-way styles of messaging. The handling of request-response messaging ensures that the JAXM client processing the requests can receive and process a request from a standalone JAXM client. Messaging Providers A messaging provider is an application that implements the JAXM to handle the transmission and routing of SOAP messages. A JAXM messaging provider normally works behind the scenes and ensures that the messages are delivered to the appropriate destinations. There are several benefits of using a messaging provider: The following sections explore these benefits in more depth. Transparency A messaging provider works in the background. Therefore, for a JAXM client, it is completely transparent. A JAXM client using a messaging provider just needs to connect to the messaging provider and send it the message. The remaining part of the message delivery process, such as message routing and so on, is done by the messaging provider in conjunction with the other components of the messaging architecture in place for the enterprise. Support for Profiles A messaging provider provides the support for profiles. In fact, a messaging provider can support multiple profiles. However, a client can use only one profile at a time. Always Active A messaging provider is always in a ready state. A JAXM client will connect to the messaging provider, send the message, and close the connection. The messaging provider will store the message and then send it to the intended recipients. If for some reason it fails to send the message, it will try again. The number of resend attempts will depend on the configuration of the message provider. A messaging provider also stores the incoming messages meant for a JAXM client. When a JAXM client reconnects to the messaging provider, the provider forwards the messages to the JAXM client. Finally, the messaging provider generates the necessary error messages whenever required and logs them. Support for Intermediate Destinations A messaging provider provides the capability to route a message to multiple intermediate destinations before going to the final destination. This is achieved through the use of the actor and mustUnderstand attributes in the SOAP header. The value of the actor attribute specifies the intermediate destination. For example, consider a message that is a request for an individual's credit history. The header might route the message to a user validation service, which validates the requesting service as a valid user. The user validation service will then process the message, remove the header information relevant to it, then forward the message to the next actor. The next actor will process the message and pass it on to the next actor. This process will continue until the message reaches the final destination, which is the default actor. Whether an actor needs to process the header depends on the value of the mustUnderstand attribute. If it is set to true, then the specified actor must process the SOAP header. | 
Print 
E-Mail 
Add Note 
Add Bookmark
