SOA Services

From Geostandards

Contents 1 Features of the services 2 Web services 3 WSDL 4 SOAP 5 Service registers 6 BPEL

Features of the services

Within the Services Oriented Architecture (SOA) context, a difference can be made between the various services offered. The services fall into three layers:

• Technical services
• Business services
• Compounded (process )services

Technical services are characterised by their technical nature and do not offer a direct business related function. They are, in the main, supporting services that are widely applicable. Examples are - a security service that checks which users have consulted specific services or - a service that takes care of the access (security) and permits the invoking of services. Technical services are services that may be regarded as infrastructure components. In the world of geo-information these are, for example, OGC WMS or OGC WFS.

Business services are services which offer functions that business understands and which are immediately applicable. They are often known as a ‘separate function’ within the user applications. An example of a business service is the ‘giveDangerousLocationsbyMunicipality’ service; this provides a map of dangerous locations which is based on a location indication, but it also provides a conversion service that executes a format conversion of geographic information or makes a payment service; these are clearly business services.

Process services are the services which offer a combination (assembly) of several services as a whole. An example, based upon the two services mentioned above, is the service ‘giveDangerousLocationsbyMunicipality in RD (Dutch coordinates reference system)’ as the co-ordinates, are registered in WGS84.

For each type of service and especially for the process services, the ownership of the service and the provided information have to be clear.

Web services

The Web Services architecture is becoming more complex day by day, new specifications are continually being realised in complete new sub areas of web services. For a general understanding of web services the initial plan described in the W3C web services architecture document is more than adequate. In this document the three functions below are mentioned:

• Exchange of messages
• Description of services and messages
• Publishing and finding of described Web Services

To realize these three functions, technical standards (WSDL, SOAP and UDDI) have been developed which are elaborated below.

As well as the listed parts, the components within the architecture of Web Services also contain aspects from the fields of the management and security of the services. The Web Services specifications which ensure the reliable traffic of messages – with important facilities such as 'guaranteed arrival of messages’ - are under development. These concern a cohesive whole of a number of specifications. In the (SOA) practise a dichotomy can be noted in technology families. ebXML is the family of standards that is mostly selected.

The interaction of, and between, services (see figure below) in a Web Services environment, uses the architectural components and standards mentioned above. UDDI is the technical standard that offers a register in order to register and search services. The [(WSDL standard is used to define and record Web Services. The SOAP layer is used as a communication standardisation layer.

 

WSDL

The use of services by others and, therefore, the use of Web Services too, fails or succeeds with the request and offer. It is just the same as it is for a normal businesses; finding a client for the services and products that are offered. Within the playing field of Web Services, the basis for this is created by Web Services Definition Language (WSDL), a language which can describe the services offered. This description contains not just the technical and functional information, but the business oriented information as well. The present form of WSDL focuses mainly on the technical and functional area. Making recommendations and clearly positioning a target group of a specific Web Service as a kind of commercial for the service, is not yet provided for WSDL.

WSDL uses XML to describe the messages that are exchanged between the offering party and the requesting party. The messages themselves are then linked to a network protocol and message format. The WSDL structure can best be described as a set of components which each describe a part of the Web Services layer and together form a definition. The definitions of messages don’t go any further than just describing the parameters and the results that a specific function needs or provides. Each message has a name which enables the giving of a unique identity within the WSDL to be possible.

The layers described are:

• Messages - Individual definitions of messages characterised by a name and parameter or results that the message expects or provides.
• Port types - Compounds the individual message definitions into a function consisting of an input and output message.
• Type definitions - Offers the possibility of adding specific externally defined datatypes to the WSDL definition.
• Element descriptions - Offers the possibility of adding specific external structures to the WSDL definition. This way a WSDL can be built up in a modular way by importing external XML scheme definitions.
• Connections - Describes the concrete linkage of a port type and the functions that are linked to it in a specific format of messages and transmission protocol.
• Services <span id="fck_dom_range_temp_1261490743048_202" /><span id="fck_dom_range_temp_1261490743048_71" />- Describes which port types the service provides and how this communication service is offered.

SOAP

Simple Object Access Protocol (SOAP) has been developed in order to standardise and simplify the exchange of information in distributed environments. SOAP, therefore, can be favourably compared to component standards such as the Component Object Model (COM) and CORBA standards which already exist. However it is a protocol that uses XML to describe the message format. It also uses HTTP, the default internet communication protocol, to send messages between systems.

SOAP was initially developed by Microsoft to make data exchange possible via internet standards. The intention was to develop a new, open and XML based standard and to leave proprietary DCOM behind. After some initial scepticism because of the assumed Microsoft marketing ideology behind SOAP, IBM now also supports the standard. Both companies and a few others have offered the SOAP specification to the World Wide Web Consortium (W3C) as standardisation.

SOAP is an RPC like (Remote Procedure Call) mechanism: a question is asked and the answer is immediately forthcoming, and then the connection is closed. SOAP offers access to a function in a standard way. It can best be regarded, therefore, as a shell put around a developed function. Implementing the function, or the code, ensures that the invoked service does what it has to do. A function such as this can be either a new or an existing function, legacy systems provided with a wrapper, therefore, can be approached using SOAP messages. The information that is needed to invoke the function and the result that comes back from the function is placed into an XML structure, the so-called SOAP message. The SOAP shell is generic and can be used to link all types of components.

The SOAP structure

SOAP-based communication can be compared with the usual sort of mail traffic that a letter is written for. There is an envelope, which has the address of the destination on it and in the envelope is the letter with the header indicating the official destination and details of whom the letter is addressed to; it also contains the date and the beginning of the letter. The other part of the letter is the message that has to be transmitted. We also see these three parts in a SOAP message:

• The envelope is the external part of the message indicating the destination. The envelope must be there;
• The header could be there and is used to give further route details of the destination;
• The body contains the factual message and must be there. The body is used to mention mistakes that might have occurred in an answer.

Service registers

In order to make re-use possible and to stimulate the use of it within a service oriented architectural context, it is necessary for the offered services to be easily registered and found. So-called service registers are used for this; a digital ‘yellow pages’. In the geographical world an interface which OGC developed itself CSW is mainly used, while in service oriented architecture and the Web Services environment, UDDI or ebRIM are used (which is supported in a CSW application profile too).

In fact, it does not make any difference which type of register is used. It is even possible to set up a register based upon a standard file system, to have it indexed and to make it available by way of a search engine, such as Google. Apart from technical content, the function that the registers have to offer is important, but it is even more important that a register reaches a clear description of a service.

An example could involve someone who offers a service for ordering coffee. If there is no information offered about what service is provided, this could lead to surprising results. When someone thinks he is just ordering a cup of coffee he could get a complete shipload!

When the service is described clearly in the right context, then the search and selecting mechanism don’t matter anymore. In this way it becomes possible to start small, with a website made up of HTML pages which describe the services. At a later stage the service descriptions can be organised in a register.

BPEL

Web services is regarded as the technical standard through which service oriented architecture can be realised. Web services is an open standard that can be created and applied in each software development environment and technique, independent of the fact that it is a Microsoft, SAP, Cobol or Java environment. An interesting increase of Web services is the addition of a specific part to define, model and manage processes.

This addition Business Process Execution Language (BPEL) defines a standard language for the modelling of processes which is also called orchestration. Providers of workflow and BPM solutions deliver applications that interpret this BPEL language and execute the modelled processes. This makes it possible to model processes and to exchange them with others, independent of the requirements of specific Software installations.

A BPEL process is made up of one or several services, and can also be invoked itself as a service.

← previous

SOA Services

next →