Comments on TIBCO SCA Event Processing Proposal

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:  

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