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