1. Web Services Development in WebSphere v5by
Tapas Banerjee
CEO, Web Age Solutions Inc.

2. What are Web Services?
Applications that can be published, located and invoked programmatically over the Web.
XML-based (XML-in, XML-out).
Self-contained functions that can be used individually to provide services.
Good applications:
Business Information.
Business Integration
Business Process Externalization.

3. Service Oriented Architecture
A service-oriented architecture is created by services communicating with each other
The SOA architecture allows
Different systems and programming languages to talk to each other
Describes the service interface clearly
Allows search for needed services
It’s made up of - service provider, service broker and service requestor
Web Services implement this architecture

4. Web Services Supporting Architecture Standards
Web Services rely on:
XML (eXtensible Markup Language).
UDDI (Universal Description Discovery and Integration).
Publish and discover.
SOAP (Simple Object Access Protocol).
Query UDDI, binding and use of services.
WSDL (Web Services Description Language).
Describe the interfaces of Web Services.
Web Services rely on four essential elements:
Web Services need a language/platform-neutral and structured way to represent business information and interaction. XML provides a framework for describing what a service can do, how it can be invoked, discovering the available service, passing request/parameters for invoking the service, and receiving responses.
UDDI defines the way for businesses to publish and/or discover information about Web Services they provide and/or look for. Service providers register the services to a global UDDI registry by using a WSDL descriptor. The descriptor describes the services, their interfaces, and specifies how to bind to the services to execute them. Customers/clients can search for services in the UDDI registry.
SOAP is an XML-based standard for messaging over HTTP. It is a lightweight protocol using the exchange of information in a decentralized, distributed environment. It is used to query the UDDI registry for Web Services and it enables the binding and usage of the Web Services by defining a message path for routing message.
WSDL is an XML-based open description that describes the interfaces to the Web Services. In order to make a Web Service available, service providers publish a WSDL for a service to a UDDI registry.

5. The Functions and Information Flow
Service Broker
UDDI Registry
2. Assign a unique ID and
populate the registry
This slide shows the flow from registration, to discovery, to use of the service.
A service provider hosts the Web Services. The service provider creates, tests and deploys the service, makes the service available, and describes (using WSDL) and publishes the service to a UDDI registry.
A service broker provides a UDDI registry. The UDDI registry registers and categorizes services, and provides a search service.
Server consumers/requesters use the service broker to discover (through use of the UDDI API) the service they are looking for. The broker will hand out the binding information for the service to the consumer. The binding information tells the consumer how to invoke the service and what to expect in response/return.
The client binds the information and uses the service.
Service Provider
Service Consumer
1. Publish
3. Discover
Web Service
Client
4. Request/Response via SOAP

6. Web Services Programming Model
RPC-based:
Service-specific.
Synchronous model.
Similar to RMI and DCOM.
Message-based:
Document-driven.
Asynchronous model.
The programming model dictates how to implement, assemble, deploy and invoke Web Services. There are two types of Web Services: Remote Procedure Call (RPC) -based and message-based.
The interaction between a client and an RPC-based Web Service centers around a service-specific interface. RPC-based Web Services are synchronous. That is, when a client sends a request, it then waits for a response before doing anything else.
Message-based Web Services are document-driven rather than being associated with a service-specific interface. When a client invokes a message-style Web Service, the client typically sends it an entire document, such as a shipping order, rather than a discrete set of parameters as in an RPC-based model. Message-based Web Services are asynchronous. A client that invokes the Web Service does not then wait for a response before it does anything else.

7. Web Services Programming APIs
APIs for RPC-based Web Services:
Sun’s JAX-RPC (Java API for XML-RPC) in WSDP.
Apache’s SOAP-RPC (Apache SOAP 2.3 ships with WAS5)
APIs for Message-based Web Services:
Sun’s JAXM (Java API for XML Messaging) in WSDP.
Apache’s SOAP-Message.
APIs for publishing and discovering Web Services:
Sun’s JAXR(Java API for XML Registry) in WSDP.
IBM’s UDDI4J.
Web Service APIs are interfaces that consume XML messages. Vendors have implemented APIs based on specifications such as SOAP, WSDL and UDDI. Developers can use these APIs to develop Web Service clients for accessing UDDI registries (for publishing and discovering) and using or binding the Web Services. Some use GUI tools for accessing a UDDI registry. We will give an overview of the APIs here. More details regarding programming Web Services and UDDI clients will be discussed in greater detail later. We will concentrate on Sun’s APIs available in WSDP.

