Comments on TIBCO SCA Event Processing Proposal

[Mike Edwards <mike_edwards@uk.ibm.com>]

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)
  - NB the use of event type filters appears redundant on Consumers in this model
  since one method == one event type always...
  
• 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?

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)

-------------------------------------------------------------------------------------

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?

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.

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?

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.

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

E. What is the purpose of the event
type grouping implied by a WSDL portType?


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