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] TIBCO eventing proposal



Folks,

I am sure that we shall get into the nitty-gritties of this stuff very soon today, but I would like to comment on
one thing Anish says below.

This concerns the multiplicity of a producer.

Scott indicates that it would normally be 0..1 and that the implementation code would perform a single invocation
on a method of the producer interface in order to send a message.

Anish then comments that 0..1 would imply that the producer could not be connected to more than 1 channel.

I would like to say that at the Assembly level, the multiplicity is irrelevant for a producer.  That any producer
can be connected to as many channels as the Assembler chooses.  This would have zero impact on the implementation
code - there would never be an implication that the implementation code has to make multiple invocations in order
for the message to be sent to more than 1 channel.  I have always assumed that it is the binding code that does the
necessary work to send messages to as many target channels as are configured on the producer.

I also add another comment.  When used as a Producer, I think the correct multiplicity is actually 1..1 rather than 0..1.
Even if the Producer is not connected to a channel at the Assembly level, I see no reason not to inject a proxy for that
producer and for the implementation call to invoke operations on the proxy.  The fact that there are no targets for the
events being produced is not something that the implementation code should have to be concerned with.  I view this
situation as analogous to a producer connected to a channel which has no consumers.



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



From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
To: Scott Vorthmann <scottv@tibco.com>
Cc: OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date: 01/12/2009 07:08
Subject: Re: [sca-assembly] TIBCO eventing proposal





More comments inlined as <anish>...</anish>

Thanks.

-Anish
--

On 11/30/2009 11:13 AM, Scott Vorthmann wrote:
> Responses inline, Anish...
>
> Scott
>
>
> On Nov 25, 2009, at 11:45 PM, Anish Karmarkar wrote:
>
>> Thanks for sending this out. Even though pictures/examples are missing, I *think* I get the general idea. Few questions/comments about the details (not the overall design) that immediately came to mind:
>>
>> 1) Section 3.1 Exposing a Service as a Consumer says "The name of such an operation is understood to define an event type ..."
>> Can you elaborate on why the operation name has to define the event type? Perhaps I misunderstood what the doc says, but from an event processing perspective, I don't think you want to restrict which events are delivered to a method based on its method name. For example, an onMessage(...) method may (and typically does) processes any event that is delivered. The name onMessage has no relevance wrt which event types it wants to consume.
>
> This is a question of programming style.  The self-dispatch style of event handling you mention should not be ruled out, but as a developer I would prefer to write to a pre-dispatched interface, "printerOn(...), printerOff(...), etc.".  JAX-WS considers this style appropriate and developer-friendly, after all.
>

<anish>
I don't have problem with using JAX-WS style of event dispatch. But the
assumption that the operation name *necessarily* stands for event type
is problematic. Eventing processing sometimes requires that the
application be subscribed to all events in a channel and do its own
dispatch. Furthermore, if we want to enable legacy systems, which I
would argue we do, we have to deal with the fact that event instances
don't necessarily have a event type metadata associated with it. Perhaps
you are thinking of synthesizing the event type metadata for such instances.
</anish>

> If the Java TC wishes to define annotations to support one-method, self-dispatching consumers, that's fine, but we don't believe it is necessary, given the existing mechanisms for one-way operations with JAX-WS.
>
>> 2) Section 3.2 Exposing a Reference as a Producer does not say anything about the cardinality of the reference. I assume it is 0..n.
>
> Actually, I expect it is always 0..1 for one-ways.  There are no responses coming back, so no use-case that makes sense to me for 0..n.
>

<anish>
Having 0..1 does solve the problem of getting an array in the Java code
and having to send the same message (for a producer) to every member of
the array. However, assuming the same wiring rules as that for
service/reference apply, 0..1 prevents a consumer/producer from being
connected to multiple channels. This disallows important usecases. For
example, a producer may be producing earthquake related events and the
producer may have to be connected to the 'data gathering/archival'
channel as well as the 'tsunami warning channel'.
</anish>

>> 3) WRT the minimum-novelty goal, I should point out that the W3C WSRA WG that is standardizing WS-Eventing and friends has found the need to separate the event type description from WSDL. See
http://www.w3.org/2002/ws/ra/edcopies/wseventing.html#Advertising  There is also a plan (not sure if it is approved by the WG yet) for refactoring the event description part in a separate spec in the WG. Trying to fit/overlay event description into the WSDL portType/method model does have its problems.
>
> Perhaps.  We should discuss those problems.  Our main point is this: even if we deem it useful to define a specific metadata model for event types, we should fit it into our existing extension point for interface metadata, and define a mapping to/from WSDL.
>

<anish>
Defining a mapping to/from WSDL seems fine and hopefully WSRA will
tackle that. But I don't see why we have to "... fit it into our
existing extension point for interface metadata ..."
</anish>

>> 4) In Section 7 Domain Channels, is your objection to the syntax or to the fact that a pub/subcriber deep down in a nested composite is "connected" to a domain-level channel, i.e. visibility issue?
>
> The latter, visibility.
>
>
>> 5) WRT channelBinding.sca, is that really necessary given that binding.sca is magic anyway? Wouldn't binding.sca fit the bill?
>
> The issue here isn't the semantics, rather just the XML mechanics (or UML if you like).  From a modeling and schema perspective, "bindings" live on references and services.  We need something else to live on channel, consumer, producer.
>
>> Thanks!
>>
>> -Anish
>> --
>>
>> On 11/25/2009 5:13 PM, Scott Vorthmann wrote:
>>> Here is our proposal, in not a great deal of detail.  We'll have pictures and examples next week.  ;-)
>>> Scott
>>> ------------------------------------------------------------------------
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php









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]