Introduction to Web Services in EntireX

This document covers the following topics:


Introduction

The EntireX Web Services Wrapper is a wizard that generates and optionally deploys Web services (EntireX Workbench file with extension .aar) to offer an RPC server - for example a COBOL or Natural RPC server - as a Web service. The generated XML/SOAP mapping file (EntireX Workbench file with extension .xmm) can also be used to enable RPC clients - for example a COBOL or Natural client - consuming (or calling) a Web service. This section covers the following topics:

Generating Web Services

Web services are generated from Software AG IDL, XML/SOAP mapping files or Natural subprograms. The generated result is a Web service archive (Workbench file with extension .aar) that contains the relevant artifacts of the Web service such as an XML/SOAP mapping file (Workbench file with extension .xmm), WSDL file and additional configuration files, for example services.xml:

graphics/webServicesWrapper.png

See Generating Web Services from Software AG IDL File.

Deploying Web Services

The Web service archive is deployed for execution by the wizard or - in an extra deployment step - in a Web Services Stack with the Listener for XML/SOAP running, for example, in an application server:

graphics/intro_intro_deploy.png

See Deploying Web Services.

Consuming (or Calling) Web Services from RPC Clients

To enable an RPC client - for example a COBOL or Natural client - consuming (or calling) a Web service, the generated XML/SOAP mapping file (Workbench file with extension .xmm) is used together with RPC Server for XML/SOAP:

graphics/intro_intro_consume.png

See also Developing Web Service Client Applications.

Supported Features

EntireX supports a number of advanced Web services features in combination with the Web Services Stack. This includes support for

  • SOAP 1.2 according to http://www.w3.org/TR/soap12-part1/ in addition to SOAP 1.1. No extra configuration is needed.

  • SOAP 1.2 messaging

  • SOAP 1.2 binding in WSDL 1.1

  • Multiple transports (HTTP, HTTPS, TCP). See Transports.

  • WSDL 1.1; The generated descriptions are compliant with the Web Services Description Language (WSDL 1.1 - http://www.w3.org/TR/wsdl). They contain both SOAP 1.1 and SOAP 1.2 binding definitions and endpoints. Example (excerpt from a WSDL file):

    ...
    <wsdl:service name="Calc">
      <wsdl:port name="CalcSOAP11port_http" binding="ns0:CalcSOAP11Binding">
        <soap:address location="http://host:port/wsstack/services/Calc" />
      </wsdl:port>
      <wsdl:port name="CalcSOAP12port_http" binding="ns0:CalcSOAP12Binding">
        <soap12:address location="http://host:port/wsstack/services/Calc" />
      </wsdl:port>
    </wsdl:service>
    ...
    
  • WS-I Basic Profile: If the WSDL generation format document/literal is used, the generated Web service is compliant with WS-I Basic Profile 1.1 (see http://www.ws-i.org).

  • WS-Policy (WS-Addressing, WS-Security, WS-ReliableMessaging)

  • WS-Policy Attachment to WSDL 1.1

Web Services

Web services are programmable, distributed application components accessible on the Web using solely standard internet protocols. In contrast to the current "document Web", which specializes in human interaction, Web services are designed to be accessed by programs to form a new application architecture, the "application Web".

Generally speaking, a Web service application consists of three major Web service components:

  • A Web service registry, which stores information about Web service providers and Web services.

  • A Web service client, which makes use of a service offered on the Web using a standard messaging and transport protocol. Web service clients can search Web service registries to find desired services.

  • A Web service, which is accessible via a standard messaging and transport protocol. Web services publish information about themselves in a Web service registry. A Web service must provide a precise technical description of its interfaces to be used by clients.

The standards on which Web services are based today are:

  • HTTP and SMTP for basic network transport services,

  • XML as data format,

  • the Simple Object Access Protocol (SOAP) for XML messaging and RPC,

  • the Web Service Description Language (WSDL) for service descriptions and

  • Universal Description, Discovery and Integration (UDDI) for Web service registries.

The Simple Object Access Protocol (SOAP)

SOAP (originally Simple Object Access Protocol) (SOAP 1.1) is a messaging and RPC protocol designed for integrating heterogeneous Web services in the internet. It defines a message format in the Extensible Markup Language (XML) that can be transported over existing internet transport protocols (HTTP, SMTP, FTP or others). By using standard XML, SOAP messages are self-describing, that is, they carry enough information for a receiver to decompose and process the message in a standard way. By using standard internet protocols, SOAP seamlessly fits into existing internet infrastructure (for example, routers, firewalls, Web servers).

For more details, see the World Wide Web Consortium's note at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.

Web Services Registries and CentraSite

Web services created with EntireX can be registered in any UDDI registry, including CentraSite. CentraSite offers enhanced registry functionality, and also repository functionality that enables you to store Web services artifacts and register interdependencies for impact analysis.

Web Service Architecture

SOAP is one of the basic technologies required to build Web services. It is combined with the related technologies Web services description language (e.g. WSDL) for describing Web services, and Web service registries (e.g. UDDI based) for storing information about Web services.

  • A Web service provider publishes a description of the service it offers to a Web services registry;

  • A Web service client contacts a Web services registry to find the service, and

  • uses the Web service description to actually bind to the Web service.

SOAP can be used for publish, find and bind operations.

The following level of SOAP and Web services functionality is provided:

  • SOAP enabling of EntireX RPC servers

  • generation of WSDL service descriptions for EntireX RPC servers

  • generation, configuration and deployment of Web services into the Software AG Web Services Stack runtime

General SOAP Architecture

EntireX uses the Software AG Web Services Stack. WSS is a toolkit that provides functionality for execution, configuration and management of Web services.

The core part of the WSS runtime is the SOAP engine, which is based on Apache Axis2.

The EntireX Workbench provides functionality to create, configure, and deploy EntireX Web services. EntireX Web services are packaged into a service archive (extension .aar).

Incoming SOAP requests are processed by the WSS SOAP engine. The SOAP request is given to the XML/SOAP Runtime, which validates the request and transforms it into an RPC request. The result of the RPC request in turn is transformed into a SOAP response message and sent back to the client. If an error occurs, a SOAP fault message is sent back to the client.