Re: [sca-assembly] [Issue 80] Proposed directional resolution

[Simon Nash <oasis@cjnash.com>]

Jeff,
I understand the value of events and pub/sub and I agree that SCA
needs to move forward with adding these capabilities.

My experience of dealing with customers is that they are OK if
not everything arrives in a single release, as long as there is a
clear roadmap for how improved capability will be added later.

I thought the email from Jacques Durand on this subject
(see http://lists.oasis-open.org/archives/sca-assembly-comment/200906/msg00016.html)
was very interesting.  The approach he suggests in comment [12b] of
documenting "best practice" for handing events with the current
Assembly concepts might provide a way to achieve credibility for
SCA 1.1 in the integration space while allowing the standarization
of the full event and pub/sub model to proceed in parallel on a
later schedule.

   Simon

Jeff Mischkinsky wrote:
> hi Simon,
> 
> The problem we have with delaying putting in the event concept is that 
> we see it as a fundamental part of the functionality that SCA is 
> supposed to deliver. Essentially without eventing and pub/sub support as 
> a first class citizen, SCA will not be seen as a credible solution in 
> the SOA-space in general; and the integration-space in particular -- its 
> two major targets. I know y'all laugh if i pull out the "our customers 
> tell us" chestnut, though in fact that IS true, especially for our 
> larger customers. In addition, it is critical to our internal customers 
> (the apps and integration teams), and analysts have made the same point 
> to us, repeatedly.
> 
> Without a decoupled processing model that complements the existing SCA 
> service-reference model, we believe that SCA will not gain as much 
> traction and be a serious contender in the SOA-space, as it deserves. 
> Both our internal and external customers use both models to integrate 
> their applications and solutions. Pub-sub and event processing are 
> well-established and well-entrenched way of modeling, thinking and 
> programming in the integration-space and we strongly believe that SCA 
> needs to address them now.
> 
> We just don't understand how in this day and age one can go out with a 
> message that SCA is the best implementation model for SOA without it 
> addressing one of the main design points of SOA - loose coupling, event 
> processing.
> 
> When making the proposal to issue-80, we are very much aware of, and do 
> appreciate, the implications on the schedule. But we feel that it is in 
> the best interest of the SCA standard and its adoption to delay the 
> release of SCA 1.1, if necessary, to include support for pub-sub and 
> event processing. Without this inclusion, there is a real risk of SCA 
> not being taken seriously and proprietary eventing processing, pub-sub 
> extensions impeding portability and fragmenting the standard.
> 
> We are also not clear on exactly how long a delay this will actually 
> create, since we don't know at this point when we will be in a position 
> to the meet the exit criteria, i.e. the test suites with 2 implementations.
>   cheers,
>   jeff
> On Jun 22, 2009, at 12:53 PM, Simon Nash wrote:
> 
>> Anish,
>> I am very concerned about the work involved in fully integrating
>> the event concepts into SCA Assembly and presumably all the other
>> SCA specs.
>>
>> At this stage in the SCA 1.1 lifecycle I believe our priority should
>> be to close down the few remaining issues, complete the public reviews,
>> and move to formal ratification of the SCA 1.1 standard based on the
>> current specifications.
>>
>> Absorbing this major new piece of functionality into the SCA specs
>> will have large implications and push out the completion of SCA 1.1
>> by some considerable time.  IMO it would be better to look at whether
>> the Events support could be standardized in some other form such as
>> a separate delta or supplement to the SCA 1.1 base specs.  This would
>> allow the current specifications to achieve standardization in a
>> timely manner, followed by an SCA Events 1.1 standard when this is
>> complete and ready to go forward.
>>
>>  Simon
>>
>> Anish Karmarkar wrote:
>>> I would like to propose that we use the contribution at [2], as a basis
>>> for a directional resolution for issue 80 [1]. Specifically, we
>>> introduce the concepts of events, event types, producers, consumers,
>>> channels; and the changes these concepts make to the existing
>>> composite/component/componentType/constrainingType constructs.
>>> If this directional resolution is accepted, I suggest that an inlined
>>> document (with change marks) be produced that provides a merge between
>>> [2] and the existing latest version of SCA Assembly. This would then
>>> serve as a basis for the resolution of issue 80.
>>> Comments?
>>> -Anish
>>> -- 
>>> [1] http://www.osoa.org/jira/browse/ASSEMBLY-80
>>> [2]
>>> http://www.oasis-open.org/apps/org/workgroup/sca-assembly/download.php/32379/SCA_Assembly_Extensions_for_Event_Processing_and_PubSub_V1_0.pdf --------------------------------------------------------------------- 
>>>
>>> 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
> 
> -- 
> Jeff Mischkinsky                              jeff.mischkinsky@oracle.com
> Director, Oracle Fusion Middleware                 +1(650)506-1975
>     and Web Services Standards                       500 Oracle Parkway, 
> M/S 2OP9
> Oracle                                Redwood Shores, CA 94065
> 
> 
> 
> 
> 
> 
> 
> 
> 
>