[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]