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