1.3 Bringing the Pieces Together

1.3.1 Service Requester “Service Provider Relationship

Web Services technology can be described in terms of a Service Requester “Service Provider relationship (refer to Figure 1-1). The Service Provider runs business services from their systems locally and remotely. Business services provided can be found in a Service Registry. In order to register and publish the business service in the Service Registry, the Service Provider defines (authors) service description and configuration information (such as configuration files or WSDL ”Web Services Description Language) and then codes the implementation (Service Implementation). The Service Implementation may be from existing legacy system functionality via Remote Procedure Calls or new applications.

Figure 1-1. Web Services Consumer “Service Provider Relationship

graphics/01fig01.gif

The Service Requester is a consumer of business services. This can be the end- user (as in Business-to-Consumer) or server (as in Business-to-Business scenario). The Service Requester finds the business services from the Service Registry via a Service Proxy (such as an Apache SOAP server). Upon a successful search, the Service Registry, which may be provided by the same Service Provider or by a public Service Registry node, fetches the appropriate service description (for example, WSDL) and returns the service end-points (that is where the business service is located) to the Service Requester. Then the Service Requester can "bind" the business service to the actual service end-point or location.

In summary, the Service Provider uses WSDL to describe the business service and configuration to implement business services. Service descriptions (such as WSDL) are then published in the Service Registry (either UDDI or ebXML).

The Service Provider also uses SOAP technology (such as SOAP Proxy) to wrap existing legacy system functionality as reusable business services. The Service Requester discovers business services dynamically via a SOAP Proxy from the Service Registry, and binds the business services to the actual URI (Universal Resource Identifier) locally or remotely. The business services are encapsulated in XML messages using a SOAP message envelope. This enables easier data manipulation and processing using XML-based products and applications.

1.3.2 Software Tools

Table 1-1 provides a list of the software tools that you will need to work with the examples and labs throughout this book.

Table 1-1. List of Software Tools Used in This Book

Software Tools

Description

Where to Download

Java Web Services Developer Pack

Also known as JWSDP, this is an all-in-one development toolkit with Apache Tomcat 4.1.2, Apache SOAP 2.2, and JAX packs . This is the core component for this book.

http://java.sun.com/ webservices /downloads/webservicespack.html

Axis

New generation Apache SOAP engine. This is a good complementary product to JWSDP, and is essential to run many of the samples in this book.

http://xml.apache.org/axis/index.html

Trust Services Integration Kit

Also known as TSIK, this product provides XKMS and WS-security support. This component is essential to run the Case Study sample programs.

http://www.xmltrustcenter.org/developer/verisign/tsik/download.htm

jSAML Toolkit

A pre-Liberty SAML-based toolkit for implementing Single Sign-on.

You'll need to register to download this tool. Select download from the "Product Downloads" on the left hand column at this Web site.

http://www.netegrity.com/products/index.cfm?leveltwo=JSAML&levelthree=download

SOAP-Lite

This product lets you access SOAP from a Perl client. Requires Perl version 5.0 or above.

This is instrumental to illustrate that we do not require a Java client to invoke Web Services.

http://www.soaplite.com/



J2EE Platform Web Services
J2EE Platform Web Services
ISBN: 0131014021
EAN: 2147483647
Year: 2002
Pages: 127
Authors: Ray Lai

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net