RE: [sca-assembly] some of our concerns with the eventing proposal

["Estefan, Jeff A (3100)" <jeffrey.a.estefan@jpl.nasa.gov>]

Martin,

I will do my best to join today's call; however, I challenge you to look to your own standards body; namely, OASIS for a very clear capture the essence of what SOA is that is devoid of marketing hype.  For example, please review the products of the OASIS SOA RM TC as an example.  Clearly, SOA is a paradigm,  ESB is not.  ESBs are a type of integration middleware, intended to be more "standards-based" than their earlier Integration Broker (IB) cousins.  If anyone is suggesting otherwise, then we're talking marketing hype!

 - Jeff E.

-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com] 
Sent: Wednesday, September 09, 2009 8:27 AM
To: Estefan, Jeff A (3100); 'OASIS Assembly'
Subject: RE: [sca-assembly] some of our concerns with the eventing proposal

Jeff,

While I agree the names are a bit misleading these are mostly marketing terms.
We definitely have two main trends in the industry, SOA and ESB, but experience has shown us that software never neatly fits into
one or the other, they are usually a mixture of both. If SCA is going to have legs for quite a few years, then it's in our interest
to make sure both trends are covered. 

Interestingly the term SOA 2.0 is being used to cover combined SOA/ESB architectures, so lets future proof SCA!

Martin.

> -----Original Message-----
> From: Estefan, Jeff A (3100) [mailto:jeffrey.a.estefan@jpl.nasa.gov]
> Sent: 09 September 2009 16:15
> To: 'OASIS Assembly'
> Subject: RE: [sca-assembly] some of our concerns with the eventing proposal
> 
> If there is no contractual agreement between an SCA consumer and provider, then it would seem we are
> no longer talking about services in the context of SOA, or in this case, a programming model for SOA.
> What then does "Service" in "Service Component Architecture (SCA)" really mean?
> 
>  - Jeff E.
> 
> -----Original Message-----
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: Wednesday, September 09, 2009 7:14 AM
> To: 'Jim Marino'
> Cc: 'Scott Vorthmann'; 'OASIS Assembly'
> Subject: RE: [sca-assembly] some of our concerns with the eventing proposal
> 
> 
> 
> > -----Original Message-----
> > From: Jim Marino [mailto:jim.marino@gmail.com]
> > Sent: 09 September 2009 14:56
> > To: Martin Chapman
> > Cc: 'Scott Vorthmann'; 'OASIS Assembly'
> > Subject: Re: [sca-assembly] some of our concerns with the eventing proposal
> >
> > Hi Martin,
> >
> > I had one question below.
> >
> > Thanks,
> > Jim
> >
> > On Sep 9, 2009, at 2:44 PM, Martin Chapman wrote:
> >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Scott Vorthmann [mailto:scottv@tibco.com]
> > >> Sent: 09 September 2009 08:47
> > >> To: OASIS Assembly
> > >> Subject: [sca-assembly] some of our concerns with the eventing
> > >> proposal
> > >>
> > >>
> > >> To inform the technical discussion we'll be having tomorrow, I'd like
> > >> to shed some light on TIBCO's concerns with the existing proposal.
> > >> The following is not exhaustive or terribly detailed, but is enough
> > >> to
> > >> begin discussion.
> > >>
> > >> 1. Eventing and publish-subscribe messaging are not the same thing.
> > >> While it is useful for SCA to define a pub-sub alternative for the
> > >> current wiring paradigm, that does not have to imply definition of
> > >> new
> > >> componentType concepts like consumer and producer.  We believe that
> > >> pub/sub messaging can and should be fit into SCA without affecting
> > >> the
> > >> developer model.
> > >
> > > [<MartinC>] Would have to disagree here. I think the developer does
> > > want to know if it is processing an event (i.e. can do what it
> > > wants with it) vs servicing an explicit request from a client. So
> > > some annotation or syntactic differentiation is required IMHO.
> > >
> >
> > Assuming a service is one-way and not bidirectional (in SCA terms),
> > why would handling an event be any different than handling an
> > invocation from a developer/implementation perspective? In other
> > words, how would the difference between event data and invocation data
> > manifest itself?
> 
> [<MartinC>] with an event, there is no  semantic contractual expectation on the side of the sender as
> to what the receiver will do
> upon receipt - the operation name is meaningless for an event but carries some semantics for normal
> invocations.
> e.g debitBankAccount(200) vs an event that says an Account has gone overdrawn.
> 
> >
> > Jim
> >
> > ---------------------------------------------------------------------
> > 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