What happens when a customer asks for a simple new bit of functionality? Do you have to execute changes on four different systems, test each in isolation and in combination, involve a separate testing, infrastructure and operations team?
If so, according to Johannes Brodwall, your architecture is probably not service oriented. In this blog entry
, Brodwall examines the real meaning of coupling and how it relates to SOA. He also sets out to define SOA by explaining what SOA is not.
What a lame posting.
He spends more time talking about what he plans to talk about than what he actually talks about. And in the end, he doesn't even do what he says.
I know Johannes Brodwall as a speaker and a great contributor to the norwegian XP- and Java communities, and I think this may not be representable for what his is good for.
Maybe he should have left this posting as a draft at this time and worked some more on it before publishing, because it looks like a draft, with logical gaps and missing pieces.
Seeing another comment on "coupling" makes me feel sorry for that poor horse that's been beaten almost to death; that good ol' "low-coupling" work horse (and that forgotten pack mule, "high-cohesion").
But, it is true, people had gotten carried away with de-coupling (many misunderstanding it). And, true, software dependencies (and hence the degree of coupling) can be found via tools / metrics (compile-time dependencies the easiest to identify). In the post, the "implicit coupling" described (ie, passing strings between two SOA requests), could be any type of very traditional pre-SOA data coupling, eg "external coupling" or "control coupling". Which are still examples of a highly-coupled system with low-cohesion. So, a very traditional example of a bad design.
But it's good to re-contextualize the term using the modern technologies.
Somewhere along the way, this may have been forgotten... perhaps a confusion of "dependencies" (eg compile-time dependencies) w/ "coupling". Not only w/ SOA, but especially w/ the advent of IOC... At one time coupling was (as described in the article) "a single change requiring an update to two places"(*), degenerating into "a single change requring an update anywhere"... So all the "coupling" got thrown into an XML config file (the thinking being that it's not "code", so that "update" doesn't count...?)
(*) "Coupling" could more accurately be defined as the degree to which two modules depend on each other... A single change requiring an update to both just being a side-effect of the coupling.
Implicit coupling is not necessarry as bad as you point out, Johannes. I think loose coupling is a lot better than having to change both service endpoints (or more if there are more than a single client). You do get the compile-time decoupling by the string-string approach and that is a helluva lot better than no coupling at all.
Also, you can decorate the payload for ingoing and outgoing payloads without breaking the public api and this is damn important imho. If for instance you pass a payload which is xml-based then you can use xpath queries on all endpoints and no "new features" will break the existing service contract.
Like we talked about on Tuesday: Yeah, there are ways of using an implicit interface so that you can avoid breaking the clients when the API is upgraded. There are ways of doing this for WebServices, database schemas and even RMI. And yes, this is a good thing. As a matter of fact, you have reduced the coupling.
But in my experience, it is easy to create an implicit interface that is also tightly coupled, either by the way it is used (e.g. Axis based web service clients), or by the nature of the change (e.g. CustId field renamed to CustomerId, Name field split to FirstName + LastName).
My point is that coupling is about "when does a change propagate". If you require your clients to change, it doesn't matter that you're compile-time decoupled.
In the text you, like most I think, define services to be distributed. I do not understand why everybody introduce that limitation. You can implement a one JVM system in that uses business oriented “services” (interface programing) that locates the service implementors at run or call time. I do not see a fundamental difference in that architecture and the distributed SOA.
Equally I do not think you should consider a architecture as SOA if you have hardcoded the impleremtor of a webservice even if it is business oriented and loosely coupled otherwise…
Perhaps it is sufficent to have a broker between the service requestor and implementor?
That is when you truly have decoupled the system, if the implementor and requestor runns in the same JVM or not does not seem that relevant. (in theory :-) )
In the text you, like most I think, define services to be distributed.
You're right. I expect SOA services to be distributed. I think in order for the expression SOA to make any sense, the services have to be distributed. The reason for this is the way I see SOA, the technical services are the same as the services you provide to your customers. In order for you customers to use the services, I think would have to be distributed.
However, this is not in general a good idea for integration internally inside an organization. In that case, your suggestion of internal services is much better. But I wouldn't call it SOA. Just plain old good design.
Does that make sense?
I assume that you define "customer" as coustomer to your business. I agree that
the technical services are the same as the services you provide to your customers.
but in system architecture, I rather think of customer to the service so I definitely think you can have a local service.
(A plugin architecture might probably be considered SOA as well, the service is just delivered as a jar instead of a remote interface). I also very much appreciate the recursive architecture you can create with local SOA.
I assume that you define "customer" as customer to your business. I agree that
the technical services are the same as the services you provide to your customers. but in system architecture, I rather think of customer to the service so I definitely think you can have a local service.
One big waste in our industry is creating stuff for imagined "internal customers" which turn out to have no real business value. The promise of ("business") SOA is to get away from that. By subverting the message to accept local services as SOA, we lose the grounding to real, measurable, external business value.
If you're creating something for external consumption, completeness and stability are key characteristics (think Contracts). If you're creating something for internal consumption, you want flexibility.
In both cases, you want low coupling - but this is something that is universal about good design. If you want to use "SOA" to mean simply "good OO design", there is nothing stopping you. But there's very little value left in the definition.
What is wrong with calling a Plug-In Architecture "a Plug-In Architecture"? Why do you need to call it SOA?