RE: [sca-assembly] [Issue 80] Proposed directional resolution

["Martin Chapman" <martin.chapman@oracle.com>]

<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