OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [sca-assembly] SCA event processing principles



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.

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

Each event stands on its own.  There is no concept of an "interface", either for a producer or for a consumer.
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.

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.


-----------------------------------------------------------------------------------------------------------------------------------------------------------------
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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]