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: Re: [sca-assembly] Comments on TIBCO SCA Event Processing Proposal

Just a couple of brief comments inline below, Mike... we can expand the discussion tomorrow...


On Nov 30, 2009, at 2:25 PM, Mike Edwards wrote:


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)


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.



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.


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

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