[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-bp] FW: Differences between an operation and a BT
Jean-Jacques, Excellent posting. Clearly what people are wanting is a sweetspot where they can use ebXML and webservices together. I have no reservations in saying that BPSS provides the business-centric model that is applicable for providing transaction based solutions. Snag is when you look at the BPEL alternate world - with compensation handlers, et al - it looks suspiciously like re-inventing a database system, stored procedure language, and distributed interactions like Tuxedo, using XML, some wire and bits of black tape. It's certainly nothing any average business analyst is going to want to learn into IMHO. So how to make these two worlds co-exist? One way is to work with the ebSOA team - I posted something there today saying that V3 of BPSS could be feature enabled to support the ebSOA architecture, and specifically - using Linking and Switching, choice points and state management as a neutral external service that directs how both BPSS and WS components can work. That's one view. Also - if you view the WS as just an alternate transport mechanism to ebMS - then another path is to somehow (not easy) create WSDL definitions that emulate ebMS. These would be a limited subset - but could work. If you see what I've done in the BPSS model - it uses Exchange Profiles - which you name - like - Normal, ASAP, Required, One Day, and so on - and then you set the transport characteristics for that profile entry. You then deliver a transaction and pick an exchange profile for it. We could easily create WSDL exchange profiles that emulate a subset of ebMS - and these could be used for non-critical paths in the BPSS. A third option is to specify WS calls to specific service offerings that do something. So you may send someone a ProductAvailabilityRequest as a transaction via ebMS as normal - but add an annotation to it - with a WS call-out - to be used to action that - something like - "CheckWareHouseStocklevel" with all the necessary WSDL glue - that is then used by the receipient to get the answer... again that interaction model would have to be well specified and the use case firmed up. Some ideas to think about - but basically I'm reinforcing what JJ is saying - I believe wholesale changes to BPSS should be a last resort. First we need to see use cases and value propositions that make sense - then determine what extensions can support those. BPSS looks very good right now for its intended mission - and our job I believe is to educate the world to this with outreach, tutorials, teaching - so people can start to take advantage of it to document their business problems and ultimately deploy software to run those patterns. Thanks, DW ----- Original Message ----- From: "Jean-Jacques Dubray" <jeanjadu@Attachmate.com> To: <ebxml-bp@lists.oasis-open.org> Sent: Tuesday, May 25, 2004 11:29 AM Subject: [ebxml-bp] FW: Differences between an operation and a BT Had some problem with email yesterday. -----Original Message----- From: Jean-Jacques Dubray Sent: Monday, May 24, 2004 12:06 PM To: 'monica.martin@sun.com' Subject: FW: Differences between an operation and a BT Did you get this message? -----Original Message----- From: Jean-Jacques Dubray Sent: Monday, May 24, 2004 9:37 AM To: Monica J. Martin Cc: ebXML BP; kpetrop@01P.gr Subject: Differences between an operation and a BT WS Collaboration Made of several operations without Made of several BT with an Explicit relationship to each other explicit relationship (chor) Does not require a BSI or Agreement Requires a BSI Mechanisms Requires "negotiated" agreements Operation BT Req, Response, Fault* Request,Response*, Fault* No state alignement protocol Business transaction protocol Directed (A->B) No direction specified (BTA) Looking at this set of properties it is legitimate to ask the question whether we want to make an operation invocation a BT (it clearly looks like a subset). However, it is not because we can do something that we should do something. This question is as legitimate (not more) to ask whether a CORBA call or an RPC should be part of a collaboration. I don't think I would find many people asking for invoking a method from a BPSS. The reason why this question is relevant is because, WS is an internet ready technology and many businesses may decide to expose a If we make an operation look like a BT we would a) bring confusion, "so why do I need all this stuff if an operation IS A business transaction". Transaction is about state alignment (not rollback/compensation - rollback/compensation is a convenience mechanism to serve state alignment). A web service operation does not give you any kind of state alignment guarantee. ebXML BPSS and the ebXML architecture has been carefully designed and tested to provide state alignment capabilities via the concept of signals. Let me know if you need an explanation on this (the short version is that in the WS, only the consumer of the service knows the outcome, that kind of works for one of services like "creditCheck" where the interaction does not depend on previous states being reached. Imagine a world where we carry out interactions without being sure of the past????). A web service operation by itself CANNOT guaranty state alignment in any situation. b) we will have to hack BPSS pretty much everywhere to explain that a operation BT does not work like a BT - cannot be used in any order (so we have to specify the roles somewhere) - cannot be changed via "substitution set mechanism" - cannot be augmented to use a business transaction protocol - use a different "CPP/A" mechanism - different exception mechanism (technical failure) -... Making an operation a BT will require that we annotate EVERY aspect of BPSS to specify how this works with the operation BT pattern. It will also limit our ability to use other WS stack spec as we see fit. I recommend that we keep operation and BT separate and create an operation activity which has its own behavior totally independent from the BT behavior. I recognize that this is a hybrid approach, but we are dealing with technologies that had and will have different paths. JJ- -----Original Message----- From: David RR Webber [mailto:david@drrw.info] Sent: Monday, May 24, 2004 9:04 AM To: Monica J. Martin Cc: ebXML BP; kpetrop@01P.gr Subject: Re: [ebxml-bp] Webber 5/23/2004: Laura Project Progress in Europe Monica, Thanks I'll contact Kostas direct and provide input back on what I find out. DW Quoting "Monica J. Martin" <Monica.Martin@Sun.COM>: > David RR Webber wrote: > > > http://www.lauraproject.org/project's%20description.html > > <http://www.lauraproject.org/project%27s%20description.html> > > > > Does anyone have contact with this group? > > > > Would be great to get their input into our BPSS work. > > > > DW > > mm1: David, I had seen a post in November 2003 from Kostas Petropoulos > (kpetrop@01P.gr) on the ebxml-dev list. Your post reminded me today. > I've attached the relevant email about the project I had and also cc: > Kostas to respond on this project to set up B2B adaptive zones in > Greece, Germany, Bulgaria and Europe. We'll see what we can find out. > Can you take an action to follow this through? Thanks. > http://drrw.net
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]