On Mar 19, 6:29 am, [EMAIL PROTECTED] wrote:
>
> Hi Jon
>
> Sorry this is a rather tardy response. I've been out on a few days
> leave. You raise some very interesting points here. I have to admit up
> front that I'm not a distributed transaction expert and also that we
> haven't thought about this in detail in PHP SCA/SDO yet.
>
> First a point of clarification. It seems from your note that you are
> interested primarily in the ability to share a transaction context
> amongst distributed applications (as opposed to distributing a
> transaction spanning multiple transactional resources). Is this the
> case? If so then I guess you still need to generate a global
> transaction id in order to share this amongst the client application
> but that at the data resource there is only one transaction with many
> clients providing updates to that transaction. Is that right?
>
> This seems to fall between you suggested solutions 1) and 2) (maybe
> I'm missing something?) in that you could rely on an RDBMS with XA
> capabilities to manage a transaction ID for you but you still need to
> share that transaction ID between participating clients. You also need
> to know when the transaction should be committed or rolled back of
> course.
>
> Having said this you still end up having to do some  work yourself,
> I.e. I've not come across any off the shelf PHP transaction
> coordination implementation. Some work has been done in the web
> services space, for example, several companies created a set of specs
> for supporting the coordination of distributed actions at the WS
> message level (http://www-128.ibm.com/developerworks/library/
> specification/ws-tx/). But you would have to provide some kind of
> implementation. Maybe the Axis PECL extension will start to provide
> some of this but I haven't seen anything yet.  A short term solution
> might be to provide a service which interacts with the database and
> accepts the transaction id as a parameter to CRUD operations and
> provides interfaces for starting, and committing the transaction.
>
> It sounds, from your "background" piece at the end, as if you are
> starting to think about how to apply SOA principle to your application
> suite.  Maybe some of this thinking will allow you work around the
> implementation of complex distributed transaction support by pulling
> the distributed parts into common services. This is not always
> possible of course.>From an SCA point of view clearly we need to provide 
> better support
>
> for managing the details of the transports provided. As you may have
> seen from the mail trail SCA more widely defines a system of policies
> and intents. In this case we would be interested in understanding how
> those related to transactions can be applied to PHP SCA. No progress
> has been made here yet but your experience of trying to do this could
> be really useful here.
>
> Regards
>
> Simon

Thanks for your response Simon,

> First a point of clarification. It seems from your note that you are
> interested primarily in the ability to share a transaction context
> amongst distributed applications (as opposed to distributing a
> transaction spanning multiple transactional resources). Is this the
> case? If so then I guess you still need to generate a global
> transaction id in order to share this amongst the client application
> but that at the data resource there is only one transaction with many
> clients providing updates to that transaction. Is that right?

Yes, that's right... The applications (and associated services in a
SOA solution here) may or may not have their own transactional
resource (some write to their own DB or backend for example, but many
services would be dealing with the same shared resource, usually a
RDBMS).

I have mocked up a transaction coordination service with SCA and a
couple of "middle tier" services that do very granular inserts (my
"solution number 2"). A top-tier script calls the transaction service,
gets a global ID and that is passed around to the middle tier services
as they do their work. Currently the logic for deciding to commit or
rollback resides in the top-tier script and that decision is passed to
the transaction service. (each transactional resource would need it's
own coordinator and be composable in such a way that they can take
part in a more global cross-resource transaction, but at this stage,
I'm just trying to deal with one transactional resource within one
business process)

This all works as an early proof-of-concept, but I have realized that
my current implementation is unworkable because of the synchronous
nature of the PHP SCA implementation and how I've used it to make
calls. To execute only two inserts across these coordinated services,
about 6 SOAP messages/responses have to be delivered. Because of
synchronousity, only 1 SOAP message or response is being sent at any
one time within the whole flow of the business process. (ex: top tier
calls the transaction service, then waits for response. Top tier then
calls middle tier service 1 to do an insert and waits for response. In
order for middle tier service 1 to complete it has to coordinate with
the transaction service so it too sends out a SOAP message there and
waits for response, finally responding to top-tier which can then
proceed, etc...). (This is all running under Apache with fastCGI)

All of that waiting for SOAP response and doing it one at a time means
quite a delay to do a simple two-table insert. In comparisons with a
single-tier solution (all logic and DB access in one small script) the
performance differences between my tests on my lowly dell workstation
are significant (our production hardware would be much more adept, but
early results in this solution aren't tractable i don't think).

I am currently thinking about ways to go asynchronous where possible
(perhaps using a delivery queue in a kind of publish/subscribe model
for messages that don't require response... or somehow coordinating
asynchronous responses)... perhaps having a top-tier PHP script (or a
more architecturally sound solution where top-tier is only for user
input and GUI creation, and having all business logic reside elsewhere
so it can be composed more easily) push requests onto a queue (these
requests would detail what service needs to be called and the
associated data), another process would then read through the queue
and use SCA to make the requested calls. Still investigating....

jon


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"phpsoa" group.
To post to this group, send email to phpsoa@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.co.uk/group/phpsoa?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to