SOA with Java Business Integration (part 2)

Exclusive offer: get 50% off this eBook here
Service Oriented Java Business Integration

Service Oriented Java Business Integration — Save 50%

Enterprise Service Bus integration solutions for Java developers with this SOA book and eBook

$29.99    $15.00
by Binildas A. Christudas | January 2009 | Java Open Source

In Part 1, we saw that JBI is a great enabler for SOA because it defines ESB architecture. It provides for loosely coupled integration by separating out the providers and consumers to mediate through the bus.In this part of the article by Binildas C. A, we will look at the Provider—Consumer Contract and Message Exchange Patterns. We will also consider the different options provided.

(For more resources on this subject, see here.)

Provider—Consumer Contract

In the JBI environment, the provider and consumer always interact based on a services model. A service interface is the common aspect between them. WSDL 1.1 and 2.0 are used to define the contract through the services interface.

The following figure represents the two parts of the WSDL representation of a service:

SOA with Java Business Integration (part 2)

In the Abstract Model, WSDL describes the propagation of a message through a type system. A message has sequence and cardinality specified by its Message Exchange Pattern (MEP). A Message can be a Fault Message also. An MEP is associated with one or more messages using an Operation. An Interface can contain a single Operation or a group of Operations represented in an abstract fashion—independent of wire formats and transport protocols.

An Interface in the Abstract Model is bound to a specific wire format and transport protocol via Binding. A Binding is associated with a network address in an Endpoint and a single Service in the concrete model aggregates multiple Endpoints implementing common interfaces.

Detached Message Exchange

JBI-based message exchange occurs between a Provider and Consumer in a detached fashion. This means, the Provider and Consumer never interact directly. In technical terms, they never share the same thread context of execution. Instead, the Provider and Consumer use JBI NMR as an intermediary. Thus, the Consumer sends a request message to the NMR. The NMR, using intelligent routers decides the best matched service provider and dispatches the message on behalf of the Consumer. The Provider component can be a different component or the same component as the Consumer itself. The Provider can be an SE or a BC and based on the type it will execute the business process by itself or delegate the actual processing to the remotely bound component. The response message is sent back to the NMR by the Provider, and the NMR in turn passes it back to the Consumer. This completes the message exchange.

The following figure represents the JBI-based message exchange:

SOA with Java Business Integration (part 2)

There are multiple patterns by which messages are exchanged, which we will review shortly.

Provider—Consumer Role

Though a JBI component can function as a Consumer, a Provider, or as both a Consumer and Provider, there is clear cut distinction between the Provider and Consumer roles. These roles may be performed by bindings or engines, in any combination of the two. When a binding acts as a service Provider, an external service is implied. Similarly, when the binding acts as a service Consumer, an external Consumer is implied. In the same way, the use of a Service Engines in either role implies a local actor for that role.

This is shown in the following figure:

SOA with Java Business Integration (part 2)

The Provider and Consumer interact with each other through the NMR. When they interact, they perform the distinct responsibilities (not necessarily in the same order).

The following is the list of responsibilities, performed by the Provider and Consumer while interacting with NMR:

  1. Provider: Once deployed, the JBI activates the service provider endpoint.
  2. Provider: Provider then publishes the service description in WSDL format.
  3. Consumer: Consumer then discovers the required service. This can happen at design time (static binding) or run time (dynamic binding).
  4. Consumer: Invokes the queried service.
  5. Provider and Consumer: Send and respond to message exchanges according to the MEP, and state of the message exchange instance.
  6. Provider: Provides the service by responding to the function invocations.
  7. Provider and Consumer: Responds with status (fault or done) to complete the message exchange.

During run-time activation, a service provider activates the actual services it provides, making them known to the NMR. It can now route service invocations to that service.

javax.jbi.component.ComponentContext context ;
// Initialized via. AOP
javax.jbi.messaging.DeliveryChannel channel = context.
getDeliveryChannel();
javax.jbi.servicedesc.ServiceEndpoint serviceEndpoint = null;
if (service != null && endpoint != null)
{
serviceEndpoint = context.activateEndpoint
(service, endpoint);
}

