[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]