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
The solution may also be problematic because of locking issues during
a 2PC inside pgsql which I have not thoroughly investigated.
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!
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....
You received this message because you are subscribed to the Google Groups
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at