OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sca-assembly] Issue 94: Conversational services


Resending with issue number in subject.

> -----Original Message-----
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: 11 December 2008 14:08
> To: 'Jim Marino'; 'OASIS Assembly'
> Subject: RE: [sca-assembly] Conversational services
> 
> Jim,
> 
> My main concern lies with the simplistic concepts we have, and in the
> annotations we have done for wsdl.
> We only have the "endsConversation" annotation, and I cannot tell by
> looking
> at the wsdl what operation starts a conversation, or even if an
> operation is
> required to be in a conversation. In addition, I cannot call an
> operation
> with an "endsConversation" and allow the option of continuing the
> conversation, so we force an end/terminate/cancel operation to be
> explicitly
> defined. Only having the "endsConverstaion" annotation, and having
> assumptions about the other operations in the same interface is why I
> say
> its half-baked. I'm sure it suits some simple use cases, but it doesn't
> solve the general case, and doesn't address the multi-party case.
> 
> There are two ways to do this properly IMHO:
> 
> 	1. extend the declarative style with begin, continue etc. One can
> even envisage specifying the valid sequences of operation calls. Work
> was
> done in the 80's on extended open predicate path expressions which is
> one
> example of this approach:
> http://www.ansa.co.uk/ANSATech/93/Primary/10100002.pdf.
> 
> 	2. The other way is the programmatic approach (not sure this is
> the
> right word). This is where there are no annotations on operations per
> say,
> but rather invocations are scoped on the client side with begin/end
> markers,
> much like one would do when writing transactions - though of course the
> server has to be suitable enabled.
> 
> Approach 1 doesn't solve the multi-party case though and one could
> argue
> that you are getting into choreography territory.
> Approach 2 requires activity/coordination services and is probably a
> more
> general solution to the problem.
> 
> So this is what leads me to the conclusion that either we do the job
> fully
> and properly,  or we remove the feature for this round of SCA.
> 
> Martin.
> 
> 
> 
> 
> > -----Original Message-----
> > From: Jim Marino [mailto:jim.marino@gmail.com]
> > Sent: 09 December 2008 17:35
> > To: OASIS Assembly
> > Subject: [sca-assembly] Conversational services
> >
> > Hi,
> >
> > Martin mentioned Oracle's experience with conversational services led
> > them to the conclusion that they were "half-baked" and too complex on
> > the Assembly call today. Unfortunately, time ran out before I could
> > ask him to elaborate. From an end-user perspective, conversations are
> > a critical part of our applications. Without them, we will likely be
> > forced to adopt a proprietary approach (or potentially look to
> another
> > technology), which for obvious reasons we don't want to do. Based on
> > my discussions in the past with other end-users, I don't think I am
> > alone in my views.
> >
> > As some background, we are currently building several European inter-
> > bank payment and ATM processing systems which are in various stages
> of
> > production use. The size of these applications are quite large (over
> > 150 composites each) and the requirements challenging, but due to
> > SCA's ease-of-use, we were able to implement them successfully with
> > developers who had no prior SCA exposure and relatively limited
> > experience with service-based architectures. In building these
> > applications, conversational services allowed us to greatly simplify
> > many previously complex tasks, such as large document processing and
> > managing JPA persistence contexts. From a cost and ongoing
> maintenance
> > standpoint, conversational service support has allowed us to remove
> an
> > enormous amount of "boilerplate" code that existed in our legacy
> > systems.
> >
> > We were able to support conversational services in our SCA
> > infrastructure in a relatively straightforward way. So far, based on
> > our application throughput requirements (processing 100 million
> > transactions in a three hour period), we have not encountered any
> > performance issues related to conversations.
> >
> > I'm sure there are areas where they can be improved. For example,
> > multi-party conversations is one, which we have implemented as a
> > proprietary extension in our infrastructure. There is also the
> > question of inter-operability, although I don't view that as
> > necessarily important at this stage given SCA runtimes from different
> > vendors are not likely to interoperate (e.g. different vendor
> runtimes
> > participating in the same domain) any time in the near future.
> > However, before we remove such an important feature, I would like to
> > understand the specifics of why conversations are too complex both to
> > use and implement. Granted, there are areas in need of further
> > specification and refinement, but I think that can be said of many
> SCA
> > features.
> >
> > Not to single people out, but Martin and Mike, you both made these
> > claims on the call. Could you please elaborate with technical
> details?
> >
> > Thanks,
> > 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




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]