A B2B Solution using WebSphere Business Integration V4.1 and WebSphere Business Connection V1.1

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

diagram.

.

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:

http://www-3.ibm.com/software/solutions/webservices/pdf/WSDC.pdf

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).