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

[Jeff Mischkinsky <jeff.mischkinsky@oracle.com>]

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