This topic provides an overview of a typical end-to-end scenario
where the broker implements a Web service.
An existing C or COBOL based system offers
some business logic which can usefully be exposed as a Web service.
The
broker can start the operation on the existing system, that is, the system
exposes an interface to the broker. Typically the existing system would be
enabled for WebSphere MQ, meaning that it receives
MQ messages containing application data, dispatches these to the underlying
implementation and then packages the return values as an MQ response. The
data structures supplied to, and returned by, these existing operations are
defined in a C header file or COBOL copybook.
The Web service offers
an interface based on the operations already exposed by the existing system.
This interface might comprise all of the existing operations, or a subset
of the existing operations or composite operations, or both.
To define
your interface:
- Look at the business function offered by the existing system.
- Select the subset of this business function to be exposed.
- Decide how to represent the subset in the interface, that is, as many
discrete operations, or as fewer multipurpose operations.
You must decide whether you want the Web service interface to
be RPC-style or document-style. For more information about Web services, WSDL
and message flows, and the relationship of WSDL to the Message Model refer
to the related links.
- An RPC-style interface is generally designed to map on to an underlying
set of operations provided by some API, and the individual operations (method
calls) have relatively small payloads.
- A document-style interface might have fewer operations each with a larger
payload, for instance this might be a document representing a loan request.
The WS-I (see
http://www.ws-i.org/)
recommend the use only of document-style WSDL, but many older Web services
use RPC-style.
To implement the scenario: