On 15 Mar, 20:24, "jon" <[EMAIL PROTECTED]> wrote:
> Hello list,
>
> This is more of an architecture question as it generically relates to
> SOA, but I am interested in accomplishing this via PHP SCA and would
> like to run it by the group. If you have any resources related to this
> issue and any possible PHP implementations out there, please forward
> along (it is also specific to SOAP and not other transports that SCA
> is interested in abstracting).
>
> I am interested in writing a transaction coordination service to
> manage distributed transactions in a PHP SOA environment.  As recent
> threads have indicated, PHP SCA currently has limited access to SOAP
> headers where normal WS-* standards relating to transaction policy and
> context would be transported. In lieu of that messaging framework, it
> would be possible to pass around context to each service call and the
> transaction service calls (though a pain).  Assuming the transaction
> context is available to each service needing to be a part of a
> transaction, and can register appropriately with the coordinator, what
> is the best implementation of the actual distribution of the
> transaction using SCA PHP and an open DB platform like postgres or
> mysql? I have had two ideas, the first of which fails, the second
> seems a bit hackish:
>
> 1) Use postgresql >8.1 two-phase commit feature. Each service that is
> part of a business process has access to the database, and prepares a
> transaction to the DB (given a context from the coordinator it
> prepares to the DB with a known transaction ID). When the business
> process is complete and all services have completed, the controlling
> logic that initiated this business process tells the coordinator to
> issue the final-stage commits for all the prepared transactions that
> took part in the overall transaction (or rollback if any of the preps
> had failed earlier).
>
> This solution is problematic in that if two services need to prep
> transactions to the same DB and, say, the second transaction is
> inserting information dealing with a foreign key referencing the first
> transaction's inserted data, the constraints fail the DB insert during
> the second service's prep (the nature of a 2PC situation in this
> scenario).
>
> The solution may also be problematic because of locking issues during
> a 2PC inside pgsql which I have not thoroughly investigated.
>
> Next solution:
>
> 2) Any service needing to take part in a distributed transaction for
> writing and updating to the same DB, is handed a context from the
> coordinator.  Each service formulates its SQL, packages it up somehow
> and sends it back to the coordinator service which does not run the
> SQL, but simply queues it up (storage of the queue could be disk,
> memory cache or DB). When the logic controlling the business process
> has completed, it tells the coordinator to commit. The coordinator
> then loops through it's stored SQL for that transaction context and
> wraps all calls in a transaction, returning the result of that entire
> commit to the process which is handling the business process logic.
>
> This solution seems hacky to me on a kind of gut level but I am not
> sure how to accomplish a distributed transaction scenario in PHP
> across several services.
>
> Any feedback or resources is appreciated!
> thanks,
> jon
>
> PS: background context for thinking about this solution:
>
> I am working in an organization that has several PHP applications
> supporting the website as well as customer relations management (some
> off the shelf open source apps, and some built in-house). It has
> become increasingly difficult to maintain sane development cycles of
> each application when shared PHP code exists for accessing customer
> information... even when packaged as a standard set of 'libraries',
> each application starts to rely on a particular version of the library
> and deployment and development becomes increasingly difficult.
> (shared customer information access is only one example). The
> organization has increasingly requested significantly more integration
> between these PHP apps to provide a more seamless user experience as
> well as a better data accessibility and management across apps to
> customer support and admins. So -- i've been researching SOA in PHP.
> We aren't prepared as an organization to jump to a vendor for SOA
> support with a particular technology (J2EE/WebSphere (or others), or,
> gasp, .NET) but we do need some of the things these vendors would (i
> imagine) help provide including distributed transaction implementation
> and I'm increasingly wondering if a LAMP stack is up to this task....

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


--~--~---------~--~----~------------~-------~--~----~
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