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] [Issue 80] Proposed directional resolution

On behalf of all TIBCO's participants to the entire collection of SCA  
TCs, we wish to express the following concerns with regards to  
integrating the proposal for eventing.
Our concerns come in three parts:

   • we see technical issues with the proposal from OSOA
   • whether or not the TC(s) address these technical issues, it will  
still take a while to incorporate the proposed changes,as an  
inevitable consequence of discussion and coordination with other TCs
   • even if we didn't have issues, procedurally, introducing this  
much change this late doesn't work
On the technical side, we have quite a number of concerns with the  
proposal as it stands. These concerns range from small details to  
overall large architectural concerns. As one of many examples, based  
on our understanding, a Java developerwho wants to use eventing will  
need to understand a substantially different model to use this  
functionality, and probablyneed to code differently, when in a  
significant number of cases that may not be useful or necessary.

Even if we did not have quite a few detailed technical concerns, we're  
hard-pressed to see how this proposal can be adopted without  
dramatically delaying the process of completing the SCA specifications.

In the Assembly TC, we see numerous points of delay. Merely fitting  
the existing eventing proposal into the Assembly specification,  
unifying the terminology, fixing up links, and addressing mismatched  
context problems will take a while, with numerous editorial drafts.  
Then the TC will need to engage the question of normative statements,  
and the testing required to support eventing. It is possible that the  
companies proposing eventing think this can go quickly, and have done  
work to enable that, but we do not. Further, to be fair to our  
eventual customers, another PR process would be appropriate. Then  
there's the matter of coordinating with the other TCs.

For example, the bindings TC will need to consider the implications of  
eventing. That TC likely faces a key initial decision - either engage  
the eventing notion, and try to fit it into the existing  
specifications, or simply choose not to support it. In the case of  
engaging with eventing, we suspect it is likely that new issues will  
be uncovered that can only be addressed by the Assembly TC. Either  
those issues get addressed in the Assembly TC - further delaying the  
Assembly specification, or they do not, in which case the binding TC  
will be left to muddle through a decision on its own. Going back to  
the original decision point, if the bindings TC decides to forgo any  
discussion of eventing, it calls into question the very notion of  
having eventing in the assembly specification, without any bindings  
that profess to implement it.

It is perhaps worth reminding everyone that the Bindings TC, of all  
the TCs, is currently the most delayed of all. Adding work to this TC  
is perhaps ill-advised.

The implementation TCs will likely engage with the eventing  
specification as well. All of Java, BPEL, and C++ will have the same  
initial decision as the Bindings TC. Consequently, they will all add  
an additional burden of coordination, or contribute to the same lack  
of validation for the concepts of eventing.

To our final point, this is the wrong point in the process to  
introduce changes of this scope. Most of the SCA specificationshave  
already gone out for public review. Adding the amount of functionality  
implied by the eventing proposal seems to us to amount to a "just  
kidding" message for those people who have already bothered to review  
the existing specifications.Procedurally, we also observe a very odd  
procedural situation. Since the "eventing" issue is already open, only  
takes a majority to "resolve" the issue with specific text. However,  
should a majority of the TC then come around to realizing a flaw in  
the proposal, by the standing rules of all the TCs, raising and  
opening those issues will require a two-thirds votes of the committee.  
It is, in other words, easy to make a mistake, and very difficult to  
fix it. That's the very opposite of where we should be while nearing  
the end of a public review.

For a variety of obvious reasons TIBCO likes the notion of publish and  
subscribe functionality, and does have an interest in seeing that some  
sort of functionality like that which has been proposed eventually  
fits well with SCA. We're thankful for the effort that others have put  
into coming up with a proposal. Unfortunately, as much as we like the  
notion, for the reasons we expressed above - the technical issues, the  
coordination and resulting delay, and the procedural flaws, we cannot  
support adding such functionality at this time. We think the  
specification, and (all!) our customers would be better served by  
finishing up with the current scope of specifications we do have,  
rather than adding the inevitable delay that will stem from the  
eventing notion. Given the time pressures, we're also deeply concerned  
about the potential for compromises which make the specifications  
weaker overall. That would be a sad way to wrap up the fantastic  
efforts by so many people, from so many companies, for so long.

Sincerely, TIBCO's SCA-related TC members.

On Jun 22, 2009, at 4:03 PM, Eric Wells wrote:

> All,
>    much as I think the Event Handling spec is pretty useful I have  
> to agree
> with Simon.
> As Mike pointed out there are actually quite a few open issues now.  
> I don't
> think the current PRD/CD03 spec is a completely accurate reflection  
> on what
> the final document will look like.
> If you add to this Event Handling the it will be too much work to  
> deal with
> in a reasonable time. (Do I need to mention TESTING it as well? :-}
> Let's wrap up what we have in the 1.1 PRD and then think about how  
> to add in
> Event Handling.
> Best Regards,
>              Eric.
>> -----Original Message-----
>> From: Simon Nash [mailto:oasis@cjnash.com]
>> Sent: Monday, June 22, 2009 12:54 PM
>> To: Anish Karmarkar
>> Cc: OASIS Assembly
>> Subject: Re: [sca-assembly] [Issue 80] Proposed directional  
>> resolution
>> 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.pd
>>> f
>> ---------------------------------------------------------------------
>>> 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_workgr
>> oups.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]