[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]