On Thu, 2006-11-23 at 15:46, Mark Baker wrote: > On 11/23/06, Andrew S. Townley <[EMAIL PROTECTED]> wrote: > > On Wed, 2006-11-22 at 20:30, JP Morgenthal wrote: > > > I came up with a test to determine if your architecture is SOA > > > compatible. Let me know what you all think of it! > > > > > > > > > > > > Your architecture is SOA-compatible if you can change the service > > > provider without impacting any of the service consumer's operations. > > > > > > > I think that gets to one of the biggest parts of it: true loose > > coupling based on well-defined data formats and exchange operations. > > Bravo - you guys are *totally* on the right track here. Keep it up. > > Can you come up with one or two (or more) examples of "well-defined > [...] exchange operations"?
I know where you're going with this particular leading question, but I'll have a go anyway... ;) As I have mentioned previously, I am somewhat attached to the view of implementations of SOA as a community under established legitimacy principles (hopefully mutually-agreed, but they can be specified or mandated as long as everyone is willing to accept them). What these legitimacy principles do is define the rules of the community. In doing so, they create (or at least strongly influence) the structure, or architecture of the community. One of the aspects of this structure is to define norms or codified rules (laws) for how members of the community interact. For example, in polite society, when you ask someone for something, you're supposed to say "please", and when you get that something, you're supposed to say "thank you". This is also kind of an interesting example, because there's no law that says saying "please" and "thank you" are part of the protocol of asking someone for something. It is something that you get from either a) your parents beating it into you as a child, or b) observation that people are more likely to give you things if you use them. Taking a bit of license here, but what happens when you don't observe the proper protocol when asking for things? Eventually, people stop giving them to you. You aren't playing by the established (albeit somewhat implicit) rules of the community, so eventually nobody talks to you, you get upset, leave the community and start your own community of people who don't say "please" and "thank you" to each other. Getting a bit closer to technology implementations, if I'm wandering around Dublin and need to ask someone directions on how to get to the Guinness Storehouse, I'm probably going to get some kind of answer. It may be that I get street names, street indices (take the first left, go down past the Spar, then take the second right, etc.), or someone may draw me a map. However, if I get street names in Irish, and I don't speak Irish, they're just meaningless sounds because I don't know how to translate them into the words written on the signs (provided that they're really still there anyway--if you've been here, you'll understand). The point here is that if I only know how to ask the question and get the response, but I don't understand what the heck they just said to me, I'm still a long way from my "free" pint of Guinness and the expensive, plastic paperweight (what? There's a tour???). This is the reason that I said well-defined data formats *and* exchange patterns. Unless I'm just the taxi driver who doesn't care who you are as long as you know where you're trying to go, I need to understand the data I get from the exchange. The Web (pick a version, any version) isn't SOA, not because of REST or WS-*, but because there's no agreement on both the exchange pattern and the data you're going to get back. The representations of state being passed around in REST still need a context in which they become meaningful. Not that needing context is bad, because everything needs context. I know you can say, "I only want maps, please. Oh. No maps, huh? Ok. Thanks." and walk up the street, but that isn't terribly efficient. However, if I know that I can get SVG maps from mapquest for an address specified in a profiled subset of OASIS xAL POSTed to a specific "address-finder" URL, and I know that I can POST a purchase order for books expressed in UBL to Amazon and get an UBL invoice back (or the Location of my order so I can do all sorts of other things), I might have the basis for a REST-based SOA implementation. The WS-*-based implementations of SOA do at least allow the definition of the input, output and fault messages as part of the interface, but then the invocation mechanism might vary, e.g. SOAP/HTTP, SOAP/JMS, SOAP/WS-RM, SOAP/insert-custom-protocol-here, as well as the operation, e.g. mapIt, getMap, whereTheHellAmI. But, of course, they all *mean* the same thing, right? You know, like semantically? In either case, you don't have a unified set of fundamental architectural constraints defined for the community (SOA). Taken on their own, you have various, generic capabilities, but they aren't a coherent and purposeful community. To do this, you need another layer of design and specification (the legitimacy principles). That doesn't mean the community can't evolve and its membership change in interesting ways, but it does mean that once you're dealing with the community, you know what to expect (all pubs sell Guinness). Without the agreements, there's no community; without the community it's just technology. -- Andrew S. Townley <[EMAIL PROTECTED]> http://atownley.org
