RE: [wsdm] MUWS - 2.1.2 Message Exchange Patterns

["Jeff Bohren" <jbohren@opennetwork.com>]

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