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
Director, Oracle Fusion Middleware +1(650)506-1975
and Web Services Standards 500 Oracle Parkway, M/S 2OP9
Oracle Redwood Shores, CA 94065
