RE: [wsdm] MUWS - 2.1.2 Message Exchange Patterns

[Heather Kreger <kreger@us.ibm.com>]

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_workgroup.php