8. JAXR – Java API for XML Registry
Enables Java programs to access XML registries.
JAXR provider:
Accesses XML registry.
A façade to a registry provider.
JAXR client:
A client program that accesses an XML registry using JAXR API.
Perform queries and update UDDI registries.
Sun’s registry browser
Included in WSDP download.
Is a JAXR client with GUI.
Allows to publish and search XML registries.
The client must create a connection with the JAXR provider in order to use a registry. Once connected to the UDDI registry, the client can interact with the UDDI via XML messages or RPC calls.
We will discuss the JAXR API and the Registry Browser in more detail in the UDDI chapter later in this course.

9. Other Web Services Concepts
Several other important Web Services concepts:
Web Services Invocation Framework
Web Services Inspection Language (WS- Inspection)
Workflows
Web Services Gateway
Web Services Security

10. Web Services Invocation Framework
Web Services Invocation Framework (WSIF)
A framework for the simple invocation of Web Services over a Java API.
Allows for maximum flexibility and late (even runtime) binding for clients

11. Web Services Inspection Language (WS Inspection)
A complementary technology to UDDI
A service discovery mechanism
XML-based model for building a list of references to existing Web Service descriptors

12. Workflow and Web Services
A Workflow description allows a process to be described as a sequence of discrete events (e.g. service calls)
A workflow engine can then parse the workflow description and execute the sequence automatically
Defines a business process

13. Workflow Languages There are three web services workflow languages:
Web Services Flow Language (WSFL)
XML-based
Flow Definition Markup Language (FDML)
Similar to WSFL, but with extensions
Business Process Execution Language For Web Services (BPEL4WS)
A meeting of IBM's WSFL and Microsoft's XLANG

14. Web Services Gateway (WSGW)
The WSGW acts as an additional layer between a web service client, and a web service provider
Server side
Allows for better control over web service communication

15. The Gateway Administrative Console
Open a web browser to The hostname is of the server to which you installed the gateway. The port number is the HTTP transport port for that server.

16. Security Needs
Since web services are inherently network based (and typically Internet-based), security is crucial
Additionally, web service communication can be compromised at many levels
At this time, Web Service security still has no formal standards. Much of the material discussed in these sections is based on informal approaches and proposed drafts.

17. SOAP HTTP Request Example
POST /SampleWebServiceWeb/servlet/rpcrouter HTTP/1.0
Host: localhost:9080
Content-Type: text/xml; charset=utf-8
Content-Length: 526
SOAPAction: ""
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV=" xmlns:xsi=" xmlns:xsd="
<SOAP-ENV:Body>
<ns1:findDepartmentByName xmlns:ns1=" SOAP-ENV:encodingStyle="
<departmentName xsi:type="xsd:string">Sales</departmentName>
</ns1:findDepartmentByName>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The payload is in XML – a single <SOAP-ENV:Envelope> element. All the attributes of the <SOAP-ENV:Envelope> are required as shown in the example above. The <SOAP-ENV:Envelope> must contain a single <SOAP-ENV:Body> element, which contains a single element which is the procedure call. The name of the procedure is the name of this element. Note that the procedure name must be a valid XML element name.
The elements contained within the procedure call are the parameters to the procedure. The names of the parameters is significant, the order of the parameters is not. Parameter type is indicated by the xsi:type attribute.
For example, the procedure name could be the name of a file containing a script that executes on an incoming request. It could be the name of a cell in a database table. Or it could be a path to a file contained within a hierarchy of folders and files.
A procedure call may take no parameters. If it takes no parameters, the procedure element must not contain sub-elements.

