Soa And Loose Coupling
Soa And Loose CouplingCouplingAndCohesion -- with an emphasis on lowering the former and raising the latter -- have long been foundations of qualitatively "good" StructuredProgramming and ObjectOrientedProgramming. ServiceOrientedArchitecture has raised "LooseCoupling" to buzzword status, as the best practices of SOA supposedly encourage low or "loose" coupling. In other words, dependencies between interconnected services are presumably minimised in a properly designed ServiceOrientedArchitecture. Of course, the dependencies between interconnected systems or subsystems should be minimised, wherever and whenever possible, in general. This is not unique to ServiceOrientedArchitecture, and is a fundamental tenet of SoftwareEngineering and indeed engineering of any kind.
Use of XML is sometimes mentioned as being a key ingredient in achieving loose coupling in an SOA. When we talk about systems being loosely coupled, we mean that there are few dependencies between them, and/or the dependencies are arranged in their technical details such that certain kinds of changes to the subsystem that implements an interface can be tolerated by clients without requiring changes to the latter. The only technical aspect of XML-based interaction that seems to promote loose coupling is the fact that information can be added to the output of interfaces, which will be ignored by unmodified clients, and perhaps conversely, that additional inputs accepted by the serving system can be defaulted if not supplied by the client. (Kind of like adding optional parameters to a function; callers don't have to be modified.) This kind of decoupling is eased by the use of XML, but can also be done (though typically it hasn't been) using other, more compact representations. Other types of changes--deletion of information in inputs or outputs, or changes in the meaning of inputs and outputs--still require changes in both clients and servers.
If not XML, what other mechanism has received widespread acceptance, and have the benefits of embedded semantics (or is semantics unimportant?). A question and not a challenge -- dl DeleteWhenCooked
I would venture to say that RPC is a good example. See http://www.opengroup.org/onlinepubs/9629399/toc.htm. I'm hesitant to mention ODBC and JDBC as examples, but the combination of these and SQL could be seen as (very) roughly similar, with the full recognition that this may be subject to considerable debate. -- DV
XML does not have "embedded semantics". This is the most egregious snake oil that is sold by some XML proponents. Semantics is critically important, but it's not carried by data. You cannot exchange messages via XML, or any other transport medium, without having an a priori agreement at either end about what the data means. Short of a hypothetical AI system, the most meaningful XML tags in the world won't allow the receiving code to simply 'understand' the meaning of your XML message--thus there's no useful way in which you can say that semantics are embedded in it. -- DanMuller
Dan, various industry groups (e.g. health, accounting) have come together to define the "vocabulary" appropriate for their domain. And lots of these are using XML as a base. Yes you are correct in the absolute sense, and yes I "invented" "embedded semantics" on-the-fly, but would you agree there is merits still in using XML, based on the "imperfect improvements" to exchange messages? -- DavidLiu
I have never seen any convincing arguments for technical merits of XML over various other past and hypothetical data exchange representations, and there are at least a couple of ways in which XML is inferior to what has been used before. XML's large momentum is, however, an undeniable asset, important because of social issues. I don't know what you mean by "imperfect improvements to exchange messages". -- DanMuller
In a late 05 paper "Introduction to Building WindowsCommunicationFoundation Services" at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnlong/html/introtowcf.asp, ClemensVasters? contrasted the WCF way of messages with older mechanisms such as those used in DotNetRemoting (section title "RPC or Messaging"). Amongst other things, he stated the "liberating" effects of the "new restrictions" of "doing without pass objects by reference or pass callback delegates".
RPC and Loose Coupling
From above: "I would venture to say that RPC is a good example. See http://www.opengroup.org/onlinepubs/9629399/toc.htm"
If I am not mistaken that was the now defunct DEC Distributed Computing Environment stuff. And it is synchronous. It does agree with what you said later that "Synchronization has absolutely nothing to do with loose coupling".
I am not sure whether I understand.
Asynchronous messaging is indeed valuable, nobody has said otherwise. It's also not new, e.g. there have been RPC systems that optionally supported it (although arguably, asynchronous RPCs look a lot less like procedure calls than synchronous ones). It is not traditionally part of what was meant by 'loose coupling'--a term that was applied to colocated software long before it was applied to distributed systems. I note that some of the articles mention asynchronicity as one of numerous characteristics of loose coupling, but that's the first time I've seen this -- it's a recent addition, and I would argue that it rests on a completely different meaning of the phrase.
Particularly amusing to me is the notion that stateless APIs are desirable. This is very old news, which was pretty well known when procedural programming ruled. It was lost during the OO frenzy, and is now being rediscovered. Or perhaps some conniving graybeard saw a chance to inject this good, old idea into new discussions under cover of trendy new acronyms. Power to him. -- DanMuller
If we take the evolution of WebArchitecture from XmlRpc to SoapProtocol, do we find RPC type usage becoming more confined to specific problem domain?
People interested in a bit of history of the various RPC derivatives may want to look at the link at http://www.dsps.net/History.html for context.
References
EditText of this page
(last edited November 26, 2014)
or FindPage with title or text search