[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsdm] MUWS - 2.1.2 Message Exchange Patterns
I have some practical experience in this area. I developed an asynchronous notification solution based on web services using XML/HTTPS (effort pre-dated the SOAP 1.0 standard). The system had a manager sending XML/HTTPS request to an agent which would then return an immediate response that the request was received. At some point in the future the the agent would send an XML/HTTPS request to the manager with the result of the original request. The agent could also send unsolicited notifications to the manager using the same mechanism. This solution requires that both the manager and the agent be able to act as either web service clients or servers. It seems clear that the "management agent" needs to be a web service server to support the simple request/response model and adding the capability to be a web service client does not introduce much more complexity. It also seems the a management system needs to be a web service client to support the simple request/response model. The problem is the making a management system also a web service server will add a lot more complexity and security issues. In reality SOAP/HTTPS is a poor choice for asynchronous messaging. SOAP over a messaging system is a much better fit. But do we want to take on defining two different transport bindings for the first version of WSDM? Jeff Bohren Product Architect OpenNetwork Technologies, Inc -----Original Message----- From: Heather Kreger [mailto:kreger@us.ibm.com] Sent: Wednesday, June 04, 2003 10:54 AM To: wsdm@lists.oasis-open.org Subject: RE: [wsdm] MUWS - 2.1.2 Message Exchange Patterns I think for managing Web Services as resources, we are a bit spoiled, the managed Web service and the management system will both have soap/http stacks and can initiate communication in either direction. For managing the 'random resource', we are wrapping these resources with Web service portTypes, that means that the intercept point for the manageability Web service must 'be a service' and be able to be invoked with a SOAP/HTTP stack. If we want the resources to send asynchronous events (or operations? or belated responses?) to a manager, then it seems we put a requirement on the manager representation to support a Service Provider side SOAP/HTTP stack to catch these invocations/responses. Is this a problem for us? <Chair-hat-off> this seems like a reasonable requirement if the manager wants to use management USING Web services. </Chair-hat-off> Are there additional runtime supports required for sending WS invocations beyond those for receiving invocations? I personally can't think of any Service Provider side stacks that don't support both. This does imply that expected asyncronous messages are described in the receivers portType as an operation. E.g. 'receiveNotification' or 'configurationChangeResponse' Is this a problem for us? Asynch messaging initiated by services to service requesters in general is a problem because not all service requester side SOAP/HTTP stacks are able to deal with invocations. In fact, you must assume that they are not. I may be being a bit simple-minded about this.... Heather Kreger STSM, Web Services Lead Architect for SWG Emerging Technologies Author of "Java and JMX: Building Manageable Systems" kreger@us.ibm.com 919-543-3211 (t/l 441) cell:919-496-9572 "Dan Foody" <dan@actional.com> on 06/04/2003 10:20:38 AM To: "Sanjeev Kumar" <sakumar@attbi.com>, "Geoff Bullen" <geoff.bullen@webmethods.com> cc: "Wsdm (E-mail)" <wsdm@lists.oasis-open.org> Subject: RE: [wsdm] MUWS - 2.1.2 Message Exchange Patterns Hi Sanjeev, Even with keep-alive, I believe HTTP 1.1 is still a request-response protocol (the server cannot send unsolicited messages to the client). So, you can't use an HTTP 1.1 connection for asynchronous traffic. In any case, I don't know of any SOAP stacks that could take advantage of this even if it were allowed behavior. Cheers. -- Daniel M. Foody CTO, Actional Corporation 701 N. Shoreline Blvd. Mountain View, CA 94043 http://www.actional.com > -----Original Message----- > From: Sanjeev Kumar [mailto:sakumar@attbi.com] > Sent: Wednesday, June 04, 2003 12:45 AM > To: Geoff Bullen > Cc: Wsdm (E-mail) > Subject: Re: [wsdm] MUWS - 2.1.2 Message Exchange Patterns > > > > Geoff, relevant points wrt co-existence with firewalls. More details > below. > > Geoff Bullen wrote: > > > > Hi all, > > I remember as part of the discussion on this section it was > suggested > > that if we just specify that we need an asynchronous protocol, then > > you can implement the single request/reply concept on top > of this... > > so therefore you don't need to specify both. It is my > belief that we > > definitely need to specify a direct request/response > protocol. There > > are a number of cases where using firewalls makes it quite > difficult > > to support asynchronous traffic (messages initiated from both > > ends) rather than the simpler request/reply - where > messages are only > > initiated from one end. > > I think, specifically, maintaining a well-known (inbound) port on both > sides and the connection being persistent should make things more > firewall friendly. If we take the case of MUWS, then the inbound ports > used across the firewall on either end are most likely to be 80, and > we can be explicit about being able to work over HTTP1.1 and HTTP1.0 > w/ Conn:Keep-Alive. There is still the issue of initiation of > the connection, which typically should always be done from > inside the firewall. But async messages sent over HTTP should > not have this problem. [Correct me if my assumption is wrong here.] > > > I am not suggesting we should not support async, but I think you > > should be able to create a management solution without it. > > Well, if we are to support async, then we have to address co-existence > with firewalls. Given that the transport for WS is HTTP, we will be at > the mercy of the idiosychracies (sp?) of this protocol wrt > firewall-friendliness regardless of the range of message semantics > (sync, async, req-reply) that we address. > > My $0.02! > Sanjeev K. > > You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgrou p.php You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgrou p.php You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgrou p.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]