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: Comments on TIBCO SCA Event Processing Proposal


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:


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)



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

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