Re: [sca-assembly] SCA event processing principles and WSDL MEPs

[Mike Edwards <mike_edwards@uk.ibm.com>]

Danny,

OK, let's discuss WSDL MEPs, although
I will point out in advance that WSDL isn't the whole story for Web services
and it is interesting to observe that
there are 2 other specifications in the Web services world that have attempted
to
describe Web services models for Event
processing (WS-Eventing and WS-Notification), so that I contend that 
WSDL on its own is by
no means a sufficient description of things.

There are 4 WSDL MEPs (ignoring the
Robust versions described in WSDL 2.0, which only really differ in their
handling of errors):

in-only    or  "one
way"

in-out       or  "request-response"

out-only  or  "notification"

out-in       or  
 "solicit response"

I think that previously, I *did* deal
with the first two - services can clearly work in these tow MEPs with no
problems - and
SCA provides these.  

My question is whether in-only is a
model for Event processing.  I will discuss that in another email,
as promised 
before.

In this email, I'd like to look at the
final two MEPs - out-only and out-in.

These are fine but problematic MEPs.
 They are problematic in that there is an assumption that a service
is
going to send out a message to some
client FIRST, as part of some operation.

Which leads to the obvious question
- how did the service know who to talk with?

SCA already provides ONE answer to this
question, although it does not currently model things using out-only
and out-in MEPs.  I am referring
to the SCA callback functionality.  This is precisely of the out-only
and out-in
form from the service provider point
of view.  The service provider knows who to talk with because in an
SCA
callback context, there MUST be an initiating
forward call from the client, which thus identifies the client (and which
MUST provide a callback address, per
the SCA specs).

This usage is clearly in the context
of a service interaction.  Client makes a forward call and expects
zero or more
callback invocations from the service
provider.

Currently, SCA  does NOT model
the callback operations as out-only and out-in operations on the forward
service
interface.  Instead we chose the
approach of defining a second interface which carries those operations
as
in-only and in-out operations, but with
the "client" acting as provider.  I think that this is probably
an optimal
approach since I am not sure that the
available tooling for common languages provides adequate support for
doing things using out-only and out-in
marking in the WSDL (you are welcome to show that this statement is not
correct).

WS-Eventing and WS-Notification provide
a different context for out-only and out-in processing.  These Event
processing specs involve an initial
subscription of the event consumer to the event producer, which
then 
provides the address of the consumer
for the producer to use when emitting event(s).  The producer (the
service provider in service parlance)
then knows where to send any events is produces.

I note that we have no model in SCA
at present for this type of subscription handling.  Still less do
we have a 
model for the broker capability implied
by WS-Notification which provides for M x N communities of producers
and consumers.  Note that there
is an implication, as there is for a callback, that the client (ie reference)
has
a service interface that is invoked
by the "service" (ie the consumer).

My contention is that the very existence
of the WS-Eventing and WS-Notification specifications indicates that we
are entering a new world once these
forms of Event notification are considered.  I believe that the SCA
model
will need similar extending in order
to deal with the issues raised by this form of interaction.



Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com

Danny van der Rijn <dannyv@tibco.com> wrote
on 09/09/2009 22:59:49:

> [image removed] 
> 
> Re: [sca-assembly] SCA event processing principles
> 
> Danny van der Rijn 
> 
> to:
> 
> Mike Edwards
> 
> 09/09/2009 22:59
> 
> Cc:
> 
> OASIS Assembly
> 
> [Perhaps this stuff was discussed on the call today, but alas, I 
> wasn't able to attend.] 
> 
> I think your reply below glosses over an important point, Mike.  IMO
> the Service world that you describe is about request/response 
> services.  However, the designers of WSDL, in their infinite
wisdom,
> chose to include 3 more MEPs in WSDL 1.1 over 8 years ago.  
> 
> In my mind, the MEP-ness of what you describe (if not the data 
> aspects) are a *subset* of the service world, and not distinct from
> it.  So I believe that it is completely germane to the description.
> 
> I, too, want to start with WSDL and the current Assembly 1.1 and 
> examine why it fails to meet the use cases.
> 
> Danny
> 
<snip>

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU