EAI with Service Oriented Architecture

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