sca-assembly message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: [sca-assembly] SCA event processing principles
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
- Date: Wed, 2 Sep 2009 11:20:44 +0100
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]