[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] [Issue 80] Proposed directional resolution
I think we should do the full job. All the best, Ashok Martin Chapman wrote: > 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 >> > > > > --------------------------------------------------------------------- > 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]