The Provider creates a WSDL described service available through an endpoint. As described in the Provider-Consumer contract, the service implements a WSDL-based interface, which is a collection of operations. The consumer creates a message exchange to send a message to invoke a particular service. Since consumers and providers only share the abstract service definition, they are decoupled from each other. Moreover, several services can implement the same WSDL interface. Hence, if a consumer sends a message for a particular interface, the JBI might find more than one endpoint conforming to the interface and can thus route to the best-fit endpoint.

Message Exchange

A message exchange is the "Message Packet" transferred between a consumer and a provider in a service invocation. It represents a container for normalized messages which are described by an exchange pattern. Thus message exchange encapsulates the following:

  • Normalized message
  • Message exchange metadata
  • Message exchange state

Thus, message exchange is the JBI local portion of a service invocation.

Service Invocation

An end-to-end interaction between a service consumer and a service provider is a service invocation. Service consumers employ one or more service invocation patterns. Service invocation through a JBI infrastructure is based on a 'pull' model, where a component accepts message exchange instances when it is ready. Thus, once a message exchange instance is created, it is sent back and forth between the two participating components, and this continues till the status of the message exchange instance is either set to 'done' or 'error', and sent one last time between the two components.

Message Exchange Patterns (MEP)

Service consumers interact with service providers for message exchange employing one or more service invocation patterns. The MEP defines the names, sequence, and cardinality of messages in an exchange. There are many service invocation patterns, and, from a JBI perspective, any JBI-compliant ESB implementation must support the following four service invocations:

  • One-Way: Service consumer issues a request to the service provider. No error (fault) path is provided.
  • Reliable One-Way: Service consumer issues a request to the service provider. Provider may respond with a fault if it fails to process the request.
  • Request-Response: Service Consumer issues a request to the service provider, with expectation of response. Provider may respond with a fault if it fails to process request.
  • Request Optional-Response: Service consumer issues a request to the service provider, which may result in a response. Both consumer and provider have the option of generating a fault in response to a message received during the interaction.

The above service invocations can be mapped to four different MEPs that are listed as follows.

In-Only MEP

In-Only MEP is used for one-way exchanges. The following figure diagrammatically explains the In-Only MEP:

SOA with Java Business Integration (part 2)

In the In-Only MEP normal scenario, the sequence of operations is as follows:

  • Service Consumer initiates with a message.
  • Service Provider responds with the status to complete the message exchange.

In the In-Only MEP normal scenario, since the Consumer issues a request to the Provider with no error (fault) path, any errors at the Provider-level will not be propagated to the Consumer.

 

 

Service Oriented Java Business Integration Enterprise Service Bus integration solutions for Java developers with this SOA book and eBook
Published: March 2008
eBook Price: $29.99
Book Price: $49.99
See more
Select your format and quantity:

Robust In-Only MEP

Robust In-Only MEP is used for reliable, one-way message exchanges. It has got two usage scenarios—the normal scenario and the fault scenario.

Normal scenario: In the Robust In-Only MEP in the normal (without any fault) scenario, the sequence of message exchanges is similar to that of In-Only MEP. The difference comes to play only in the case where there is an error at the Provider-level, which will be described next.

The following figure explains the Robust In-Only MEP—Normal scenario:

SOA with Java Business Integration (part 2)

In the Robust In-Only MEP—Normal scenario, the sequence of operations is as follows:

  • Service Consumer initiates with a message.
  • Service Provider responds with the status to complete the message exchange.

Fault scenario: In the Robust In-Only MEP in the fault scenario, the Consumer issues a request to the Provider and the Provider will respond with a fault instead of the normal response.

The following figure explains the Robust In-Only MEP—Fault scenario:

SOA with Java Business Integration (part 2)

In the Robust In-Only MEP—Fault scenario, the sequence of operations is as follows:

  • Service Consumer initiates with a message.
  • Service Provider responds with a fault.
  • Service Consumer responds with the status to complete the message exchange.

So, what you need to note is that, in the Robust In-Only MEP—Normal scenario, the exchange is terminated when the Provider responds with status to complete the message exchange, whereas in the Robust In-Only MEP—Fault scenario, the exchange is terminated when the Consumer responds with the status to complete the message exchange. The status to complete the message exchange even in the case of fault scenario, brings robustness to it.

