58 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
2.3 Key technologies
The architecture discussion up to now has focussed mainly on architectural
issues, patterns, components, services, and processes for creating an EIS
integration architecture.
Of course, any architecture that you create must have a detailed design and
must be implementable. Otherwise, what would be the purpose of creating an
architecture that cannot be implemented?
Some of the discussions in the architecture chapter have mentioned
technologies or specifications, most notably J2C and JMS. You would also have
noticed the architecture chapter suggesting a services-based style of
architecture, commonly referred to as SOA. Of course, SOA is not an
implementation architecture but rather a style of architecture.
You can assert that calling CICS / COBOL routines on your EIS from your
desktop C/C++ application is a services-based architecture. The fact that you
could have used proprietary technologies, such SNA / APPC, and your own
proprietary protocol does not suggest that you do not have a services-based
architecture. Your services (in this example scenario, your CICS / COBOL
routines) might not pass an interoperability test. However, that is another
discussion and technical challenge.
Our architecture discussion mentions a lot of catchy phrases used by software
architects like interoperability, components, loose coupling, adaptability, scalable
flexible on demand solutions, services, and so on. The following sections discuss
some of the key technologies that you can use to implement this architecture.
J2EE
Java 2 Platform, Enterprise Edition (J2EE) is a set of coordinated specifications
and practices that together enable the development, deployment, and
management of multi-tier, server-centric applications. J2EE builds on top of the
Java 2 Platform, Standard Edition (J2SE) platform with additional capabilities
that are necessary to provide a complete, stable, and secure environment for an
enterprise level application.
The J2EE platform provides a reusable component model, using a suite of
technologies, such as Enterprise JavaBeans, JavaServer Pages (JSP), Java
Servlets and so on, to allow application developers to build and deploy multi-tier
J2EE applications that are platform and vendor-independent. The J2EE platform
shares the "Write Once, Run Anywhere" approach of the Java platform and has
gained significant industry support.
Chapter 2. Architecture 59
More information of J2EE can be found at:
http://java.sun.com/j2ee/index.jsp
Web services
The W3C Web Services Architecture Working Group has provided the following
definition for Web services:
A Web service is a software application identified by a URI, whose interfaces
and bindings are capable of being defined, described, and discovered as
XML artifacts. A Web service supports direct interactions with other software
agents using XML-based messages exchanged via Internet-based protocols.
The primary technologies that make up Web services consist of:
???? Extensible Markup Language (XML)
A specification developed by W3C that provides a generic language for
describing content in a structured way to facilitate data interchange between
computer applications.
???? SOAP
A XML-based protocol that is used to facilitate exchange of information in a
decentralized, distributed environment. It is used in combination with a variety
of other standard Internet technologies such as SMTP, HTTP, and FTP.
???? Web Service Description Language (WSDL)
A XML-based language that provides a standardized way of describing the
interface of a Web service.
???? Universal Description, Discovery, and Integration (UDDI)
A worldwide registry of Web services to facilitate advertisement, discovery
and integration.
The following is a list of key characteristics of Web services:
???? Web services are language independent and interoperable.
The core technologies of Web services, such as XML, SOAP, WSDL, and
UDDI , are built using open source projects, promoting vendor independence
and interoperability. In addition, the use of technologies allows the service
provider and service requester to communicate without knowing the platforms
and languages that the other is using. This language and platform
independence in turn facilitates interoperability.
???? Web services are loosely coupled
Traditionally, application design depended on tight interconnections at both
ends. In Web services, a consumer of a Web service is not tied to the service
provider directly. Instead, the service provider can change its interface over
60 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
time without compromising the consumer’s ability to interact with the service.
This results in a loosely coupled system, allowing a more flexible
re-configuration for an integration of the services in question as well as ease
of maintaining software systems.
???? Web services are composable.
Simple Web services can be aggregated to form complex Web services either
through workflow techniques or by invoking lower-layer Web services from a
Web service implementation. This composition is made possible and easier
because Web services are modular, coarse-grained units.
BPEL4WS
BPEL4WS is the notation for Business Process Execution Language for Web
Services (BPEL4WS). It was first specified in July 2002 by BEA, IBM,
Microsoft®, SAP, and Siebel to combine XLANG and WSFL, approaches that
were described previously by Microsoft and IBM respectively. BPEL4WS aims to
provide a language that formally specifies business processes that are based on
Web services, thus extending the Web services interaction model to support
business processes.
At the time of this writing, the latest release of the specification is version 1.1,
which was submitted to the OASIS standards group in May 2003. A copy of the
standard is available at:
http://www.ibm.com/developerworks/webservices/library/ws-bpel/
Support for BPEL4WS at the time of this writing is emerging in some products
and technology previews. IBM provides BPWS4J as a runtime engine for
WebSphere Application Server and Apache Tomcat. The BPWS4J toolkit also
includes a development tool which can be downloaded from:
http://www.alphaworks.ibm.com/tech/bpws4j
JCA
J2EE Connector Architecture (JCA) is part of the J2EE 1.3 specification. It
defines an open, portable standard that allows J2EE applications to access
resources in diverse, heterogeneous EIS systems. These EIS systems include
Enterprise Resource Planning (ERP), mainframe transaction processing
systems (such as IBM CICS), non-relational databases, and legacy applications.
JCA achieves this portability by providing a set of Java interfaces that are
scalable and secure and that provide transactional support.
From the EIS vendors’ perspective, the JCA specification allows an EIS vendor
to provide a standard resource adapter for its EIS. This resource adapter plugs
into an J2EE application server to provide connectivity between the J2EE
application running on the application server and the target EIS systems. So, a
Chapter 2. Architecture 61
JCA-compliant application vendor is assured of seamless connectivity to multiple
systems.
WebSphere Business Integration Adapters
WebSphere Business Integration Adapters facilitate application integration to
different legacy applications, technologies, and mainframe systems through one
consistent approach. These adapters allow heterogeneous business applications
to exchange data over an integration broker such as WebSphere Business
Integration Message Broker or WebSphere Business Integration Server
Foundation.
The WebSphere Business Integration Adapters are built using a common
adapter framework and generally have the following characteristics:
???? Bi-directional
???? Configurable through metadata
???? Reusable infrastructure component
???? Supports multi-threaded business object processing
You can find more information about these characteristics in the IBM redbook,
Patterns: Implementing an SOA Using An Enterprise Service Bus, SG24-6346.
For a complete and current list of WebSphere® Business Integration Adapters,
see:
http://www.ibm.com/software/integration/wbiadapters
JMS
Messaging oriented middleware (MOM) is a popular choice for integrating
applications with existing enterprise information systems. So, MOM vendors
provide application developers with APIs to perform this integration. These APIs
are vendor specific and hence are proprietary. However, while a MOM vendor
may use proprietary message formats and implements its own networking
protocols to exchange messages, the basic semantics of the developer APIs
provided by different MOMs are the same. This similarity in APIs makes the JMS
possible.
JMS is an API for enterprise messaging created by Sun Microsystems. The
purpose is to provide a standard, open and portable way for Java based
applications to access messaging middleware. The use of JMS in EIS integration
is described in a later section.
Business Process Container
The Business Process Container, also known as the Business Process
Choreographer, is a business-process engine in WebSphere Business
Integration Server Foundation. It is used to choreograph all kinds of business
62 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
processes and provides efficient execution of both short-running and
long-running processes.
The business processes that are implemented in an enterprise typically require a
mixture of human and IT resources. The types of business processes can vary
greatly, ranging from Web services navigation to business transaction support.
Business processes can be automatic, recoverable processes or processes that
require human interaction. With Business Process Container, you can combine
business process technology with any other service offered by the open J2EE
architecture.
J2SE
Some of the J2EE purists will probably question why J2SE can be a possible
implementation option, or indeed, why should it even be considered?
Consider for a moment a deployment environment where applications and
business processes execute at a remote branch or retail site to cater for offline
scenarios. Typically, in these kinds of deployment architectures, you find that the
presentation, application, process, and component layers are deployed to every
site. (See Table 2-1 on page 14 for architecture layer descriptions.)
Depending on the number of remote sites (and of course the IT budget of your
organization), you sometimes find that these type of deployment scenarios do
not have a fully compliant J2EE application server processing their applications
at every remote site. Sometimes, you find a lightweight application server with
only a Web container to process Java Servlets or JSP, or you find only J2SE
running in remote sites.
Maintaining and supporting hundreds of application server installations across a
country, or even across the globe, can be very costly and difficult to maintain.
Some remote sites in rural areas might have to support only one to two users,
and if offline processing is important for your business, deploying full
J2EE-compliant application servers to all of these sites might be very expensive,
again, depending your organizations IT budget.
Plain Old Java Objects (POJOs) can be used to implement this architecture. You
do not have to use a J2C connector in a managed environment, nor do you have
to use an application server’s pooling services, and so on. Of course, you would
probably have to develop most of the quality of services (QOS) that an
application server provides to your applications yourself. You would have to
develop services such as connection pooling, transaction management, security,
multi-threaded access, object pooling, and so on by yourself, as well as a
component and execution architecture for your application(s) executing in
remote sites.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.