The Large Hadron Collider was created to help unlock the secrets of the universe. And also to create a working SOA implementation. (SOAFacts.com)
In a recent all-things-technology dinner conversation with a friend and developer extraordinaire Rashid, we talked about his recent purchase, Thomas Erl’s Service-oriented architecture: concepts, technology, and design. During this discussion he rightfully pointed out how virtually any and every distributed system is being dubbed “service oriented” raising a great point that since a lot has been said about “what SOA is?”, we should now talk about “what SOA is NOT” since this might be a able to clear things up as compared to, if it walks like SOA and talks like SOA... Hence I figured a typical non-SOA conversation may go as follows.
RealWorldPHB: “Do we have service oriented architecture? I have been hearing good things about it lately and the new partners really prefer it. Let’s go and buy one SOA or do they come in bulk?”
PerpetuallyPleasingIncompetentArchitect: “Of course we do have SOA sir, we are using web services for a long time, ahead of the curve!”
RWPHB: “Great; so we promote reuse, share contracts and schemas, do all those good things?”
PPIA: “No no, that’s too much work. Instead we share the dll’s and email it to our partners as soon as we sign the contract so they can build according to the specs. You gotta have specs for SOA”
RWPHB: “Even better; who cares about interop, right? If they have their SOA in order, they should be able to talk to us!”
PPIA: “Yessir!, you are right. We are loyal to our platform and we try to enforce uniformity, its better this way. Also our services share one database to ensure concurrency and integrity; someone called it violation of autonomous service principle and a bottleneck but we got rid of him!. We also bought that expensive SOA hardware solution and matching software suite to make sure our SOA works fine”.
RWPHB: “Glad you got rid of darn naysayer, these people upset me!. Anyways, so when we release the API update next month, how is going to work in SOA?”
PPIA: “Well, we want everyone to strictly follow our standards so we made sure our SOA does not allow any versioning. All 2000+ partners will be informed on deployment night to update their interfaces or they won’t be able to use our services. Now this is iron SOA as in iron fist!. I should patent this term.”
RWPHB: “Not sure what that means but it sounds good! I am going to tell board of directors we have SOA, woot!”
Now I should mention as a disclaimer that above mentioned conversation is a poor satirical attempt on my part on general state of SOA. Any similarity to actual persons or SOA’s, living or dead is purely coincidental. And that if you hear any such conversations in the corridors of power, hide! (No not really, educate please).
To make sure that you don’t have one of these conversations, let’s design with SOA tenants in mind. If this sounds too fancy, a simple breakdown of what is NOT SOA would be as follows.
-
Boundaries are Not explicit
-
Services are Not Autonomous
-
Services do Not share Schema and Contract, but Class
-
Compatibility is Not based upon Policy
There you go! This sums up all the things which would make your SOA design, a non-SOA design.
Ok, may be just adding a negation operator is not the best approach, let’s go with catch phrase methodology.
You might be a non-SOA if
-
Your services are too much dependent on each other.
-
Your service does not support versioning in contracts.
-
You have to pass around jars and dll’s to share contracts.
-
If your contracts and implementation are not properly isolated for consumers.
-
You have an enterprise SOA strategy even though your business stakeholders didn’t sit down with IT architects to examine business processes across the organization.
-
Your services use SOAP as a panacea when interop could have been better achieved with RESTful services.
-
Data is ignored and governance means a config file to turn off the service response to 500.
-
Your entire SOA strategy is implementing web services / BPM / CEM / any other TLA including SOA (this will make it a circular definition).
-
A client is passing a database connection string to your service call…
Yeah, I agree the last one is probably just plain bad design.
and as if this has not been fun enough, let’s end with a knock-knock joke courtesy of SOAFacts.
Knock, knock
Who's there?
SOA
SOA who?
You're fired.
References
