360 A B2B Solution using WebSphere Business Integration and WebSphere Business Connection
17.1 Developing Web services
We give only a brief overview of development aspects here, covering:
򐂰 General development steps
򐂰 Strategies for the service provider and the service requestor
򐂰 Service life cycle
17.1.1 Development steps
During the build cycle of any project involving Web services, certain steps have
to be performed. Figure 17-1 illustrates them in a pseudo-UML collaboration
Figure 17-1 Web services development and runtime information flow
Tip: For a more comprehensive discussion of the topic, see the document
“Web Services Development Concepts 1.0" from the Web services
development toolkit. It is also available at the following URL:
Chapter 17. Developing Web services 361
Let us walk through the diagram:
򐂰 Service provider side Java development (1)
򐂰 Conversion of existing programming language artifact into WSDL interface
and implementation document (2)
򐂰 Alternatively, you can start with the definition of the WSDL specification (1’)
and generate server side Java from it (2’). We describe the two alternatives in
17.1.2, “Development strategies for provider and requestor” on page 361.
򐂰 Generation of server side SOAP deployment descriptor from WSDL
specification (3)
򐂰 UDDI export and import (4)
Publishing, unpublishing, and update of service registrations in the UDDI
registry (4a)
Finding service interface registrations in the UDDI registry (4b)
򐂰 Generation of client side SOAP stub and optional generation of Web service
test clients (5)
򐂰 Service invocation and execution (6)
Dynamic lookup of service providers in the UDDI registry (provider
dynamic requestor only, see below for definition) (6a)
Service requestor side service invocation (6b)
Transport level communication between requestor and provider (6c)
Service provider side service invocation (6d)
Even if all specifications are human readable (XML), there is a strong need for
tools supporting these development steps— many documents with overlapping
content are involved. It would be cumbersome and error prone to define all these
files without tools.
17.1.2 Development strategies for provider and requestor
Let us next investigate how implementations for the three roles defined in the
SOAP can be developed.
Service provider
A service provider can choose between three different development styles when
defining the WSDL and the Java implementation for his/her Web service:
򐂰 Top down: when following the top down approach, both the server and client
side Java code are developed from an existing WSDL specification.
362 A B2B Solution using WebSphere Business Integration and WebSphere Business Connection
򐂰 Bottom up: if some server-side Java code already exists, the WSDL
specification can be generated from it. The client side Java proxy is still
generated from this WSDL document.
򐂰 Meet in the middle: the meet in the middle (MIM) development style is a
combination of the two previous ones. There are two variants:
MIM variant 1: some serve-side Java code is already there; its interface,
however, it is not fully suited in order to be exposed as a Web service. For
example, the method signatures might contain unsupported data types. A
Java wrapper is developed and used as input to the WSDL generation
tools in use.
MIM variant 2: there is an existing WSDL specification for the problem
domain; however, its operations, parameters, and data types do not fully
match with the envisioned solution architecture. The WSDL is adopted
before server-side Java is generated from it.
In the near future, we expect most real world projects to follow the meet in the
middle approach, with a strong emphasis on its bottom up elements. This is MIM
variant 1, starting from and modifying existing server-side Java and generating
WSDL from it.
When developing the auto parts sample application throughout the following
chapters, we will start with the bottom up approach.
Service requestor
Web service clients (service requestor implementations, that is) have to import
the WSDL interface and implementation specification of the Web service to be
invoked into their environment.
Three types of requestors can be identified. They import interface and
implementation information at different points in time (build time versus runtime):
Static service No public, private or shared UDDI registry is involved; the
service requestor obtains service interface and
implementation description through a proprietary channel
from the service provider (an e-mail, for example), and
stores it into a local configuration file.
Provider-dynamic The service requestor obtains the service interface
specification from a public, private or shared UDDI
registry at build time and generates proxy code for it. The
service implementation document identifying the service
provider is dynamically discovered at runtime (using the
same or another UDDI registry).

Get A B2B Solution using WebSphere Business Integration V4.1 and WebSphere Business Connection V1.1 now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.