Chapter 7. Using Web services 169
7.2 Web services for EIS integration
In general Web services are appreciated for the following reasons:
???? Interoperability
Any Web service can interact with any other Web service. Thanks to SOAP,
the new standard protocol supported by all of the major vendors (and most of
the minor ones too), the difficulties of converting between CORBA, DCOM,
and other protocols should be over. Because Web services can be written in
any language, developers do not need to change their development
environments to produce or to use Web services.
???? Ubiquity
Web services communicate using HTTP and XML. Therefore, any device
which supports these technologies can both host and access Web services.
Soon, Web services will be present in phones, cars, and even soda
machines. If the soda supplies are getting low, then soda machine can
contact the local supplier's Web service via a wireless network and can order
what it needs.
???? Low barrier to entry
The concepts behind Web services are easy to understand. Many vendors
such as IBM and Microsoft offer tools that allow developers to quickly create
and deploy Web services. In addition, some of these tools allow pre-existing
COM components and JavaBeans to be easily exposed as Web services.
???? Industry support
All of the major vendors are supporting SOAP and the surrounding Web
services technology. For example, WebSphere Application Server supports
these technologies inside the J2EE architecture, and the Microsoft.NET
platform supports all the proprietary Microsoft languages.
The following sections explain why Web services are ready for an extensive
deployment in scenarios that integrate business partners and that expose
existing enterprise information systems (EIS).
7.2.1 Integrate business partners
A current business and technology challenge is to accelerate inter-company
communication to gain more reactive business. Web services provide a low cost
technology to realize this kind of need. When a new technology is introduced in
the business activity, it is important for technology to offer a strong quality of
service.
170 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
In the scenario (described in Chapter 3, “Scenario overview and design” on
page 65), we introduced Web services technology because the relationship
between the bank and the stock analyst firm is changeable partnership and
cannot justify the implementation of a private communication infrastructure. The
bank wants to provide a new service which prevents its customers from buying
stocks that fluctuate wildly in value. To give impartial advice, the bank relies on
an external information service that is provided by a specialized stock analyst
firm.
As in our scenario, there are several situations that have similar conditions and
requirements:
???? The business does not justify a private network.
???? There is a need to exchange information with a remote partner.
???? The service request does not have a side effect on the remote system (basic
inquiry).
???? The service request triggers a remote transaction; however, that transaction
can be isolated by a local one.
???? There is a need for quick implementation.
Web services technology can provide answers to each of these requirements.
7.2.2 Expose the EIS
In almost all organizations, it is common to find a great variety of software
platforms provided by different software vendors. In addition to mainframe
solutions, there are many vertical solutions for ERP, eCommerce, Office
Automation, CRM, and so on. There is also horizontal application technology for
client and server computing such as J2EE application servers and Microsoft.Net.
Niche technology (for example PHP, Perl, Python, and Borland Delphi) can also
be used.
To make this different software work together, there are two options:
???? Create an ad-hoc point-to-point translator.
???? Modify all the components to speak a common language.
The first option leads potentially to the implementation of (n-1)! translator. The
second option, in the worst case, leads to the implementation of n translator. In
the recent years, many software vendors have provided Web services
implementation. The choice to use the Web services as a common language is
one of the least expensive and most viable options.
Many legacy EIS solution do not offer Web services interfaces, or if they do offer
an interface, it often lacks in terms of features. So, we suggest that you wrap
Chapter 7. Using Web services 171
legacy systems with business integration middleware. The business integration
middleware can interact with the legacy system through a native protocol and
can expose selected services through Web service paradigms.
The benefits of this type of solution are that is:
???? Exposes only a subset of services.
???? Lets the Web services platform evolve smoothly — detached from the legacy
system.
???? Adds another layer and increases the EIS isolation, giving you more control of
security constraints.
Legacy interfaces are often unsuited to be used by new applications. So, it is a
good idea to wrap these interfaces with a logic that transforms and aggregates
the information.
Figure 7-2 outlines a possible architecture that exposes the EIS with a Web
services interface. In addition to the EIS, there is an adapter for the protocol
translation.
Figure 7-2 Exposing the EIS with a Web services interface
We can expose the EIS is two ways:
???? SOAP enabler
The back-end service is exposed as is. This option needs only a configuration
task.
???? Business Process Choreographer
The back-end service is adapted to the new needs. Here, we have a
re-engineering task to develop a process that exposes a new interface. This
process can handle data transformation and compose some legacy services
to give a more complete service.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.