Introduction to Web Services 1. Introduction 2. Web Services Architectures 3. Implementing Web Services 4. The Java Web Services Developer Pack -JWSDP
1. Introduction Traditional Web Applications -Traditional web-enabled applications are primarily focused on presentation and are unable to interact with other applications.
stock.com Stock broker
news.com Headline News
weather.com Weather reports
-The main reason is that they are built using different web technologies, and their access is limited through an Internet browser or by using an application-specific client.
Web Services Paradigm -Web services introduce a new paradigm for enabling the exchange of information across the Internet using a wide range of computing platforms, based on the use of open Internet standards and technologies. -Web services are self-describing and modular business applications that expose the business logic as services over the Internet through programmable interfaces and using standard internet protocols. -As such they can be defined as “loosely coupled software components delivered over Internet standard technologies”. -Based on XML standards, web services can achieve interoperability of applications based on different programming languages and platforms. -This facilitates the delivery of business applications as a service accessible to anyone, anytime, at any location, and using any platform.
Example Scenario of Web Services
Find services
Travel services registry
Airline reservation system
automobile Register services Service requestor desktop
Rental car reservation system
Invoke services Travel reservation Service provider
PDA organization
Hotel reservation system Credit card Payment system
2. Web Services Architecture Basic Operational Model of Web Services Service broker Discover service
Register service
Service requestor Invoke service
Service provider
-Web services operations involve three distinct roles and relationships: •Service provider: develop, deploy, and publish the web services. •Service broker: responsible for service registration and discovery. •Service requestor: locate, invoke, and execute the web services.
-A typical web service architectural model consists of three logical components as core building blocks:services container, services registry, and services delivery. -The logical components are implemented using de facto web services standards: WSDL, UDDI, and SOAP technologies. Web service broker UDDI registry Discover services & location of WSDL
Service delivery Web service Requester
ebXML Registry/ repository
Invoke services using SOAP/ebXML Messaging
Register services using WSDL
Services container Web service provider
Simple Object Access Protocol (SOAP) -XML-based Messaging protocol for exchanging information between the service provider and service requester. -It consists of the following: •SOAP Envelope: describes the message contents and processing info. •SOAP Transport: defines the binding for the underlying transport protocol such as HTTP and SMTP. •SOAP Encoding: defines a set of encoding rules for mapping the instances of the application-specific data types to XML elements. •SOAP RPC conventions: defines the representation of the RPC requests and responses.
Web Services Description Language (WSDL) -XML schema-based specification for describing Web services as a collection of operations and data input/output parameters as messages. -Defines the communication model with a binding mechanism to attach any transport protocol, data format, or structure to an abstract message or operation. Universal Description, Discovery, and Integration (UDDI) -Defines a mechanism to register and categorize Web services in a registry that users communicate to in order to discover and locate registered services. -A query submitted to the UDDI returns the WSDL description of the service interface. The developer can use this description to construct a SOAP client interface that can communicate with the service provider.
ebXML -Provide a standard framework for building an e-business by enabling the standardization of business processes and profiles, and partner agreements. -Complement other Web services standards such as SOAP, WSDL, and UDDI, in order to provide a reliable framework for e-business tasks. -Major features include the following: •ebXML Messaging service (MS): SOAP plus reliability and security. •ebXML CPP/CPA: WSDL augmented to enable business partner profiles and agreements to be described. •ebXML reg/rep: provides registry and repository (UDDI is just a registry). •ebXML Core components: provide a catalogue of business process components for the business community.
Web Services Communication Models -Web services can be implemented using either RPC-based synchronous or messaging-based asynchronous communication models. RPC-Based Communication Model Request Response Web service requester
Web service provider
-The client invokes the Web services by sending parameter values to the service provider that executes the required methods, and then sends back the return values. -When the client sends a request, the client waits until a response is sent back from the server before continuing any operation.
Messaging-Based Communication Model Message
Web service requester
Web service provider
-Loosely coupled communication model which supports asynchronous messaging. -The client typically sends an entire document to the service provider. The service provider receives and processes the document, and then may or may not return a result.
3. Implementing Web Services General Approach 3.Stores service descriptions as binding templates&URL
4.Locates services and its binding info
Service delivery -SOAP Clients Web Services requester
Web Services Broker
UDDI based Registry Services
2.Register/publish services
5.Invoke & obtain WSDL
6.Exchange data using SOAP RPC/Messaging
Service container -SOAP Interfaces -WSDL Descriptions Web Services Provider
1.Create SOAP proxy interfaces and WSDL based service descriptions
Developing Web Services-Enabled Applications Web Services Requestor Service delivery -SOAP client preferences
Web Services Provider Invoke services
Service runtime environment
SOAP
-SOAP interface classes -XML descriptors -WSDL
J2EE
CORBA Microsoft.NET
- A Web service can be created as a new application or from using an existing application by re-purposing them as services. -In either case, the business components (J2EE, CORBA, .Net) must be encapsulated as service-oriented interfaces using SOAP and exposed as web services by deploying them in a web service container. -The service requestor finds the services through UDDI. To invoke the services exposed by the provider, the requester is required to implement SOAP-based client interfaces according to the WSDL description.
4.The Java Web Services Developer Pack -JWSDP Overview -The combination of Java and XML provides an excellent solution for developing interoperable, portable, and extensible applications: XML is a cross-platform neutral data format and Java is a cross platform programming language. -The integration of both technologies requires the development of parsers and other supporting technologies to process the XML data. The JWSDP proposed by SUN is one such technology. -The core components of JWSDP include the following: •Java XML pack •Apache Tomcat container •JWSDP Registry server •JavaServer Pages Standard Tag libraries •ANT Build tool
Java XML Pack -Consists of a set of high-level APIs and reference implementations that abstract the complexities behind XML processing. The following APIs are available: •Java API for XML Parsing (JAXP) •Java API for XML Registries (JAXR) •Java API for XML-based RPC (JAX-RPC) •SOAP with Attachments API for Java (SAAJ) •Java API for XML Messaging (JAXM)
Java API for XML Processing (JAXP) -Used for the parsing and transformation of XML documents: •Parsing: the process of interpreting the content of a structured XML document ->SAX, DOM •Transformation: consists of applying a template to the XML data in order to produce a document in a desired format->XSLT Simple Access for XML (SAX) API -Event-driven processing model where data elements are interpreted on a sequential basis and events are triggered based on selected constructs. -Since it does not load any XML documents into memory it is very fast and lightweight. <xml> <> >
event input
JAXP Compliant Parser
event event
Default Handler
Document Object Model (DOM) API -Its processing model consists of reading the entire document into memory and building a tree representation of the structured data, which can be used to manipulate the data by inserting, deleting or Document editing elements. <xml> <> >
input
JAXP Compliant Parser
Build DOM
Extensible Stylesheet Language Transformation (XSLT) -eXstensible Stylesheet Language (XSL) is used to describe templates for converting XML documents in desired formats (XML, HTML, PDF, WML etc.). -XSLT is the processor that performs the formatting task. <xml> <> >
html input XSL
JAXP Compliant XSLT Processor
wml pdf
Java Architecture for XML Binding (JAXB) -Provides application developers with a way to generate Java objects based on XML definitions and vice versa, more specifically: •Marshalling: converting a Java object tree into an XML document. •Unmarshalling: converting an XML document into a Java object tree. •Validation:checking an XML document for conformance with a DTD. XML schema
compiling
Java class Java class
Conforms to Instance Of <xml> <> > XML document
marshalling Java Object unmarshalling
Java Object
Java API for XML Messaging (JAXM) -Lightweight XML messaging API for application-to-application (A2A) integration and business-to-business (B2B) communication. Sender Application
Receiver Application
JAXM API
JAXM API
JAXM Messaging Provider HTTP
SOAP message
JAXM Messaging Provider HTTP
Java API for XML Remote Procedure Calls (JAX-RPC) -Set of high-level Java APIs enabling XML-based Java applications to interoperate using RPC. 3. Soap/http request
Application server
1. Lookup service
Client
UDDI
2. Return information
4. Soap/http response
-JAX-RPC runtime -JAX-RPC API -Service endpoint
ANT Build Tool -Build tool similar to make and gnumake, that uses XML for specifying the various tasks that must be executed in the build process. -Provides many defined tasks that can be used by the developer while compiling, building, or deploying the application code.
Developing RPC Web Services with JAX-RPC -JAX-RPC defines an API framework and runtime environment for creating and executing XML-based remote procedure calls. -The Web Service requestors invoke the service provider’s methods and transmit parameters and then receive return values as XML-based requests and responses. -The JAX-RPC-based Web services can be deployed in java servlet 2.2- or the J2EE 1.3-compliant server providers. JAX-RPC-based services and clients are developed and deployed as J2EE components.
JAX-RPC Application Architecture -A typical JAX-RPC application architecture model involves: •JAX-RPC Service: Java business component (e.g. servlet, bean). •JAX-RPC Service client: access exposed Web service. •Serialization/Deserialization:Java-to-XML and XML-to-Java mappings •JAX-RPC Runtime Environment: runtime mechanisms and execution environment for the Web services and service clients. JWSDP Environment
J2SE Environment
WSDL JAX-RPC Client Invocation JAX-RPC-based Service Stubs/Dynamic Proxy/DLL TIES JAX-RPC Runtime
JAX-RPC Runtime Request/Response Soap over HTTP
JAX-RPC-based Service Implementation -JAX-RPC services can be implemented using Java classes (≈ RMI) or by using a WSDL document. Developing a JAX-RPC Service from Java Classes -The key steps include the following: 1. 2. 3. 4. 5.
Define the Remote interface (Service Definition). Implement the remote interface (Service Implementation). Configure the Service. Generate the Stubs and ties. Package and deploy the service.
Developing a JAX-RPC-based Service from a WSDL Document -This consists of developing a JAX-RPC-based service using a WSDL document exposed by an existing Web services environment. -The key steps include the following: 1. 2. 3.
Create a service configuration referring to the WSDL. Generate the client-side stubs and server-side ties. Package and deploy the service.
JAX-RPC Client Implementation -Can be implemented either as stub-based or dynamic proxy-based or dynamic invocation interface based. Stub-based Client -Uses the local stub classes generated by the xrpcc tool. Dynamic Proxy-based Client -Enables the invocation of a target service endpoint dynamically at runtime, without requiring a local stub class. Dynamic Invocation Interface (DII) Client -Enables the client to discover and invoke target services dynamically at runtime. -The client uses a set of operations and parameters, and a search criterion to discover the target service. Hence a client can invoke a service and its methods without knowing its data types.