In-Out MEP

In-Out MEP is used for a request-response pair of service invocations. Here the Consumer issues a request to the Provider, with expectation of a response. It has got two usage scenarios—the normal scenario and the fault scenario.

Normal scenario: In the In-Out MEP in the normal (without any fault) scenario, the Consumer issues a request to the Provider, with expectation of a response. The Provider responds with the normal response.

The following figure explains the In-Out MEP—Normal scenario:

SOA with Java Business Integration (part 2)

In the In-Out MEP—Normal scenario, the sequence of operations is as follows:

  • Service Consumer initiates with a message.
  • Service Provider responds with a message.
  • Service Consumer responds with the status to complete the message exchange.

Fault scenario: In the In-Out MEP in the fault scenario, the Consumer issues a request to the Provider with expectation of a response and the Provider will respond with a fault instead of the normal response.

The following figure explains the In-Out MEP—Fault scenario:

SOA with Java Business Integration (part 2)

In the In-Out MEP—Fault scenario, the sequence of operations is as follows:

  • Service Consumer initiates with a message.
  • Service Provider responds with a fault.
  • Service Consumer responds with the status to complete the message exchange.

In-Optional-Out MEP

In the In-Optional-Out MEP, the service Consumer issues a request to the service Provider, which may or may not result in a response. Both the Consumer and the Provider have the option of generating a fault in response to a message received during the interaction.

One-Way: In the In-Optional-Out MEP—One-Way scenario, the service Consumer issues a request to the service Provider. The Provider neither returns any response, nor generates any fault.

The following figure explains the In-Optional-Out MEP—One-Way scenario:

SOA with Java Business Integration (part 2)

In the In-Optional-Out MEP—One-Way scenario, the sequence of operations is as follows:

  • Service Consumer initiates with a message.
  • Service Provider responds with the status to complete the message exchange.

Two-Way: In the In-Optional-Out MEP—Two-Way scenario, the service Consumer issues a request to the service Provider. The Provider then returns a response.

The following figure explains the In-Optional-Out MEP—Two-Way scenario:

SOA with Java Business Integration (part 2)

In the In-Optional-Out MEP—Two-Way scenario, the sequence of operations is as follows:

  • Service Consumer initiates with a message.
  • Service Provider responds with a message.
  • Service Consumer responds with the status to complete the message exchange.

Provider-Fault: In the In-Optional-Out MEP—Provider-Fault scenario, the service Consumer issues a request to the service Provider. The Provider generates a fault instead of the normal response.

The following figure explains the In-Optional-Out MEP—Provider-Fault scenario:

SOA with Java Business Integration (part 2)

In the In-Optional-Out MEP—Provider-Fault scenario, the sequence of operations is as follows:

  • Service Consumer initiates with a message.
  • Service Provider responds with a fault.
  • Service Consumer responds with the status to complete the message exchange.

Consumer-Fault: In the In-Optional-Out MEP—Consumer-Fault scenario, the service Consumer issues a request to the service Provider. The Provider then returns a response. The Consumer generates a fault while accepting the response.

The following figure explains the In-Optional-Out MEP—Consumer-Fault scenario:

SOA with Java Business Integration (part 2)

In the In-Optional-Out MEP—Consumer-Fault scenario, the sequence of operations is as follows:

  • Service Consumer initiates with a message.    
  • Service Provider responds with a message.
  • Service Consumer responds with a fault.
  • Service Provider responds with the status to complete the message exchange.

Where considering a MEP, we always consider the service provider's point of view. Thus, a message targeted towards the provider in an In-Only MEP is the 'In' part of the MEP. On the contrary, if a message is targeted towards the consumer, it is in fact targeted out from the provider, and hence is the 'Out' part of the MEP.

Thus, depending upon the role of the component in the message exchange, the appropriate part or message is created, initialized, and sent to the delivery channel. For an In-Out scenario, the typical steps are as follows:

javax.jbi.messaging.InOut inout = createInOutExchange
(new QName(addressNamespaceURI, addressLocalPart), null, null);
inout.setProperty("correlationId", id);
// set other properties
javax.jbi.messaging.NormalizedMessage nMsg = inout.createMessage();
// nMsg.setProperty(Constants.PROPERTY_SSN_NUMBER, ssnNumber);
// set other properties
inout.setInMessage(nMsg);
send(inout);

