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: Re: [sca-assembly] SCA event processing principles



On Sep 3, 2009, at 10:40 AM, Mike Edwards wrote:


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.

That sounds like a good place to turn to now along with the "addressable" issue below.

Some detailed comments inline.

Yours,  Mike.

<snip/>

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

By data contract I mean the information passed from the infrastructure to the consumer takes a certain agreed form. This form could be very generic or specific, e.g. a "buy order". In other words, the infrastructure will never pass an unexpected type to the consumer. I'm also inclined to say the producer side is the same - it passes an agreed form to the infrastructure.



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


That there is a defined way the consumer and producer interact with the infrastructure. On the consumer side, there is a determined way a consumer receives an event. JMS does this through the MessageListener API. An API for eventing is probably not the best way to do this and something higher level can probably be used based on introspection rules (like the JMS binding does for determining a service operation).

The other aspect I would like to have is that this "interaction contract" always requires producers and consumers to adhere to pass-by-value semantics. A consumer or producer should never modify the contents of an event message after it has been sent to the infrastructure. This will allow the infrastructure to make by-reference optimizations.

I don't think the contract should include any delivery guarantees unless there is a specific policy configured. 

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


By addressable I mean can be located according to some logical identifier - i.e. a URI in SCA. It is not necessarily the case that addressable mean "network addressable" since local services cannot be accessed over a remote network.

If a consumer is addressable, then the next question is whether it is wireable or not. 

It is interesting this issue seems to have come up again in an entirely different context (OASIS). I think it would be good to explore this further when we get to the point of seeing how all of this relates to SCA concepts. In particular, how even streams are modeled. 

As an aside, one thing that would have helped in bringing the OSOA proposal into OASIS is if the major technical issues/debates were documented so they could be discussed further.

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

I'm not sure I follow your response here but this may be a minor point. In many cases - particularly message-based ones - clients don't need guaranteed processing semantics. Guaranteed delivery are enough and they can assume a message will eventually be processed through redelivery.  


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

OK this is interesting. Maybe the same argument can be made about eventing - a service is invoked by a client with no semantics about how/if the event will be processed? I'm not necessarily arguing for this approach but it is one to think about. That would still preserve the fact that there is no contract between the producer and consumer.




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