[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] Issue 94: Conversational services
On Dec 17, 2008, at 11:11 AM, Martin Chapman wrote: > a) because in all but simple cases it's a notational challenge. > I thought Simon was arguing for a) but I'll let him respond. > Could you list the common use cases that you believe can't be addressed by the given semantics? My argument would be that unless they fall into the "80 %" rule, then having basic functionality, even if it does not address complex scenarios, is a good thing as it will meet most people's needs. Having a clear set of use cases will help us decide if those cases are very common or not. Also, I would point out that the existing semantics to my knowledge don't preclude more complex semantics from being implemented either via an implementation type or application code. Another way of looking at this is to ask, do you think the existing semantics are not useful in common cases or inhibit the complex ones from being realized using additional mechanisms? FWIW, the applications I have been involved in have some fairly complex conversational services and the existing SCA mechanisms have held up well in practice. Jim > Martin. > >> -----Original Message----- >> From: Jim Marino [mailto:jim.marino@gmail.com] >> Sent: 17 December 2008 17:59 >> To: Martin Chapman >> Cc: 'Simon Nash'; 'OASIS Assembly' >> Subject: Re: [sca-assembly] Issue 94: Conversational services >> >> Hi Martin, >> >> I'm a bit confused :-) One of the objections you raised with respect >> to conversational services seemed to be that service lifecycle >> semantics could not be imputed from the service definition. But here, >> you state that you agree with Simon's conclusions. Is it: >> >> a) You don't believe start/continue/end are semantics that should be >> exposed to clients >> b) You think that implementation state management semantics should >> not >> be exposed to clients but start/continue/end as service lifecycle >> semantics should be made explicit to clients >> c) Something else >> >> FWIW, my position is b. >> >> Jim >> >> (I plan on responding to Simon's post separately so as not to confuse >> the discussion) >> >> On Dec 17, 2008, at 9:39 AM, Martin Chapman wrote: >> >>> The add and remove can be parameterised, but since I do not disagree >>> with >>> your conclusion this is academic :-) >>> >>>> -----Original Message----- >>>> From: Simon Nash [mailto:oasis@cjnash.com] >>>> Sent: 16 December 2008 23:10 >>>> To: 'OASIS Assembly' >>>> Subject: Re: [sca-assembly] Issue 94: Conversational services >>>> >>>> As Jim has mentioned, I believe it is better to take the operation >>>> ordering choreography out of the interface definition and make it >>>> the responsibility of the provider implementation to enforce. >>>> >>>> The reason for this is that there are some common cases that can't >>>> be enforced declaratively. For example, consider a "shopping cart" >>>> scenario with the following operations: >>>> create() create a new empty shopping cart >>>> add() add an item to the cart >>>> remove() remove an item currently in the cart >>>> checkout() purchase the items currently in the cart >>>> >>>> We can declaratively assert that create() must be called first, >>>> followed by add(), optionally followed by some combination of >>>> add() and remove() calls, followed by checkout(). We can't say >>>> declaratively that when calling remove(), the item being removed >>>> must already be in the cart. We can require an add() call before >>>> a remove() call, but this add() call could have added a different >>>> item from that being removed. >>>> >>>> There are many similar cases where declarative annotations are not >>>> sufficient for fully defining operation ordering constraints. If >>>> we >>>> are going to include a "conversation" or "stateful correlation" >>>> mechanism in SCA, with begin/continue/end operation semantics that >>>> control the creation/retention/removal of implementation instances, >>>> I think these are best treated as part of the service >>>> implementation >>>> because they are closely coupled to the design of its business >> logic. >>>> >>>> The interface needs to fully describe the semantics that the client >>>> must observe when using it, including not only the ordering of >>>> calls >>>> but also the parameters that may validly be passed on those calls >>>> (as in the add/remove case described above). However, the >> management >>>> of implementation state by the service provider should not be >> visible >>>> to the client and therefore should not be part of the interface. >>>> >>>> Simon >>>> >>>> Martin Chapman wrote: >>>>> Probably getting a bit too indepth for an email discussion but >>>>> I'll >>>> add a >>>>> couple of more comments. >>>>> >>>>> I think we both agree that when we annotate an interface we are >>>> further >>>>> defining the contract that interface offers. For a simple non- >>>> bidirectional >>>>> interface, the annotations can work, but as soon as we add in bi- >>>> directional >>>>> and multi-party we need more. In the bi-directional case, we may >>>>> need >>>>> annotations to say "if you invoke X, I will invoke y back", and a >>>>> multi-party case something like "when x is invoked, I will >>>>> invoke Z >>>> on >>>>> another party (as well as call you back with y!)". This becomes a >>>> notational >>>>> mess and IMHO is best left to other languages (which I believe we >>>> already >>>>> resolved). >>>>> >>>>> I think the prime use case is really in being able to make sure >>>>> you >>>> get back >>>>> to the same instance, and this I see is orthogonal to the contract >>>> approach >>>>> that details partial ordering of operations. Maybe we could >>>>> explore >>>> this >>>>> approach instead. >>>>> >>>>> Martin. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Jim Marino [mailto:jim.marino@gmail.com] >>>>>> Sent: 12 December 2008 19:54 >>>>>> To: Martin Chapman >>>>>> Cc: 'OASIS Assembly' >>>>>> Subject: Re: [sca-assembly] Conversational services >>>>>> >>>>>> Hi Martin, >>>>>> >>>>>> Comments inline as usual... >>>>>> >>>>>> Jim >>>>>> >>>>>> On Dec 11, 2008, at 6:07 AM, Martin Chapman wrote: >>>>>> >>>>>>> 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. >>>>>>> >>>>>> It looks as if we agree that "conversations," "stateful >>>> interactions," >>>>>> or whatever they are called are important for SCA (I will use >>>>>> "conversations" to describe them). That's good. Also, I think we >>>>>> can >>>>>> accommodate your concerns with some very minor additions to the >>>>>> current conversational model. This is also good given the time >>>>>> constraints we are under and the risks associated with developing >> a >>>>>> completely new model for these types of interactions. It also >>>>>> sounds >>>>>> as if you agree with me that conversational lifecycle should be >>>>>> reflected in the service contract. Others may have a different >>>>>> opinion. For example, Simon has proposed in the context of the >> Java >>>>>> work group that conversational lifecycle may be an implementation >>>>>> detail. I think conversational lifecycle is part of the service >>>>>> contract for the reasons you state above. Taking that position as >> a >>>>>> starting point, I wanted to go into more detail about how I think >>>>>> we >>>>>> can accommodate your concerns. >>>>>> >>>>>> At this point it would be good to outline the semantics of the >>>>>> conversational lifecycle as it is currently laid out in the >>>>>> specs: >>>>>> >>>>>> 1. All operations begin a conversation if none exits. >>>>>> 2. If a conversation already exists, all operations continue it. >>>>>> 3. If an operation is marked with endsConversation, the >>>>>> conversation >>>>>> will be ended after the operation completes. >>>>>> 4. If an operation is called after an endsConversation operation >>>>>> completes, a new conversation begins >>>>>> 5. It is not possible for a conversational service to have a non- >>>>>> conversational operation. >>>>>> >>>>>> From this, I believe it is always possible to determine the >> precise >>>>>> conversational semantics of an operation on a conversational >>>> service. >>>>>> As you mentioned above, in some scenarios it is useful to >> demarcate >>>> an >>>>>> operation that starts a conversation from one that continues >>>>>> it. A >>>>>> while back, we did have a for beginsConversation annotation. >>>>>> Perhaps >>>>>> we could reinstate it with the following broadly sketched >>>>>> semantics: >>>>>> >>>>>> 1. Conversational services have three states: begin, continue, >>>>>> and >>>> end >>>>>> 2. If a service contract has an operation marked with >>>>>> beginsConversation, invocations of that method begin the >>>> conversation >>>>>> lifecycle. Clients must invoke an operation marked with >>>>>> beginsConversation prior to other operations not marked with >>>>>> beginsConversation. >>>>>> 3. Multiple operations on a service contract may be marked with >>>>>> beginsConversation. >>>>>> 4. Methods not marked with beginsConversation or endsConversation >>>>>> continue the conversation lifecycle. >>>>>> 5. It is an error to invoke the same beginsConversation method >>>>>> twice >>>>>> or multiple methods marked with beginsConversation without >> invoking >>>> an >>>>>> operation marked with endsConversation >>>>>> 6. If no operations are marked with beginsConversation, then >>>>>> invocations on all operations will begin a conversation if one is >>>> not >>>>>> started or continue an existing conversation >>>>>> >>>>>> One thing I don't quite understand is your statement that " 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." Couldn't this be handled by >>>>>> existing mechanisms where an operation is not marked with >>>>>> @EndsConversation but the service provider (if written in Java) >>>>>> invokes Conversation.end()? Given this, I think for clarity it is >>>> best >>>>>> to require a conversation to be ended if marked with >>>> @EndsConversation >>>>>> so the semantics are unambiguous. Is there a use case where this >>>> would >>>>>> not be appropriate? >>>>>> >>>>>> >>>>>>> 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. >>>>>>> >>>>>> Thanks for the link but I think this type of approach is probably >>>> more >>>>>> complex than is warranted and, as you mention below, is best >>>>>> handled >>>>>> by specialized implementation types. >>>>>> >>>>>> >>>>>>> 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. >>>>>>> >>>>>> I think the dichotomy between declarative and programmatic is >> often >>>> a >>>>>> false one. For example, activity-based approaches are often >>>> considered >>>>>> programmatic and an analogy is drawn to transactional behavior. >>>>>> However, starting with JEE and arguably before that, declarative >>>>>> approaches to transaction management have largely supplanted >>>>>> programmatic ones for most application use cases. Arguably the >> idea >>>> of >>>>>> declarative transactions was one of the things EJB got right, >>>>>> even >>>> if >>>>>> it got the specific semantics wrong. >>>>>> >>>>>> The current conversational model is declarative and we would do >>>>>> well >>>>>> to keep it that way for a number of reasons. One is to make >>>>>> wiring >>>>>> more fail-safe. For example, if conversation propagation were >>>>>> programmatic, how could a wiring algorithm determine a binding >>>>>> can >>>> be >>>>>> safely applied (i.e. it supports conversation propagation) >> without >>>>>> introspection of the implementation "code" (bytecode in the case >> of >>>>>> JVM-based implementations)? >>>>>> >>>>>> >>>>>>> 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. >>>>>>> >>>>>> Could you elaborate what you are thinking and the use cases not >>>>>> covered by existing mechanisms? >>>>>> >>>>>>> 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. >>>>>>> >>>>>> I'd be interested to see if your concerns with the existing >>>> mechanisms >>>>>> are addressed by the above. If not, can you outline some specific >>>>>> application uses cases we could work through? Having some actual >>>>>> examples (potentially composites) would help us bring these >>>>>> issues >>>> to >>>>>> the fore. >>>>>> >>>>>> Thanks, >>>>>> Jim >>>>>> >>>>>>> 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 >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------- >> -- >>>>> 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 >>> >> >> >> --------------------------------------------------------------------- >> 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]