EAI with Service Oriented Architecture

The SOA approach to doing EAI makes it easy to add, remove, or reconfigure components without actually breaking the process

Wednesday, February 22, 2006

Print

Comment

Email

Digg

Del.icio.us

Reddit

Twitter

The increasing needs of enterprises have always forced technology to evolve. The advent of the OOP had a major impact on how technologies were harnessed. Service Oriented Architecture or SOA holds the torch ensuring that it can meet the demanding business requirements.

SOA is a type of enterprise architecture whose core focuses on the requirements of the enterprise applications. The architectural pattern of the SOA is based on the approach that considers the software components as services over the network. Attempts to propose this approach were made previously by technologies like DCOM and CORBA. However, due to their inherent features, they could never emerge as a standard that can be used across the industry. When implementing these technologies, each end had to be aware of the implementation on the other. This has made the coupling tight, taking away the benefit of the service orientation.

In a stark contrast to these, the SOA relies on its fundamental principles-exposed functionality, document messaging, loose coupling, and platform independence and service autonomy.

The SOA statement states that each application is autonomous and has explicitly defined boundaries. These applications expose their services as a contract. The contract details the information about the service rather than its implementation. For the service to be accessible by any client, the contract should be published in a standard format that can be understood by the client irrespective of its platform or language of implementation. So in effect, the implementation of the service is hidden behind this contract.

XML messaging
XML, being ubiquitous, holds the privilege of exposing this contract. Therefore, a client who understands XML has the capability to consume the service.In effect, SOA rises as a framework, capable enough of consuming the XML to execute well defined sequence of routing, processing and transforming XML messages. Now this can be about integrating the trading partners or two departments in the same organization. It can also be about exposing a credit card validation service or something as plain as processing the order. The nature of the service will be defined by the participants that are involved, different points in the solution that will be actually triggering the workflow and also a with the security requirements for the solution. All these become major deciding factors for the SOA solution.

Developing EAI solutions with SOA
The EAI solutions take care of integrating the various external applications while defining a workflow for their interactions. Integration projects can offer several benefits if they make use of the Service Oriented Architecture. Most importantly, allowing loose coupling of the components in a highly distributed environment. Each application that participates to complete the EAI solution is achieving a certain function that contributes to the entire solution. As we discussed in our previous articles, most of the times, this application is not at all concerned and has very little or absolutely no knowledge about the functionality and implementation of the other applications participating in the integration workflow. This is exactly where the SOA jumps in with its advantages of loose coupling. This makes it quite simple to add, remove or reconfigure the components without actually breaking the process. Another striking attraction about the Service Orientation is the self-descriptive nature of the services. Due to this factor, it becomes very easy for making the services extensible. Extensibility of individual components, thus, participates in theextensibility of the entire solution. With SOA, it can be easily extended to one or more services to create a totally new service that is offering a combined functionality of all its participants.

With the Contract-first approach, the BizTalk Solution design actually starts with defining a contract to interact with the end systems

Moving up the discussion on the similar lines, we will see how this architecture has moved up to support BPM (Business Process Management) and EAI (Enterprise Application Integration) products, specifically aiming at the Microsoft BizTalk Server 2004.

SOA in the BizTalk jigsaw
The BizTalk server 2004 implements the SOA not just as a part of the functionality that is developed, but also as a development approach for anybody who develops solutions with BizTalk. It approaches this in an interesting way – the 'Contract-first' way of development.

As we have seen throughout our previous BizTalk articles that the basic component of any BizTalk process is the message. Whenever BizTalk interacts with any external system, it expects a 'message'. This can be any chunk of data that the external application uses to communicate. The 'pre-processor' components, namely adapters and pipelines convert the data received from the external system to the BizTalk Message. This message in BizTalk is defined with its xml schemas. Effectively, a BizTalk developer needs to first get his schemas in place in order to integrate with any external system. Looking at it from the SOA paradigm, the BizTalk developer actually starts with defining contracts that would simply 'plug' the end systems to the integration.

Apart from the fact that this forces a Service oriented development approach, this also helps in actually creating a very loosely coupled architecture.

Looking at a fully developed BizTalk solution, we observe that the BizTalk Server communicates with each end systems using a rich set of adapters that can adapt to any protocol or system using its customizable adapter framework. This arrangement ensures that any modifications to the existing systems that contribute to the workflow will not impact the actual workflow till the time the end systems follow the contract defined for them.

