Hi Berin,
Berin Loritsch wrote:
> The compelling example that was given in WSDJ was a very simple web service to
> find out how much any book from Borders would cost in any currency. The cool
> part of SOAP and therefore WS is the support for transactions. You can compose
> larger WS from smaller ones. The example used two existing WS--one from Borders
> that returns the price of a book (specified by ISBN number) in US currency, and
> one that converts from one currency to another with the current exchange rates.
> The web service that was written took markup that specified the ISBN number and
> the resultant currency type you wanted. The web service would create a transaction
> that spanned the two other WS calls. First it accessed Border's WS and got the
> US price. Then it accessed the exchange rate WS to find the price according to
> the desired currency.
When you say transaction here, are you using the term in the technical
sense?
How does the transactional context propagate across varying resource
types? For example, if one web service is executing an EJB
implementation how do web services help the transaction to cross
boundaries to COM+ objects running under MTS? Are web services a better
integration technology then what exists today? Has someone built
products that address cross app server interoperability concerns such as
the one I mentioned above? Or are web services meant to be used only as
a simple data exchange mechanism?
-Umar.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
