[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
Mike Edwards wrote:
OFE21F2424.50DB9F7D-ON80257626.002E55F5-80257626.002FAEEB@uk.ibm.com"
type="cite">
Jim,
I think that in broad outline we
agree,
which I think is important.
Several of your points are of the
flavour
"but that event processing function can be done with one-way service
operations",
which I think is not germane to a
description
of Service interactions and Event interactions - in fact THAT is the
next
step in
the debate, which I will turn to in
my next email.
Some detailed comments inline.
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
Jim Marino <jim.marino@gmail.com> wrote on
02/09/2009
15:35:48:
> Re: [sca-assembly] SCA event processing principles
>
> Jim Marino
>
> to: Mike Edwards
>
> 02/09/2009 15:36
>
> Cc: OASIS Assembly
>
> Thanks Mike, this is a nice explanation.
>
> As I detail inline, I think many of the distinctions between
> "eventing" and "services" (especially when the
latter are loosely
> coupled) you are making can be argued aren't really distinctions,
> except one...
>
> You stated, "There is no concept of an 'interface', either for
a
> producer or for a consumer" which started me thinking about a
subtle
> difference. I agree that there is no concept of a service contract
> shared between producer and consumer. However,
>
> 1. There is a data contract at least between the producer and the
> infrastructure and the consumer and the infrastructure. One could
> potentially argue that the data contract exists between producer
and
> consumer as well.
I am not sure what you mean by a "data contract".
That an event has form and content is about the
only
thing that there is.
If that is what you mean by "contract" then
ok, but if you mean something
more, I'd appreciate an explanation.
> 2. There must be a contract between the
producer
and the
> infrastructure and the consumer and the infrastructure
What kind of contract? That the infrastructure
will convey the events
from one place to another? Or do you mean
something
more concrete and
tangible? If so, please explain.
>
> Thinking about this further, another question to ask is, "are
> consumers addressable"?
Now, what do you mean by this?
Do you mean "a producer can send an event to
a specific consumer, by the address
of the consumer".
The OSOA spec says that this is not possible,
since
the only place a producer can
send an event is to a channel and the only place
that
a consumer can get an event
is from a channel.
HOWEVER (*controversial stuff*) there was a big
debate
on this point in OSOA and
some folks wanted the capability to directly
connect
a producer to a consumer, as
part of the Assembly layer, without an
intermediary
channel. If you look carefully
at the OSOA spec, you will find that this
capability
CAN in fact be added as an
extension of the material that is in the spec.
One
place that this might get used
is in the processing of event streams when dealing
with Complex Event Processing.
That's all I want to say about this capability at
this point - we can return to it
at a later point.
>
> Potentially, the main difference between service-based and
message-/
> event-based design is the following:
>
> 1. There is no service contract
> 2. There is no addressable resource
>
> Argh, I just realized we are back to the old division between
> messaging and other types of systems :-)
>
> Other specific comments inline.
>
> Jim
>
> On Sep 2, 2009, at 12:20 PM, Mike Edwards wrote:
>
>
> Folks,
>
> This is a response to Jim's attached email - the discussion so far
> has been good, and I hope that I
> can contribute some light to the debate. I have changed the
subject
> to a new one that I think more
> closely reflects the debate.
>
> First, general comments. Event Processing is not a new concept.
It
> has been around quite a while
> and is embodied in a number of products (some very successful
ones,
> too!!) and in a number of APIs
> and protocols. Event Processing is an alternative paradigm for
the
> construction of applications,
> distinct from the method/operation based approach of "standard
SOA".
> A number of observers have
> made the comment that applications in general need to encompass a
> mix of services and event
> processing - and that SCA needs to encompass the same range of
capabilities.
>
> So, what distinguishes a service based design from an event
> processing based design?
>
> I think that service based design starts with the concept of a
> service, which can be invoked by users.
> A service is associated with an interface that defines the
> capabilities of the service - and the interface
> is described in terms of one or more operations, each of which can
> have zero or more input parameters
> and zero or one response values. (Often the parameters are
described
> as an input message and
> the response values as a response message).
>
> When a service interface has multiple operations, it is typically
> the case that there is a relationship
> between the operations of the interface. Each might be dealing
with
> same entity (eg an Order) and can
> represent different manipulations of that entity (create, update,
> status, cancel...etc). I acknowledge that
> there is nothing in a service interface that requires this, but
this
> is the logic of service based design.
> This quite often implies data sharing between different operations
> (eg output of one is an input to
> another...).
>
> One factor in service based design is also that an operation is
> something that the client of the service
> needs to know did complete. This may be due to the need to obtain
> some data value(s) for future
> work, or simply to know that a step in a process did complete
> successfully (or not, as the case may be),
> since it will affect the future actions of the client. This
implies
> some form of request/response behaviour,
> even in the case where there is no actual response data - and I
note
> that this may be the case even where
> the response arrives through some asynchronous means, perhaps a
long
> time after the original invocation.
>
> I agree with many of the points above except the one about the
> client of a service needing to know an operation completed. In
some
> cases this is the case ("guaranteed processing") and is
often
> handled through application-specific acknowledgements in messaging
> systems. However, many times this is not the case as less strict
> semantics are sufficient such as guaranteed delivery or no
guarantees
at all.
In general, I believe that service based
processing
has this characteristic.
>
> One important factor in service design and service operation is
that
> when a client invokes a service through
> its interface, the exact operation that was requested by the
client
> is what is executed by the service provider.
>
> There are some cases when the "exact" operation is not invoked,
e.g.
> when mediation or an interface matching algorithm is used. This
may
> be hairsplitting at this point but it may be important to remember
later on.
For me, this is hairsplitting. I can argue that
the mediation is in fact the
service that is invoked by the client - the fact
that
the mediation merely transforms
data and invokes other service(s) is a mere detail
of its implementation.
>
> So, envisage a service interface with a set of operations. All
the
> operations MIGHT take the same input
> parameter type ("input message") - and MIGHT even all respond
with
> the same response parameter type
> ("response message") - but it is an essential part of the
contract
> between the client and the provider that
> the correct operation is invoked on the provider - eg update(
order
> ) is very distinct from cancel( order ).
> This also means that the interface of the service provider must be
a
> superset of the interface used by the
> service client.
>
>
> The final point to make is that service based design is generally
a
> one-to-one contract between a service
> client and a service provider. That is not to say that the client
> cannot connect to multiple service providers,
> but that the client is aware of each connection and actively uses
> each connection on a one-to-one basis.
> One request - one response is the basic paradigm.
>
>
> So, can we now contrast this with the behaviour of event
processing?
>
> Event processing design is essentially based on the exchange of
> messages (data elements). It is inherently
> a one-way design. A producer creates a message (or "event")
and
> sends it out to some event consumer(s)
> without any implication that there is a response of any kind.
>
> I think the same can be said of loosely coupled one-way services
> interactions. Data can be sent with no guarantees that it will
> arrive at the service endpoint or acknowledgement. Similarly, some
> events may require strong delivery guarantees.
>
> Each event stands on its own.
>
> This can also be said of service operation parameters. They are
> "data" instead of "object pointers".
>
> There is no concept of an "interface", either for
a producer or for
> a consumer.
>
> This was the point that sparked my comments above.
>
> A producer may indicate that it produces some set of messages and
a
> consumer may indicate that it consumes
> some other set of messages. However, if a producer sends out
an
> event, even if the consumer is listening
> to events from that producer, the consumer might not process the
> event - it may be filtered away either by the
> infrastructure or by the consumer.
> This could be a characteristic of the JMS
binding
as well.
>
> A producer of an event has precisely no expectations of any
> processing that may occur in response to an
> event it produces. The producer does not even know if anyone
is
> listening for that event. There is no contract
> between an event producer and an event consumer of any kind, other
> than the data of the event message
> itself.
>
> A producer does not know and should not care how many consumers
> receive and act on any event that the
> producer sends out. A consumer should not normally care which
> producer an event came from - all the
> information should be in the event message itself.
> This can be said of uni-directional services
as well.
>
>
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
> I think that is enough to start with. I haven't related this
to SCA
> yet, but it is worth seeing whether we all agree on
> the basic concepts I've described above before moving on to ask
how
> this relates to SCA - and possible
> designs for Event Processing in SCA.
>
> 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
>
> Jim Marino <jim.marino@gmail.com> wrote on 02/09/2009
10:22:04:
> >
> > Re: [sca-assembly] Pointer to SCA event processing
presentation
> >
> > Jim Marino
> >
> > to: OASIS Assembly
> >
> > 02/09/2009 10:22
> >
> > More comments inline.
> >
> > Another general comment on the discussion...It seems a
fundamental
> > problems is the concept of eventing is too vague. A useful
step
> > would be clearly define what it is, which includes general
agreement
> > on why it is different, not different, or a specialized
subset of
> > service-based design. So far, none of the explanations put
forth
> > really seem convincing as to why it is different. So, I'm
going
to
> > keep pushing on trying to solve this with existing concepts
by
> > working through concrete examples and see where we come out.
It may
> > turn out that eventing is something entirely new and isn't
possible
> > to model via service-based design as it is currently laid out
in
> > Assembly. This will take extra time but hopefully provide the
> > benefit of having some specific examples and more precise
> > definitions/concepts.
> >
> > Jim
>
>
>
>
> 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
>
>
>
>
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
|