18. SOAP HTTP Response Example
HTTP/ OK
Server: WebSphere Application Server/5.0
Set-Cookie: JSESSIONID=000050K5KBO5DKK1CC4A2J2VKIY:-1;Path=/
Cache-Control: no-cache="set-cookie,set-cookie2"
Expires: Thu, 01 Dec :00:00 GMT
Content-Type: text/xml; charset=utf-8
Content-Length: 659
Content-Language: en-US
Connection: close
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV=" xmlns:xsi=" xmlns:xsd="
<SOAP-ENV:Body>
<ns1:findDepartmentByNameResponse xmlns:ns1=" SOAP-ENV:encodingStyle="
<return xmlns:ns2=" xsi:type="ns2:Department">
<location xsi:type="xsd:string">Toronto</location>
<name xsi:type="xsd:string">Sales</name>
</return>
</ns1:findDepartmentByNameResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Unless there's an error, return 200 OK.
The content-type is text/xml. Content-length may be specified. If it is specified, it must be correct.
The body of the response is in XML, a single <SOAP-ENV:Envelope> element.
The <SOAP-ENV:Envelope> must contain a single <SOAP-ENV:Body> element, which contains a single element which is the returned value of the procedure.
The single element contained in the <SOAP-ENV:Body> has an arbitrary name which must match the name of the procedure that was called, with the word "Response" tacked on to the end of its name. Let's call this element the wrapper for the response. Even this is not the actual value of the response, which is contained in the single optional sub-element of the wrapper and must be a valid parameter.
The namespace of the wrapper element should match the namespace in the request.
If the wrapper has no sub-elements, then the procedure did not return a value.

19. Different SOAP Implementations
SOAP4J - A Java reference implementation of the SOAP 1.1 specification. It now became the basis of the Apache SOAP 3.x project, also called Axis.
Apache SOAP 2.3
Ships with WebSphere V5
Important elements are
Rpcrouter and messagerouter servlets
The deployment descriptor
Type mapping registry
Rpcrouter and messagerouter servlets intercept requests sent from web services clients who use HTTP.

20. What is WSDL?
WSDL is an XML-based language for defining available Web Services and describing how to access the services, including URL endpoint, message format, encoding and required protocol.
Similar to IDL (Interface Definition Language) for CORBA, describing the services and how to use the services
WSDL 1.1 is the current standard.
Tools available to generate WSDL files.
In the WSDL document, the following information is defined:
What are services.
What are the ports(network endpoints/address) in each service?
What is the protocol binding for each port?
What is the portType (operation/method) in each binding?
What is the operation type(one way, request-response, solicit-response, or notification)?
What are the messages (parameters) for the operation?
What is the data type of the parameter?

21. UDDI Data Structure Five data structure types: businessEntity
businessService
bindingTemplat e
publisherAsserti on
tModel
<publisherAssertion>
Name
description
<businessEntity>
name, contact, identification
description, category
<businessEntity>
name, contact, identification
description, category
<businessService>
(1..n)
name
description
The information model of UDDI registries is defined in XML schema. The XML format is used to describe services in UDDI compliant registries because XML allows cross-platform and language-independent service discovery.
There are five XML data structure types defined for a registration, including business information, service information, binding information, business relationship, and information about specification for services. Each of these XML structures contains a number of data attributes that serve either a business or technical descriptive purpose.
The businessEntity structure contains 1 to n unique businessService structures. Individual businessService structures contain specific instances of bindingTemplate data, which in turn contains information that includes pointers to specific instances of tModel structures.
publisherAssertion allows large companies to represent several businessEntities (such as subsidiaries) that are associated. The relation is published by using the UDDI xxx_publisherAssertion messages to be discussed later in this chapter.
<businessService>
(1..n)
name
description
reference
<bindingTemplate>
<bindingTemplate>
<tModel>
Name
Description
URL pointer
to specification

22. UDDI4J IBM’s UDDI4J is a Java-based UDDI client API.
It provides package/classes for accessing UDDI registry (publishing and discovering).
UDDIProxy object is the client side proxy of the registry.
Program the UDDIProxy for publishing/discovering services.

23. Developing Web Services
Generate deployable web service from
Java Bean
DADX (XML/DB2 mapping documents)
Enterprise Java Bean
URL
Generate skeleton Java Bean and sample application from WSDL document
Web Services Client wizard also creates
Web Service Proxy as Java Bean
Sample JSP-based client application

24. Overall Workflow Typical development path Create a Web Project
Create/Import a resource from which to create a web service (Java Bean, EJB, DADX document, …)
Create a Web Service using Web Service Wizard
Publish a Business Entity, if required
Publish the Web Service
As with any web project, you use the Server tools to manage server instances and configurations. When the server is running, most changes to project resources are picked up without restarting the server.
The web project and any other J2EE projects will belong to a WSAD Enterprise Application Project. When you create a web service, it also becomes part of the Enterprise Application Project and can be deployed as easily as deploying any Enterprise Application. In a typical deployment, only the web service end point needs to be configured differently than in the test environment.

