EAI with Service Oriented Architecture

By: Sanket Bakshi,

Sr Technical Associate, Mahindra British Telecom

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.

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.Is BPEL just another standard?

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.

Source:PCQuest