174 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
an so on. All these qualities are discussed in 7.5, “Quality of service for Web
services” on page 180.
The topmost layer in the stack is the
Business Process layer (also known as
Service Orchestration). This layer is implemented using Business Process
Execution Language for Web Services (BPEL4WS0 or BPEL for short. It adds
the capability to compose many services into a workflow to deliver a new
complex business service. Although it is logically positioned as the last layer, it is
independent of the Quality of Service layer. So, we can run a BPEL process even
without security, reliability, coordination, and transaction.
7.4 Using Web services to integrate EIS
This section shows how to make the EIS accessible through the Web services
technology using a build to integrate approach. We used WebSphere Studio
Application Developer Integration Edition to make the EIS accessible with a Web
service interface.
7.4.1 WebSphere Studio Application Developer Integration Edition
WebSphere Studio Application Developer Integration Edition V5.1.1, at its core,
provides easy-to-use tools for creating reusable services out of a variety of
back-end systems and for choreographing the interactions between those
services using BPEL4WS.
WebSphere Studio Application Developer Integration Edition provides a toolbox
for discovering, creating, and publishing Web services that are created from
JavaBeans, DADX files, Enterprise JavaBeans, and URLs. You can also use
Web services tools to create a skeleton JavaBean and a sample application from
a WSDL document.
A Web service can be implemented from:
???? An existing application (bottom-up), transforming an existing application into a
Web service that includes the generation of service wrappers to expose the
business functionality.
???? An existing service definition (top-down), generating a new application
skeleton from a service definition (WSDL).
WebSphere Studio Application Developer Integration Edition extends the Web
service capabilities of WebSphere Studio Application Developer with a more
service-oriented approach.
Chapter 7. Using Web services 175
Business services
At the heart of the Integration Edition programming model are business services,
which are used to consistently model different kinds of service providers.
Services are the business functions of your enterprise, or of your business
partners. You can use the integration tools to develop various types of services,
including Web services, processes, EIS (J2EE Connector) services, JMS
services, and so on. WSDL is used as the model for describing any kind of
service.
Business processes
A business process is a service implementation that represents a part of your
business operations. It can be totally automated or may require human
interaction at certain points. WebSphere Studio Application Developer
Integration Edition provides a model that allows you to implement these
processes in a very efficient graphical way.
The following sections discuss how to expose the developed process as a Web
service, how to invoke a Web service inside the process, and what are the main
related issues.
See 7.6, “Further information” on page 195 for reference information about
WebSphere Studio Application Developer Integration Edition and how to develop
Web services.
7.4.2 Expose the process as a Web service
To expose a process as a Web service is a simple activity. The business process
engine of WebSphere Business Integration Server Foundation is based on the
BPEL4WS language that uses the Web services concept.
BPEL states that any interface from the process and to the external world is a
Web service and is physically described by a WSDL file. As a consequence, you
need to establish only the details of the communication, which is called in Web
services jargon,
defining the binding.
The binding definition for a process is done during the last development phase,
which is
Generate Deploy Code. The deploy wizard of WebSphere Studio
Application Developer Integration Edition shows all the interfaces of the process.
The Interfaces for Partners section contains all the interfaces that the process
exposes to its clients. For each interface (PortType), it is possible to select which
binding to make available. For an example, see Figure 7-4 on page 176.
176 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
Figure 7-4 Generate deploy code wizard: Selecting the bindings
For the SOAP/HTTP binding, it is possible to specify two options:
???? IBM Web Services
???? Apache
The IBM Web Services engine is the newest of these options, and it implements
the latest standard, including JSR 109 and JSR 101. It also it implements an
optimized SOAP parser that makes it outperform many of its competitors. The
Apache option is provided only for backwards compatibility reasons.
As you see in Figure 7-5 on page 177, the wizard shows a tree on the left pane,
and for each interface, it is possible to define the binding details. For the
SOAP/HTTP, you can choose:
???? Document Style: RPC or DOCUMENT
???? Document Use: ENCODED or LITERAL
???? Router Address: the URL where the SOAP listener is available
Chapter 7. Using Web services 177
Figure 7-5 Defining the SOAP style for the process binding
There are four possible combinations of style and encoding, but only the first two
should be used:
???? Document/literal
Provides the best interoperability between Java and non-Java
implementations.
???? RPC/literal
This is a good choice between Java implementations.
???? RPC/encoded
Early Java implementations (WebSphere Version 4 and 5.0) supported this
combination, but it does not provide interoperability. It is no longer supported
by the WS-I Basic Profile, and you should avoid using this option.
???? Document/encoded
Not often used in practice.
Important: If the process interface uses a message with complex types, the
wizard does not permit the Document style to be selected. In this case, you
must use the literal encoding to achieve interoperability with Business Process
Choreographer. In fact, Business Process Container can invoke only Web
services in Document/literal and RPC/literal style Web services.
178 Managing Information Access to an EIS Using J2EE and Services Oriented Architecture
To successfully expose the process via SOAP/HTTP, there are some product
behaviors that the process developer should keep in mind:
???? The SOAP engine does not support a capital letter as the first letter of the
operation name.
???? The SOAP engine does not support operations that use the same message
as input and output.
???? The generator of Web services (WSDL2Java) cannot run if the WSDL imports
files (for example, XSD files) from a different directory than it is in.
This information affects how you implement the business process interface as
defined in a WSDL file.
7.4.3 Invoke a Web service
In a BPEL process, a partner link is a 2-way relationship between the process
and the external partner. In the wizard that is used to Generate Deploy Code,
under the Referenced Partner branch, there are all the outgoing partner links that
are defined inside the process. For each partner link you can also specify the
service that implements that interface as shown in Figure 7-6 on page 179.
Important: By default WebSphere Studio Application Developer Integration
Edition generates a BPEL file that has an interface that violates the first two of
these rules. When you export BPEL files from WebSphere Business
Integration Modeler, they violate the last rule.
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.