[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] [Issue 80] Proposed directional resolution
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 > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]