Messaging Style XML based messaging

4.2 Messaging Style

Message-style communication is loosely coupled and document-driven rather than being associated with a service-specific interface. When a client invokes a web service using a message-style communication, the client typically sends an entire document, such as a feature filter, rather than a discrete set of parameters. The Web service accepts the entire document, processes it, and may or may not return a result message. Because no tightly- coupled request-response between the client and Web service occurs, message-style Web services promote a looser coupling between client and server. Message-style Web services could support asynchronous communication. A client that invokes the Web service does not wait for a response before it can do something else. The response from the Web service, if any, can appear minutes, hours or days later. A client can either send or receive a document to or from a message-style Web service. In a message-style approach, it is necessary to define a message format, and then compose the message using the format before sending and extracting that data from the message after receiving. The messaging style enables a loose coupling by not being bound to particular methods and arguments. This is a good approach when two different business entities need to communicate by using some industry-standard message schema. Basically the interface of the message style services consists of two operations: send and receive. Messaging Style Support for different protocol bindings CORBA Possible ebXML more generally any EDI protocol Yes HTTP Get Limited cases HTTP Post Yes RMI Possible SOAP document Yes The loosely-coupling in “time and space” conveyed the messaging style has motivated the decision to choose the messaging style instead of the RPC style communication. The messaging is supporting all the requirements described in the introduction. 5 Architectural considerations

5.1 XML based messaging

TO DO: The OGC framework is based on XML because… © OGC 2003 – All rights reserved 5

5.2 Network topology independence