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