An example
Let's take a quick glance at how this is possible in the BizTalk paradigm. To begin with, let's put up a scenario wherein our EAI solution integrates an inventory system with other systems forming a complete workflow for Purchase, Sales and Inventory management. Over a period of time, the functionality offered by this inventory system becomes obsolete and the IT decides to change it to its latest version.

As long as the new system respects the contracts that were laid down for the interaction of inventory data, it can easily plug in the existing workflow. A change in mode of communication would simply involve using an appropriate adapter to suite the new system. Due to the loosely coupled model, none of the other participating systems need to be aware of the change. The impact is totally absorbed by the integration solution.

The adapter framework poses as an interesting feature with the BizTalk 2004. It recognizes that even as we move towards service orientation, there are applications that would not understand it. Obviously, this would be a very common scenario in integration solutions. The adapter framework acknowledges this and provides an elegant way to communicate with these systems while still basing the service orientation at its core. This provides a great deal of power and flexibility to the organization allowing it easily to respond to the ever increasing business demands while still carrying on with its legacy applications that it trusts for years.

Web services
.NET Web services are definitely what we can say implementations of the SOA. The Web services, if designed properly, can form an excellent example of service orientation. The BizTalk Server leverages the .Net web services framework to provide its workflows as services over the network.

The server ships with the SOAP Adapter that helps the orchestration not just to invoke the services but also to expose itself as a web service. The web services publishing wizard allows the orchestrations to be easily converted to ASP.Net web services thus allowing their interoperability with other platforms. As a result the BizTalk workflows can be consumed by anybody who understands WSDL. Albeit with some limitations about what can be transformed to a service. Inherently, web services are not that supportive to long running transactions as is the BizTalk orchestration. With BizTalk, a long running transaction can span not just across minutes or hours, but it can be in days, months or even years. 

A new emerging standard-the BPEL-poses as a solution to the issue.

The wizard allows the orchestrations to be easily published to ASP.Net Webservices, increasing the interoperability with other platforms

Is BPEL just another standard?
Well, definitely not. The Business Process Execution Language or BPEL is a standard for expressing the business processes in ubiquitous xml format so that these can be exposed and used across various applications and platforms. What it means to the organization is amazing ease and flexibility with porting the workflows from one platform to the other. BPEL actually defines a language to write workflows that can execute even long running transactions in a service oriented way.

The BPEL (which is sometimes also known as BPELWS or BPEL4WS for its closeness to the web services) is put forth as an industry standard together by Microsoft, BEA & IBM.

The BPEL implementation gives an entry to the pure SOA world wherein the participating applications communicate with exchange of messages. All the functionality in an application or a component is exposed as a set of services that can be consumed by its clients. The BPEL standard takes up the responsibility to build workflows that manage the collaboration between these services. BPEL actually proposes XML based language that can be used to build the workflows. These workflows essentially involve the collaboration between various participating applications. The applications necessarily follow a service oriented pattern wherein all its functionality is exposed as services. The consumer (in this case, the BPEL workflow) would get to know the services from their self-exposed descriptions and hence would be able to actually invoke the services during the workflow execution.

Even though the BPEL does not take care of workflow functions like message mapping and transformations, it allows such functionality to be exposed as additional services, consuming them as any other.

The BizTalk 2004 implements the BPEL standard by enabling BPEL 1.1 complaint processes and converting them to XLANG – Microsoft's proprietary language for defining processes. BizTalk also supports exporting it's orchestrations in the BPEL format. This allows easy sharing of the business process along with the huge advantage of platform independence that comes as a parcel with the BPEL.

Coupled with these advantages is another major benefit that ensures that the long running transactions in BizTalk can be exposed and consumed as a service from other applications just like any other.

The complete picture
The Service Oriented perspective looks at extensibility and scalability of the applications. The applications now no longer remain opaque procedural implementations but they actually reflect the needs of the organization while abstracting all the confusing technicalities.

The BizTalk server 2004 is based firmly on the SOA grounds while keeping in mind the fact that such systems do exist that do not know SOA and that these cannot be overlooked. It leverages the .NET Web services to expose itself so that any WSDL aware client can invoke its workflows.

Overall, the BizTalk Server and its framework turns out to be an active supporter of the SOA. And what's more is that what we have discussed here is just the beginning of the agile business.

Sanket Bakshi, Sr Technical Associate, Mahindra British Telecom