Web Services Development in WebSphere v5 by Tapas Banerjee CEO, Web Age Solutions Inc.

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.

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

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.

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

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.

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.

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.

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

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

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

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

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

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

The Gateway Administrative Console Open a web browser to http://hostname:port/wsgw/admin/index.html. The hostname is of the server to which you installed the gateway. The port number is the HTTP transport port for that server.

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.

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="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <ns1:findDepartmentByName xmlns:ns1="http://tempuri.org/webservice.ejb.EmployeeDirectory" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <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.

SOAP HTTP Response Example HTTP/1.1 200 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 1994 16: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="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <SOAP-ENV:Body> <ns1:findDepartmentByNameResponse xmlns:ns1="http://tempuri.org/webservice.ejb.EmployeeDirectory" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <return xmlns:ns2="http://bean.webservice/" 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.

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.

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?

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

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.

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

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.

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.

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

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 E-mailing 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

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.

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.

… 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

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.

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 3.2.2 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

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

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