25. Creating a Web Service from a Java Bean
Typical steps:
Create/Import Java Bean into Web Project
Generate binding WSDL document using Web Service Wizard
Deploy Web Service to a Web Server
Generate client proxy
Generate sample client application
Then publish, discover and use web service
The client proxy that WSAD’s Web Services Wizard generates provides access to the web services as RPCs (remote procedure calls). Object marshalling and unmarshalling is doing via XML instead of the standard Java serialization mechanism; therefore parameters do not need to be Serializable.
The generated sample client application is a simple JSP-based test client that looks similar to the Universal Test Client. You can select a method, enter input parameters and see a text representation of the result.

26. … from an EJB Typical steps: … then it’s “business as usual”
Create a Web Project
Create/Import EJBs into an EJB Project belonging to the same Enterprise Application Project as the Web Project
Update project dependencies
… then it’s “business as usual”
WSAD only generates a Web Service from a Stateless Session EJB
… but that session bean can always use entity beans!
Starting with WSAD v4.0.3, class loading within an Enterprise Application has changed and there is no need to explicitly specify the dependency that a Web Project has on the various EJB Projects contained in the same Enterprise Application Project. For WSAD/WAS v4.0, however, you must add the appropriate project references and place the EJB projects in the Web project’s Java Build Path.

27. Web Service Development Phases
Build
May start from Java code, then we generate WSDL from that
Or start from WSDL and build/morph Java code to match
Deployment
We can publish using
UDDI, WSIL or ing customers
Run
Management
Build – Represents the development phase of the web service. Includes requirement gathering, analysis, design, implementation and test.
Deployment – Includes (a) publishing to the UDDI, (b) publishing the WSDL file and (c) deployment in the application server environment
Run – Client finding the web service and invoking it
Management – Day to day overseeing of the web service

28. Different web service creation paths
From an existing application – bottom-up
Most common. We like to expose existing back-end systems for enterprise integration (EAI) purposes.
From WSDL, generate a completely new application – top-down
This may be due to a new spec imposed by a governing body
The wizards can create skeleton code from WSDL, we then fill up the details
Combine independent web services to provide new functionality. This route is similar to the façade design pattern.

29. Different WebSphere products – how do they fare?
There are three products in the WebSphere family that can be used
WSAD
WSAD IE
WebSphere SDK for web services (WSDK) family
All three can do bottom-up and top-down from JavaBeans
WSAD IE and WSDK can do bottom-up and top- down from EJB’s
Regular WSAD cannot do top-down for EJB’s I.e. cannot create EJB’s from WSDL.

30. … from XML schema Generate Java Bean from XML schema
Create any project that works with Java source code (Java, EJB, Web, …)
Create/Import XML schema in the project
Start Web Services Wizard
Select Java beans for XML Schema.
Follow instructions to generate Java Beans
Now generate the Web Service from the new Java Bean

31. WSDK 5.0 WebSphere SDK for Web Services
Entry level developer kit, free for development
But not for production or deployment
Runs on Windows 2000/XP and Linux
Based on Axis (Apache SOAP engine)
Has embedded application server (mini WebSphere 5.0) and a private UDDI registry
Supports SOAP 1.1, WSDL 1.1, UDDI 2.0, JAX_RPC 1.0, WSDL4J, UDDI4J and WS-Security
The UUDI server runs as an EAR file inside the application server.

32. ETTK (previously called WSTK)
IBM Emerging Technologies Toolkit (previously called Web Services toolkit)
An IBM alphaworks technology, showcases technologies to come
Exposes the AXIS programming model
WSTK version includes
WS-C/WS-Tx for transaction flows between components
Web Services matchmaking engine – Businesses submit advertisements. When a customers search matches an advertisement, a response is triggered
WSXL – For better handshaking of web services with portal applications

33. Web Services Deployment in WebSphere
If you are using WSAD 5, it is same as deploying an EAR file
If you are using WSAD 4
Export the Web Service as a WAR
Use AAT to create an EAR
Use soapearenabler.bat to add SOAP services

34. Summary We discussed What are Web Services.
Web Services programming model.
How does a SOAP message look.
Developing Web Services.
Web Service Development Phases.