[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Asynchronous Web Services Summary
I think key questions to be answered:
I think choosing between WS-this or WS-that is not important at this time - only deciding if asychronous stuff is on.
The most common web service today is request/response, where the SOAP request piggybacks on an HTTP Request and the Response piggybacks on the HTTP response. These are basically synchronous, although to scale, responses are often processed asychronously.
A common asychronous scheme is still request/response, but the response may not be immediate (and therefore not delivered on an HTTP response), A request could be delivered via HTTP POST or SMTP (or BEEP, or whatever protocol you like) message to a service, the service might reply 10 minutes later with an HTTP Post, SMTP message etc. to the sender (or a URI specified by the sender). These can help both clients and servers scale well and have lightweight implementations.
In terms of designing interfaces, the same interface (as specified in WSDL) could be used for either approach, and vendors could choose which to implement. A specification of which protocols are supported for which OBIX interfaces may be warranted (i.e. the discovery service should always be supported through the standard HTTP binding, the historian always through SMTP).
A one-way web service may be useful for some applications (i.e. data push of new information), and might very well be useful in obix (i.e. receiving a message every half hour about the status of something). The configuration of the address data is being sent to may happen out-of-band (i.e. configuring a peice of equipment with a config file or user interface). It is nice and simple for implementors.
The WS-Eventing and WS-Notifications essentially provide subscription interfaces to allow programmatic subscription to one way web services, and provide a filtering mechansim as well, so you can subscribe to only data from the service if it meets various criteria. WS-Notifications provide more advanced features as well, like subscribing to topics and notification brokers. WS-Eventing is very simple. One could create their own interface instead, but there is likely no implementation benefit from rolling ones own.
I don't understand biztalk like systems very well, but I think they primarily work on coordinating one-way messages between several actors according the rules of a process calculus (pi-calculus) expressed in a language like BP4WELS http://www.oasis-open.org/apps/org/workgroup/wsbpel/. This is useful if an process is complicated, requiring the delivery and reception of messages from several sources in order to sucessfully complete. I think coordination activities and whether to use biztalk vs Java or C# to implement such coordination is an implementation issue. We might find BP4WELS or some other process calculus (like UML synchronization diagrams, petri nets etc.) a convenient way to specify such coordination of several asychronous messages.
WS-Reliability and WS-Reliable Messaging provide for guaranteed delivery of messages. An application sends the message and delivery is guaranteed eventually (therefore asychronously). Implementations typically use middleware like MSMQ. I don't know if we can leave whether to implement this to implementors of obix, or if we need to specify when/how they are used and make them optional parts of the spec.
I have not had a chance to investigate OPC.
Doug Ransom
Energy Analytics Domain Expert
Power Measurement
2195 Keating Cross Road
Saanichton, BC, Canada V8M 2A5
Tel: (250) 652-7100 ext. 7558
Fax: (250) 652-0411
E-Mail: mailto:doug.ransom@pwrm.com
Website: http://www.pwrm.com
ION® smart energy everywhere™
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]