[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [sca-assembly] [Issue 80] Proposed directional resolution
Simon, That's effectively what our proposal says! So the main point here is either we do nothing, or we do the full job; I don't think best practices help. Martin. > -----Original Message----- > From: Simon Nash [mailto:oasis@cjnash.com] > Sent: 25 June 2009 14:37 > To: ashok.malhotra@oracle.com > Cc: Martin Chapman; 'Jeff Mischkinsky'; 'Anish Karmarkar'; 'OASIS Assembly' > Subject: Re: [sca-assembly] [Issue 80] Proposed directional resolution > > Ashok, > It seems to me that the pub/sub model is very close to having services > and references wired to channels. The OSOA spec does not express it > that way, but the conceptual similarity is clear. > > I think it would not be very difficult to build something similar > to the OSOA Events model using the OASIS PRD 1.1 Assembly Model plus > a channel component that provides the pub/sub functionality and is > wired to services and references whose interfaces follow a particular > pattern. > > I'll put my hard hat on now, before the rocks start flying! > > Simon > > ashok malhotra wrote: > > As I have said before, wires and pub/sub are alternate means of > > communication and need to be presented > > side-by-side to provide the complete picture. > > All the best, Ashok > > > > > > Martin Chapman wrote: > >> <oracle hat> > >> > >> What best practices are these? > >> Aside from using a jms binding that allows for loose coupling at the > >> connection level (you still need wires though) is there any > >> experience amongst us to suggest what "best practice" exists? > >> > >> IMHO the best practices from the oracle esb/soa space are embodied in > >> the eventing pub/sub additions. > >> > >> I also think we need to be much more precise about using the term sca > >> 1.1. This is an umbrella term pointing to a family of specs > >> (policy, assembly, ws-bindings, pojo, etc.) I see no reason why > >> eventing can't be part of the 1.1 family somehow. > >> > >> Martin. > >> </oracle hat> > >> > >> > >> > >> > >>> -----Original Message----- > >>> From: Simon Nash [mailto:oasis@cjnash.com] > >>> Sent: 25 June 2009 12:08 > >>> To: Jeff Mischkinsky > >>> Cc: Anish Karmarkar; OASIS Assembly > >>> Subject: Re: [sca-assembly] [Issue 80] Proposed directional resolution > >>> > >>> 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 > >>>> 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 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> 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 > >> > > > > > > > > --------------------------------------------------------------------- > 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]