ESB—Will it Solve all Our Pain Points

If you are familiar with SOA principles, one subtle fact, which is evident now is that ESB or JBI are not an end by themselves, but a means towards an end (which is SOA). An ESB is not required to build an SOA, nor is JBI required for ESB or SOA. However, all of them have something in common using JBI—we can build standard components to be deployed into ESB architectures. Thus, JBI by itself is one of the ways by which we can attain SOA. There is also a caveat to this—just following JBI or ESB will not guarantee that you attain SOA. Increasingly, you will hear requests from your project stakeholders to implement an ESB without considering SOA as a whole, such that they want immediate solutions. It is technically feasible to build ESB, which act as pipes interconnecting systems, but the success of such ESB architectures without considering the SOA landscape, which it is supposed to be a part of, will be difficult to measure.

Summary

In this 2 part series we saw how JBI is the new integration API introduced in the J2EE world. It is a great enabler for SOA because it defines ESB architecture, which can facilitate the collaboration between services. It provides for loosely coupled integration by separating out the providers and consumers to mediate through the bus.

The NMR provides a common integration channel through which the messages flow. Services are published in the bus using the WSDL standard. Providers and consumers are the different roles taken by the integration components with respect to the bus, when plugged into the JBI bus. Message exchange takes place through different MEPs, each providing different levels of reliability.


Further resources on this subject:


Service Oriented Java Business Integration Enterprise Service Bus integration solutions for Java developers with this SOA book and eBook
Published: March 2008
eBook Price: $29.99
Book Price: $49.99
See more
Select your format and quantity:

About the Author :


Binildas A. Christudas

Binildas C. A. provides Technical Architecture consultancy for IT solutions. He has over 13 years of IT experience, mostly in Microsoft and Sun technologies. Distributed Computing and Service Oriented Integration are his main stream skills, with extensive hands-on experience in Java and C#.NET programming. Binil holds a BTech. degree in Mechanical Engineering from College of Engineering, Trivandrum (www.cet.ac.in) and an MBA in Systems Management, from Institute of Management, Kerala (www.imk.ac.in). A well-known and a highly sought-after thought leader, Binil has designed and built many highly scalable middle-tier and integration solutions for several top-notch clients including Fortune 500 companies. He has been previously employed by multiple IT consulting firms including IBS Software Services (www.ibsplc.com) and Tata Consultancy Services (www.tcs.com) and currently works for Infosys Technologies (www.infosys.com) as a Principal Architect where he heads the J2EE Architects group servicing Communications Service Provider clients.

Binil is a Sun Certified Programmer (SCJP), Developer (SCJD), Business Component Developer (SCBCD) and Enterprise Architect (SCEA), Microsoft Certified Professional (MCP) and Open Group (TOGAF8) Certified Enterprise Architecture Practitioner. He is also a Licensed Zapthink Architect (LZA) in SOA. Besides Technical Architecture Binil also practices Enterprise Architecture.

When not in software, Binil spends time with wife Sowmya & daughter Ann in ‘God's Own Country’, Kerala (www. en.wikipedia.org/wiki/Kerala). Binil does long distance running and is a national medalist in Power Lifting. You may contact Binil at biniljava@yahoo.co.in or binil_christudas@infosys.com.

Books From Packt

Service Oriented Architecture with Java
Service Oriented Architecture with Java

SOA Cookbook
SOA Cookbook

Quickstart Apache Axis2
Quickstart Apache Axis2

Apache JMeter
Apache JMeter

Java EE 5 Development using GlassFish Application Server
Java EE 5 Development using GlassFish Application Server

EJB 3 Developer Guide
EJB 3 Developer Guide

Java EE 5 Development with NetBeans 6
Java EE 5 Development with NetBeans 6

BPEL Cookbook: Best Practices for SOA-based integration and composite applications development
BPEL Cookbook: Best Practices for SOA-based integration and composite applications development

 

 

 

 

Your rating: None Average: 5 (1 vote)

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
L
h
u
2
3
g
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software