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

 


Help: OASIS Mailing Lists Help | MarkMail Help

business-transaction message

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


Subject: RE: Some comments on definition of operation/group and action


Fred Carter sent:
 
This may turn out to be a meta-meta... comment.  My apologies... 
 
I largely agree - at least as concerning the strict definition of the inter-party protocol. The discussion on transactions is perhaps more to see what you can do with protocol.
 
But I do think we want to have at least some element of conditional or reversible performance of service requests. Though how far it actually goes is up to the service.

 I think that this is all interesting, but somewhat out of our control.  Except by why of defining our space, I'm not sure we need be so concerned with carefully defining these transactions.  It seems to me that we should focus on what it takes to be a business transaction.  In particular, I offer the following observation, with a few specific comments.

I think we need to concentrate on what services/semantics are delivered to the users of the protocol -- callers and services.  I'm not sure the rest of it is terribly relevant.  Specifically,
  • I think we need to recognize that in many cases, for BTP work, the form of recovery is unknown.  Moreover, although it may be knowable by the implementors, I suspect that they may be unwilling to publish it -- it is likely to change over time.   I think we should, again for BTP work, simply concentrate only on our ability to inform the collection of services invoked in a BT (of P fame...) that it went forward or not.  
I agree - in the general case, the service would be offering no more than "if you tell me you didn't want it, I will make it as if you had not asked for these aspects of the operation ..... (which are visible to you), but these effects .... (also visible to you) will still apply" (and there may be all sorts of stuff invisible to you).
  • I think we cannot and should not rely on ACID properties.  Semantically, if I offer a service, I probably make a promise that it's Durable (although that may vary according to my Terms Of Service).  But I do not want to promise that it's Atomic (internally or externally), Consistent (that's my business, not yours), or Isolated (unless there's some privacy contract/semantic that a service and its invokers have).  
Yes - I do not know what you do with the data involved in your service, and if you get in a mess internally that's your problem. But if your service offers (in some degree) to undo/reverse/cancel/compensate if I request, I can build your service into a consistent set of service invocations, even in the case where some of the set do not work as I'd hoped.
  • I think we should be careful to be architecturally neutral.  We are often descending into speaking about coordinators, authorities, etc.  We cannot/should not specify that -- we just to Protocol -- how do I ask to have something accomplished.  
What to call these entities is one of the trickiest bits !   There's something up there sending these messages ! (You can write protocol specs in passive voice, but it gets a bit wordy)
 
Given these, it's my opinion that we're concerned only (in BTP) with collections of services and some mechanism to collaborate on their collected outcome.

I would prefer that we focus on that.  So, we get something like:

  • The Business Transaction Protocol is a vehicle for the coordination of web services.
  • When participating in a Business Transaction, a web service will
    • be informed of it's participation (by inclusion of XXX protocol fragments)
    • be given the unique id of the transaction for reference
    • be expected to respond "appropriately" to requests concerning this BT.
  • A BT will add little, if any, architectural overhead.
In many ways, I think that for at least the first draft, we might want to restrict the notion of a BT to simply a collaborative name id for a collection of web services and a protocol by which to specify it.  
 
Passing around id's, and then expanding the implications of the id later on is a bit risky. If it's just label on a bunch of invocations that can be used for queries now, there will likely need to be another id if, later, we want to say anything about the relationship of the decisions (yes/no, forward/backward, confirm/cancel) that apply to the invocations.

Above that, we could add certain API's (really, web services I suspect) which allow for query of status -- perhaps from a service "back" to the invoker (after, say, some time has passed), or by which the BT may be officially ended.
 

Working loosely, suppose we say that a BT has a id which is a URL + identifier (generally some id that the invoker "knows" to be unique at that URL -- the URL deals with global uniqueness.)

Each service is then tagged as belonging to that transaction.  The services themselves can use that ID to track whatever it is they wanna track.

If we then add some service to the URL portion, invoked services could

  • ask it about the status ("it's been a week, did it finish?")
  • change their status ("I've changed my mind and xxxx is no longer available....")
  • Moreover, as a new service is added, it could add a URL (or other contact point) for push-type messages as part of it's response.
    My opinion is that it would behoove us to make this is a light in weight as possible.  As we define things & momentum builds, we could add more capability.

    Note that the definition above is primarily by way of conceptualizing.  I'm by no means certain that it's complete.  However, I wanted to illustrate a "smaller" undertaking that seems (to me) more likely to be workable in the shorter term.

    thanx/fred

    -- 
    Fred Carter          510.986.3622 (7-3622)
                         mailto:frederick.carter@sun.com (external)
                         mailto:frederick.carter@ebay    (internal)
    Fusion Development/iPlanet Integration Server @ {Sun Microsystems, Inc., iPlanet}
       
     
    Peter 

    ------------------------------------------------
    Peter Furniss
    Choreology Ltd

    email:  peter.furniss@choreology.com
    phone:  +44 20 7670 1679
    direct: +44 20 7670 1783
    13 Austin Friars, London EC2N 2JX



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


    Powered by eList eXpress LLC