172 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
The two ways can coexist. In general, we have many legacy services and in
many cases one solution is not better than the other. These different ways to
provide the service are transparent to the client, who sees only the service
interface as described by WSDL.
In our integration scenario, we developed three different clients:
???? J2EE Web application
This application can use the legacy service without the SOAP mediation. This
solution does not break the service-oriented architecture, because the legacy
service can be exposed as an enterprise service with bindings such as EJB,
JCA, or JMS. The client can even be deployed on the same application server
that hosts the connector.
???? J2EE client
Although a J2EE client can use the traditional RMI/IIOP protocol, the Web
service approach has some benefits. The SOAP protocol is often easier to
configure with firewalls than IIOP. The service model promotes separation
between the service provider and the consumer. Finally, if you have different
types of clients, it is simpler to run and test one interface.
???? Other SOAP client
In today’s computing environment, almost all programming languages have a
SOAP API. So, we can have access to our EIS virtually everywhere in the
enterprise.
7.3 Service-oriented architecture
To better comprehend Web services technology, we need to understand its place
in the more general service oriented architecture
(SOA). This section describes
the technology stack that supports the SOA. For a detailed description of SOA,
see 7.6, “Further information” on page 195.
Figure 7-3 on page 173 describes briefly the layers of the SOA abstraction.