This document covers the following topics:
The EntireX Web Services Wrapper is a wizard that generates and optionally deploys web services (Designer 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 (Designer 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:
Web services are generated from Software AG IDL, XML/SOAP mapping files or Natural subprograms. The generated result is a web service archive (Designer file with extension .aar) that contains the relevant artifacts of the web service such as an XML/SOAP mapping file (Designer file with extension .xmm), WSDL file and additional configuration files, for example services.xml:
See Generating Web Services from Software AG IDL File.
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:
To enable an RPC client - for example a COBOL or Natural client - consuming (or calling) a web service, the generated XML/SOAP mapping file (Designer file with extension .xmm) is used together with RPC Server for XML/SOAP:
See also Developing Web Service Client Applications.
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
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.
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 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.
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
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 Software AG Designer 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.