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. 2. There must be a contract between the producer and the infrastructure and the consumer and the infrastructure
Thinking about this further, another question to ask is, "are consumers addressable"?
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. 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. 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
|