On Nov 30, 2009, at 2:25 PM, Mike Edwards wrote:
Folks,
I'd like to thank the folks from TIBCO
for sending their Event Processing model to the mailing list.
My initial reaction is to say that I
think there is actually more agreement between their proposals and
the OSOA Event Processing Specification
than I expected, with many of the points being concerned
with the Implementation types and the
computation/treatment of componentType (something that the
OSOA spec says little about).
My summary of the model is along these
lines:
- Agree broadly on OSOA Event Processing
Assembly model with
- Producers
- Consumers
- Channels
(section 3)
- Minimise changes to Implementation model(s)
- no need to introduce new "consumer" and "producer"
artifacts into implementations
- Consumer = service with 1 or more @OneWay
operation
- ignore non @OneWay operations
(section 3.1)
- Producer = reference with all @OneWay
operations
- EventType defined by parameter shape
+ name of operation
(sections 3.1, 3.2)
- WSDL portType = a grouping of EventTypes
(section 4)
- "ChannelBinding" concept -
sort of equivalent to "Binding" for services and references but
for producers and consumers
(section 5)
- Filters - exist but should only operate
on
a) Event Type
b) Event (business) data
(sections 3 & 6)
Actually, I've gotten more input on generic filtering, and I have some arguments to make against it.
-
- NB the use of event type filters appears redundant on Consumers in this
model
since one method == one event type always...
Mostly, yes. There is a use-case for event-type filters, in a top-down scenario, but it is mostly a reuse-and-usability case... not terribly strong. They also might be useful in a bottom-up scenario involving non-JAX-WS "consumer" annotations.
-
- Domain channels
- don't like them (section 6)
Questions:
1. "Event shape defined by XSD
metadata associated with input message"
- not sure that I follow this if the shape is defined in terms of a Java
class (say) by the impl.
- do you mean the XSD to be the JAXB
mapping of the Java class in this case?
I was a bit sloppy there. In our proposal, we have to define what consistency means between different interface types... just as we do today for WSDL and Java service interfaces. Yes, we would apply JAXB in the obvious way, there.
Basically, we want to support an open-ended metadata model for eventing just as we do for services. The same questions arise about which "bindings" (and implementations) support which interface types.
2. Is it possible to have one method/operation
that can take a number of different event types
as parameter (potentially all with different
shapes) - eg using a generic type that can accept
<xs:any/>? If this is not
possible, why not?
(PS I think this question is at least
partially answered by Scott's response to Anish's similar question)
Yes, if implementation.java defines a set of annotations to support consumer/producer metadata. I should have made it more clear that we don't oppose this as an option... we just expect most Java developers to go the other way, and we emphatically want to support that.
Incidentally, if WSDL were still used here, the type filters would come in handy.
-------------------------------------------------------------------------------------
Comments:
A. There is a lack of consistency between
the treatment of producers and consumers. A producer has an
interface with all methods @OneWay,
while a consumer can have an interface with some methods which
are not @OneWay and those methods are
ignored. Would it not be simpler to have the same rule for both?
"Simpler" is slippery, but in any case, I don't feel strongly.
B. Why not simply use the existing "binding"
element as defined in the current Assembly specification and use
this for consumers and producers? I
can't see what different information would apply. Think about using
JMS
for example.
JMS is probably a special case, since "destination" can be queue or topic. What about "binding types" that can apply to consumer/producer/channel but not service/reference? Or vice-versa? I always favor precise modeling (reflect contraints in syntax/structure when you can) over shorter XSDs.
C. The proposed model seeks to exclude
any of the event processing concepts from the implementation layer.
This assumes that the implementation
developer never needs to use any of those concepts. But in reality
they
may well expect to use those concepts
in some cases. Filters are a good example. The developer may
want
to say "this method accepts events
of event type X but only where the value of field Y is equal to B"
- and if so,
the developer should surely have a way
to express this and not rely on some assembler "getting it right"
at some
later point?
See above... Java annotations for consumer/producer are OK, as long as they are not the only way to go.
So while I can accept the principle
of not requiring event processing concepts *by default*, I think that excluding
them altogether goes too far and limits
the developer too much.
Agree.
D. One troubling concept in the TIBCO
proposal is the idea of treating one thing at the implementation as either
one thing or as another at the Assembly
level (eg it can either be a service or a consumer). I assume that
it would
not be possible to treat something in
two different ways at the same time at the Assembly layer (ie it's a service
AND a consumer)?
Why not? What harm befalls? Specifically, if I map a one-way componentType service to both a component service and a component consumer, is there a problem? Sure, it is a little silly, but only depending on how strict we are about exclusivity in composite wiring... I may have both a reference and a channel I want to feed to that component service/consumer.
E. What is the purpose of the event
type grouping implied by a WSDL portType?
For the user, a convenience for reuse (in top-down cases, I expect)... less to copy and paste to lots of consumers and producers. For us, the ability to stay within our extensible metadata framework.
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
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