On 19 Mar, 16:22, "jon" <[EMAIL PROTECTED]> wrote:
> 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

Hi Jon

I think with this kind of thing there is a danger of building too much
complexity from the off. In the push to building a service oriented
solution the danger is to rely on too many fine grained messages. As
you know the result is high message count and low performance.

In you test app you have a scenario in mind where you have to
coordinate inserts to a database coming from two different services.
I'm not trying to disuade you from inviestigating this interesting
stuff but do you really need to do that? Can you combine two updates
into a single service and have that service provide the atomic unit of
work.  This is one common strategy for implementing process flows
involving services, i.e. have a service represent an atomic unit of
work and have it mange any transactional semantics implied by the work
it has to do. I think maybe this is what you are hinting at when you
talk about having business logic reside elsewhere.

It would be perfectly possible to implement an asynchronous messaging
binding for SCA, for example, using SAM. This might help you separate
GUI/process flow from atomic business logic. The side affect of this
kind of architecture of course is that if you need to scale your
solution you just start more services on the end of your message
queue. Anyhow just thinking aloud.

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