Unless there's a transaction manager on the mobile device (which I haven't heard there is), mobile devices can't participate in a coordinated transaction. Also clients don't typically participate in a coordinated transaction unless there are operations on local data (i.e. data managed on the device).
The only thing a mobile device can do without a transaction manager and operations on local data is request the remote execution of a transaction that is completely coordinated off of the device. In this case there's also no way for the client to be sure whether or not the requested transaction completed, unless there's another round of messages. There is a very common misunderstanding of the term transaction, which means the execution of a program that operates on shared data, not the request for such an execution. It seems like this article refers to the request as if it were the transaction. Eric --- Gervas Douglas <[EMAIL PROTECTED]> wrote: > <<In this series of articles, we are looking at how > it is possible to > extend the basic principles of service-oriented > architecture (SOA) to > devices at the edge of the network (such as cell > phones, PDAs and > set-top boxes) so that they can connect to > enterprise-level services > within a network. > > In "Part 1: Thinking Mobile," we described how > interfaces to network > services could be defined and implemented at a level > of abstraction, > regardless of the mobile network or underlying > network protocol > layers. This means that we can "talk" to network > services directly > from any cellular phone that has a standard Java > implementation (Java > ME) without any concern over whether we are using > 2G, 2.5G, or 3G > mobile networks, or whether the underlying network > protocol is iMode, > WAP, or HTTP. > > In this article, we are going to extend the > facilities of our > architecture by adding the ability for devices to > become involved in > atomic transactions. Transactions are vital in > ensuring that all of > the relevant resources that a system provides are > coordinated and > managed so that the overall state of the system > remains consistent. > > The benefits of using transactions can range from > the simple, such as > making sure that your seat at the movie theater is > not double booked, > to the essential, such as making sure that the > correct piece of > medical equipment can be provided to the correct > field hospital in a > disaster zone. > Introduction > > For the architecture we are designing, we need > transactions to be both > distributed and mobile--which, in simple terms, > means that a > transaction represents a "unit of work" between a > set of cooperating > services on the network and over the air. Under a > transaction, either: > > * The unit of work is executed as a whole: For > example, your > airline flight reservation is confirmed and your > credit card is debited. > * None of the actions are completed: Your > airline flight > reservation is rejected because the flight has just > been fully booked, > and so your credit card account is not debited. > > In a SOA, a transaction manager is usually a service > that is used to > coordinate the other services participating in the > transaction. It > does this by creating the transaction context and > then coordinating > the participating services. Normally, this is > implemented using a > two-phase commit model in which a commit is > performed on all of the > participants, or an abort is performed on all of the > participants, > giving us the "all or nothing" behavior that we are > looking for. > > If we are going to implement services such as mobile > banking or > logistics and supply chain applications, then we > need to devise a > method of making our mobile devices capable of being > involved in any > transaction, either explicitly by talking directly > to the transaction > manager, or implicitly through calls to services > that are themselves > transactional. Or, for maximum flexibility, both. > Using Transactions on a Device > > Our mobile SOA has targeted the lowest common > denominator for Java on > devices, namely MIDP/CDLC, which means that any more > powerful > Java-enabled device can also take advantage of the > architecture. When > we took at look at designing in the support for > mobile transactions, > we settled on two sets of interfaces that are used > on the device to > create, abort, and commit transactions, and also to > participate in > transactions. > > We also needed to implement code to manage leases on > transactions to > set time limits on operations. This means that if > parts of the system > fail, we can abort the transaction after a > predetermined amount of > time. For example, if a mobile client becomes > disconnected when your > train goes through a tunnel and the network > connection cannot be > maintained, the transaction manager will abort the > transaction when > the lease expires. > > If the transaction is aborted, all of the active > participants for that > transaction will be notified. As a result your > business services can > release any resources that had been "locked" for the > expired > transaction. To recap: mobile clients can either be > explicitly or > implicitly involved in any transaction.>> > > You can find this tutorial at: > > http://today.java.net/pub/a/today/2005/08/02/mobile2.html > > Gervas > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
