Offering and Purchasing Web Services

Feature Article | November 2, 2004 by admin

A bright future lies ahead for Web services: they are the building blocks of modern software architectures. Each Web service contains a small piece of functionality and exists as a complete software component. They can be used to request a quote from a supplier, to check the availability of an article in a warehouse management system, to find a telephone number, or to place a repeat order. A Web service can be called over an interface. In this manner, other programs can use software components on a Web server. Web services are always reusable and can be combined with other software solutions. They enable industrial manufacturers to make Web services available to customers, partners, and vendors and thus set up comprehensive supply chain solutions.

Roads to Web services

SAP provides a uniform architecture and tools to create, reuse, and modify Web services. The tools include two SAP development environments, SAP NetWeaver Developer Studio and the ABAP development environment, which are respectively geared to the Java and ABAP programming languages. SAP users can thus create Web services without a great deal of effort. Already existing RFCs, IDocs, BAPIs, XI server proxies, EJBs, and Java classes can be used to set up Web services.
Two approaches help create Web services: the Web service creation wizard, which works with a few clicks of the mouse, and a step-by-step approach. Wizards contain predefined profiles with ready-made settings to ensure the security of Web services or the transport protocol in use. The second approach configures a Web service step-by-step from the ground up. Although this approach requires more effort than a wizard, it enables developers to incorporate individual requirements.

Marketplace and registries

Wizard

Wizard

SAP supports the standardization efforts of the World Wide Web Consortium (W3C). W3C is responsible for core technologies in the framework of Web services, particularly data exchange and the description of services with Web Service Description Language (WSDL). WSDL documents can be defined in the XML data format. WSDL consists of the names of services, messages exchanged about their use, links to specific transport protocols, and addresses at which a Web service is available. Users can create and use Web services without ever having seen a WSDL document. Nonetheless, it’s a good idea to be able to read a WSDL document, especially when you want to search for the data transmitted between client and server when you’re trying to correct an error.
In the Web service framework, you can call a Web service home page for every deployed Web service. You can use the Web service home page to test Web services, display WSDL documents of the Web service (see illustration), and generate proxies.

WSDL styles

WSDL styles

When using Web services, you must note the distinction between a service provider and a service requestor. In the simplest case, you can assume that the service provider makes services available, knows the service requestor, and lets the service requestor know where services can be found. But that contradicts the idea of Web service as a global platform of services. What makes the use of Web services attractive is the idea of building applications from globally available Web services. Central directory services exist to offer providers and requestors this comprehensive and global marketplace. The directory services were enabled by the development of the Universal Description Discovery and Integration (UDDI) standard approved by the OASIS standardization agency. UDDI is a basic component of Web services frameworks. Several firms offer public UDDI servers, including SAP (http://uddi.sap.com/), Microsoft (http://uddi.microsoft.com/), and IBM (http://uddi.ibm.com/).
UDDI creates registries comparable to Yellow Pages. UDDI registries contain descriptions of services as WSDL documents enhanced with structured specifications on the provider (with contact information) and the industries and business categories suitable for individual Web services. Web services created in SAP NetWeaver Developer Studio or the ABAP workbench can be published in all registries that meet the UDDI standard.

UDDI

UDDI

In addition to a publicly available UDDI business register, SAP also offers an option to create local UDDI servers at a company. Local servers are geared to making services available to only specific groups of authorized users.

Client proxies implement Web services

The generation of a client proxy is the precondition for the implementation of Web services. Client proxies are generated with the help of the WSDL document of a Web service. Every standard WSDL description can be used as input for proxy generation. WSD documents can be found in UDDI with the help of a URL or HTTP destination or in a local file.
An additional standard, the Web Service Inspection Language (WSIL), attempts to make Web services available on any Web server, without a detour to central UDDI registers. This feature eliminates the need for involved management and maintenance of UDDI directories. Web services described in WSIL are displayed in the Web service navigator of SAP NetWeaver Developer Studio. An application developer can use the navigator to display the home page of a Web service and generate a client proxy.
A client proxy functions as a broker program. The connection to the server of a desired Web service is set up over a client proxy. The developer can focus completely on the business application: the implementation of the proxy takes care of the technical side. That side includes the automatic packaging of calls to a SOAP message or the evaluation of incoming responses.

Logical ports avoid errors

All the objects needed to call a Web service are created during proxy generation. These objects include logical ports, an SAP-specific concept for the configuration of runtime features for Web service client proxies. Runtime features are characteristics that must be configured in the runtime environment when the Web service client is activated. The WSDL description of a Web service also defines a logical port. For example, it contains the URL address from which the service should be called. As a rule, the URL is generated directly in the proxy object.
Consider the following example. Problems can easily occur when the proxy is transported to a system landscape – say from the test system to the production system. The proxy would continue to try to call the Web service on the test server, although it should select the production system. To avoid the problem, the proxy would have to be regenerated or the coding adjusted manually. Because such individual, subsequent improvements are prone to error, the SAP Web service framework separates the configuration data from the implementation. After the transport or redeployment of the proxy, a simple edit can modify the URL and other important parameters.
Enterprise Java beans, Java classes, Java server pages, or a Web Dynpro model can effect a standard call for Web services. Only a few lines of code are required to integrate Web services. ABAP proxies can be placed into the editor of the program that calls them using drag and drop. The required coding can be generated automatically and used directly by the application programmer.

Potential of ESA

ABAP editor

ABAP editor

The use of Web services technology will affect the design of new applications. That’s why SAP developed Enterprise Services Architecture, a service-oriented architecture (SOA) which merges SAP’s enterprise application content with the open SAP NetWeaver platform to enable flexible business processes by SAP, partners, and customers.
The security of Web services remains a hot topic. Currently, the Secure Socket Layer (SSL) protocol guarantees the transport security of Web services. Standard Web services security handles document security. We can expect the development of new standards to improve security and enable companies to use Web services to map their business processes more quickly and flexibly and to tune them to each other. SAP has active representation in agencies involved in the standardization of Web service technology. It does so for two reasons: to bring the experience of SAP into the enterprise environment and because this future-oriented technology will continue to play an important role in software development.

Anne Lanfermann

Anne Lanfermann

Tags: , ,

Leave a Reply