Chapter 1: Overview of Web Services in EAServer
Using Web services and EAServer, you can take advantage of SOAP, WSDL, and UDDI. These protocols enable you to use third-party components called Web services, which are invoked from application providers. A Web service contained in EAServer can be invoked remotely over HTTP and HTTPS protocols. The Web service object has methods or end points that provide the business logic of the Web service being invoked. Methods are called using SOAP, and the client calling these methods is said to consume the Web service. WSDL describes the service and can be used in client applications. You can also publish business and service information to a UDDI registry site on the Web and make your Web service available to other users. SOAP provides a platform and language-neutral way to access these services.
With SOAP, WSDL, and UDDI, collaboration between business partners is easier because interfaces between applications become standardized across platforms.
Web services can be embedded in Sybase’s Web container environment. Web services supports these standards:
SOAP 1.1 – see “SOAP 1.1”.
WSDL 1.1 – see “WSDL 1.1”.
JAX-RPC 1.0 – see “JAX-RPC 1.0”.
SAAJ 1.1 – see “SAAJ 1.1”.
JAXP 1.1 – see “JAXP 1.1”.
UDDI 2.0 – see “UDDI 2.0”.
As part of the Web services functionality, the Simple Object Access Protocol (SOAP) servlet in EAServer provides you with a way to make your EAServer components accessible to your customers with minimal firewall constraints, platform dependencies, or complex development implementations involving Distributed Component Object Model (DCOM) or Common Object Request Broker Architecture (CORBA).
SOAP allows applications to communicate using existing Internet technologies (such as HTTP, URLs, SSL, and XML) and the HTTP or HTTPS port. While SOAP does not mandate which transfer protocol to use, it is the combination of SOAP and HTTP that allows you to invoke remote procedures, even through firewalls.
See the SOAP information pages for more information.
As communications protocols and message formats are standardized, it becomes increasingly important to describe these communications in some structured way. The Web Services Description Language (WSDL) addresses this need by defining an XML grammar for describing Web services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and for automating the details involved in communication between applications.
When you define a Web service in EAServer, the WSDL file can be automatically generated from the information you provide.
The WSDL document describes a component that you want to make available as a Web service, as well as its location. You can also publish the location of a WSDL document to a UDDI registry on the Web.
The Web services GUI allows you to select a UDDI public host site and login. After you log in, you can add business and service data to the UDDI registry. Once you have published information to the registry, each time you log in, the information is retrieved and available for you to review, modify, or delete.
A business partner can invoke a Web service without knowing how to write SOAP messages by using Web services generated client-side files and artifacts (the collection of files on the client-side that handles communication between a client and a Web service. They include the stub class, service definition interface and additional classes), and the WSDL document that describes your Web service.
See the WSDL information pages for more information.
Sun’s Java API for XML-based Remote Procedure Call (JAX-RPC) is an API for building Web services and clients that use remote procedure calls (RPCs) and XML. It uses technologies defined by the World Wide Web Consortium (W3C): HTTP, SOAP, and WSDL.
Using JAX-RPC, a remote procedure call is represented by an XML-based protocol (SOAP), which defines the structure, rules, and conventions for representing RPCs and responses. These SOAP messages are transmitted over HTTP or HTTPS. The Java API hides the complexity from the application developer, allowing you to focus on creating the Web services that implement business logic, and the client programs that access them.
See the JAX-RPC Web site for more information.
The SOAP with Attachments API for Java 1.1 (SAAJ) protocol enables applications to send and receive document-oriented XML messages using a pure Java API. SAAJ implements SOAP 1.1 so that developers can focus on building, sending, receiving, and decomposing messages for their applications instead of programming low-level XML communications routines.
See the JAXM/SAAJ Web site for more information.
Java API for XML Processing (JAXP) supports processing of XML documents using DOM, SAX, and XSLT. JAXP enables applications to parse and transform XML documents independent of a particular XML processing implementation, giving developers the flexibility to swap between XML processors without making application code changes.
See the JAXP Web site for more information.
The UDDI specification creates a platform-independent, open framework for describing services, discovering businesses, and integrating business services using the Internet. UDDI is a cross-industry effort driven by major platform and software providers, as well as by marketplace operators and e-business leaders.
Using Web services in EAServer, you can publish a WSDL document that describes your Web service and its location to a UDDI registry.
The UDDI protocol is the building block that businesses can use to transact business with each another, using their preferred applications.
The UDDI specification takes advantage of World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) standards, such as eXtensible Markup Language (XML), HTTP, and Domain Name System (DNS) protocols. Additionally, cross-platform programming features are addressed by adopting SOAP.
Web services allows you to publish a WSDL document that describes your Web service and its location to a UDDI registry Web site. A UDDI registry is a sort of yellow pages for businesses, the Web services they offer, and the technical foundations or specifications (called tModels) upon which they are written. You can specify an organization (business name) and description, contact information, and Web service properties for your business. Once your business or tModel is published, potential customers can find it easily from a search. You can publish multiple Web services under the same business name, or create a new business name for different Web services.
Because Web services connect directly to UDDI registry host sites on the Web, you must first be a registered user on the site where you want to publish. To register, go to www.UDDI.org/register.html. The UDDI.org Web site maintains a current list of links to UDDI registry host sites where you can register.
|Copyright © 2005. Sybase Inc. All rights reserved.|