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] Pointer to SCA event processing presentation


Martin,

I'm sorry you find this discussion frustrating but please try and  
understand the position some of us are in who were not privy to the  
prior eventing work done outside OASIS. I think it is fair to raise  
questions about the current proposal; it is after all just potentially  
one proposal among many that could be considered.

Also, I feel it is reasonable to start with the premise that we should  
first see if existing concepts can accommodate eventing use cases.  
Given the complexity surfacing in SCA and the concern that has been  
voiced about this, a good argument can be made that we should be very  
cautious about adding new concepts, particularly when the 1.1  
specifications have not been released and user experience/feedback has  
been limited.

In raising the questions I have, my goals have been to:

1. Understand eventing requirements
2. See if SCA can meet those requirements
3. Provide a solution that does not increase the complexity of SCA and  
is consistent with its current design
4. Provide a solution that is modular.

I hope the first three goals came across in my previous emails. The  
fourth goal was not explicitly stated. Basically, I would like to have  
eventing decoupled (no pun intended) from the core assembly  
specification so that runtimes can choose to implement it or not. This  
is not only good design practice but also serves a practical purpose  
in gaining at least two conformant SCA implementation sooner rather  
than later.

The rest of my comments are inline.

Jim


On Sep 1, 2009, at 2:22 PM, Martin Chapman wrote:

>> So far it seems to me that this can be handled by services,
>> references, and bindings. I may be wrong in the end, but it seems
>> worthwhile to start from that premise given the additional complexity
>> the eventing proposal introduces.
>
> What I find frustrating in this discussion is the premise that we  
> don't need to do anything, followed by some hacking of how to make
> it work. We either need to do something or we don't.

I haven't seen any proposal that says nothing needs to be done. The  
disagreement is over whether new concepts are required or existing  
ones suffice.

> The current model requires references and services to be wired,

This is not accurate. It requires them to be configured with a  
binding. That is different.

> requires the
> interfaces on each end to match (or at least a subset to match),

This is also not accurate. My proposal requires the *data* to match  
(i.e. be the same type or a substitutable type), not the interfaces. I  
believe this is required of all approaches. I'll also note at the risk  
of belaboring the point that this is how the JMS binding behaves. For  
example, I can configure a reference with the JMS binding pointing to  
a destination A and configure a service using the JMS binding that is  
associated with the same destination. The reference and service can  
have different interfaces as long as the data matches.

> and then relies on a binding to support the 1-to-1 interaction. If
> you take the need for a wire out of the equation and push  
> interaction semantics (1-m,m-1, m-n) down into a binding, you have  
> IMHO
> invented a different type of wire, for which the current semantics  
> (such as interface matching) are no longer necessary - and for
> which autowiring may become very problematic.

My proposal doesn't invent anything new here. This is exactly how a  
reference behaves when bound to a service provider that is hosted  
outside the domain. In this context, interface matching is not done as  
with a wire. Also, autowire has nothing to do with this use case as  
autowire is only used for wiring references to services (by the  
definition of wiring, in the same domain), which is not being done here.


> I don't think we need code snippets to explore these differences, as  
> we have to be
> able to conceptualise at the SCDL level.
>

I'm sorry you disagree and would urge you to reconsider. I find  
walking through concrete examples - code and SCDL - very useful since  
it helps establish a common understanding and vocabulary. In my  
experience it also helps in driving consistency at a conceptual level  
and validates a design.


> One of the use cases we have within Oracle is in the presentation,  
> that of a new employee.
> Rather than build an HR business process that hard wires (pun  
> intended) the processes required throughout Oracle,
> the HR system send out a new employee event. This is then captured  
> by whoever is listening (payroll, IT, directory updates,
> security), of course the HR system doesn't know beforehand who and  
> how many other recipients there are. In addition each listener
> may also be listening for other events from other producers in the  
> system, and typically there is an additional listener who
> captures all events into a log. This type of scenario is hard to  
> model with SCDL as it stands, even though we tried.
>

I would like to walk through the difficulties using a combination of  
SCDL and code. If you agree, I can post an example of what I was  
thinking.

Jim

> Martin.
>
>> -----Original Message-----
>> From: Jim Marino [mailto:jim.marino@gmail.com]
>> Sent: 01 September 2009 11:02
>> To: OASIS Assembly
>> Subject: Re: [sca-assembly] Pointer to SCA event processing  
>> presentation
>>
>>
>> On Sep 1, 2009, at 9:15 AM, Anish Karmarkar wrote:
>>
>>> Jim Marino wrote:
>>>> Hi Anish,
>>>> I have a very naive question about the eventing proposal: is there
>>>> a capability that cannot be implemented using JMS? My impression is
>>>> the JMS API has everything that is needed to be the foundation of
>>>> an eventing system.
>>>
>>> JMS doesn't provide what is needed for an assembly model. JMS, as
>>> you know, is a *Java* *API*. It doesn't say how to do things in,
>>> say, BPEL. It doesn't say how to create a composite application that
>>> contains components that want to subscribe or publish events of
>>> certain types. It doesn't allow multiple components that contain
>>> publish/subscribe/topic functionality to be connected/wired/
>>> configured and deployed/managed as a  single entity.
>>>
>>
>> I should have been clearer. My question wasn't about using the JMS  
>> API
>> directly. Rather, it was about using it (and a JMS provider) to build
>> eventing functionality as a binding.
>>
>>> If I were to stretch the comparison a bit: even though we have JAX-
>>> WS, which can be used to implement and invoke services, we still
>>> need SCA ;-)
>>
>> That was my point :-)
>>
>>>
>>> What the contribution addresses is an assembly-level model for pub-
>>> sub. It provides the additional concepts/constructs needed to
>>> declare subscribers (or consumers), publishers (or producers),
>>> topics (channels) that can coexist with existing service-reference-
>>> wiring model and takes advantage of the intent/policy framework.
>>>
>>
>> So far it seems to me that this can be handled by services,
>> references, and bindings. I may be wrong in the end, but it seems
>> worthwhile to start from that premise given the additional complexity
>> the eventing proposal introduces.
>>
>> Jim
>>
>>
>>> Hope that makes sense.
>>>
>>> -Anish
>>> --
>>>
>>>> As an aside, I'm not asking this as a way of implying that JMS
>>>> should be used and/or required.
>>>> Jim
>>>> On Aug 26, 2009, at 6:57 PM, Anish Karmarkar wrote:
>>>>> Hi Sanjay,
>>>>>
>>>>> Here is the link to the presentation:
>>>>> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/32653/SCA-
>> EventingProcessing.pdf
>>>>>
>>>>> It does talk about the motivation and has use cases.
>>>>>
>>>>> HTH
>>>>>
>>>>> -Anish
>>>>> --
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
>
>



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