Hi Anne, >Perhaps we might disagree on this point, though: >Tight coupling should be avoided in SOA design.
Not really. I would agree that the best application of an SOA is to share data across software domains in a loosely coupled manner, but SOA is not a technology and therefore SOA designs aren't constrained by it. If using tightly coupled services meets a business requirement, there shouldn't be any reason not to use them that way. In our widely publicized Credit Suisse SOA case study, for example, a service on a mainframe calls a service on a Windows platform in the middle of an IMS transaction to obtain data needed to complete the transaction. Of course the request has a very tight time window, I can't remember the exact number of milliseconds, so that it doesn't tie up database resources on the mainframe, but it works well enough to have been in production for a few years now. This isn't a 2PC example since the request for data from the Windows platform doesn't update anything there, but it is what one would probably call a tightly coupled service invocation. At the moment we don't really have an case in production of services using 2PC (at least not that I'm aware of) but we a lot of customers ask us about this, especially those interested in joining mainframe resources into transactions involving off host resources. I would just not rule this kind of thing out of scope for SOA, since it meets some customer requirements, although I'd agree with your recommendation in the context of best practices overall. To use 2PC in an SOA you would want to take careful control over the deployment environment to ensure it would work correctly, though, that's for sure. Eric --- Anne Thomas Manes <[EMAIL PROTECTED]> wrote: > Note that Patrick did not say *all* services should > be asynchronous. He > said: > > "Many services should be reliable but asynchronous." > > I'm with you, Eric. Some service interactions should > be asynchronous, and > some should be synchronous. Some require reliability > semantics; others do > not. Some require transactional semantics; some do > not. > > My comment was that 2PC transactions should not span > loosely coupled > connections, which I think we are also in agreement > on. From my perspective, > if a service interaction requires 2PC transactional > control, it isn't > loosely coupled -- it's tightly coupled. > > Perhaps we might disagree on this point, though: > Tight coupling should be > avoided in SOA design. > > Anne > > On 2/24/06, Eric Newcomer <[EMAIL PROTECTED]> > wrote: > > > > Hi Patrick, > > > > I believe the answer is, like so many things in > SOA, > > that it depends on what you're doing, and what > your > > requirements are. > > > > If you look at what we're doing in the WS-TX > > commmittee at OASIS, for example, we are offering > an > > open, pluggable model that supports both 2PC and > > compensation based protocols. > > > > I would definitely say that the industry needs to > go > > beyond that, and Mark Little and I and others have > > proposed an extended transaction model in the > WS-TXM > > spec in WS-CAF (also at OASIS). This is an > example of > > a very broad, asynch/synch protocol capable of > tying > > together transactions across multiple software > domains > > and communication paradigms. But I don't think > the > > industry really needs this kind of thing yet. > > > > So that's why we are focused in WS-TX on nailing > down > > the basics, including an interoperable 2PC > protocol > > and a long running activity model that uses > > compensation. Both are driven by a common > coordinator > > which can be further extended with additional > > protocols. I hope to get some of that work > started > > again in the relatively near future. > > > > I believe it is equally incorrect to say that all > > services are asynchronous as it is to say that all > > services are synchronous. The world needs both in > > some significant measure, perhaps something like > > 50/50, and therefore so does SOA. > > > > That anyway is the assumption we're working on in > > WS-TX. > > > > Eric > > > > --- "Logan, Patrick D" <[EMAIL PROTECTED]> > > wrote: > > > > > From a different thread on mobile, etc.... > > > > > > "The Jini transaction spec basically leaves it > up to > > > the participating objects whether or not to > enforce > > > 2PC semantics. Again, this is fine as long as > you > > > do > > > not need to recover update operations against > > > multiple > > > resource managers. While this provides greater > > > flexibility for developers, it also introduces > > > additional risk. This is a classic debate in > the TP > > > industry - how much to leave to the programmer's > > > control and how much to guarantee in the > software > > > system." > > > > > > I've generally considered SOA and 2PC to be > > > antithetical. i.e. I would > > > want to isolate and/or bury 2PC. Many services > > > should be reliable but > > > asynchronous. We need to enhance our > understanding > > > and implementations > > > of compensation. > > > > > > Am I wrong? > > > > > > -Patrick > > > > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > > > > > > > > > > > > > > Yahoo! Groups Links > > > > > > > > > > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
