This simple cheat sheet contains all the key goals, principals and design patterns that you should be aware of when designing SOA services and contains helpful links to places where you can find more in-depth information on each topic.
In the previous posts I discussed how I went about building my SOA ‘Entity’ service for Products by using a combination of Java Web Services, Java EE and the CouchDB NoSQL database. In this final post in the series I’m going to leverage some of the technical assets that I’ve created and implement some new user stories using some popular SOA patterns.
My current Product Entity Service implementation is very business process agnostic, and therefore highly re-usable in any scenario where consumers want to discover or store Product information. However, as it stands the Product Entity Service is designed to be used within a trusted environment. This means that there are no restrictions on access to operations like Create, Update or Delete. This is fine within a strictly controlled corporate sandbox but what if I want to share some of my service operations or Product information with non trusted users?
Lets imagine that in addition to our in-house use of the Product Entity Service we also wanted to cater for the following agile ‘user story’…
It’s time to begin the coding of my SOA entity service with NoSQL project, and as promised I’m starting with the web service’s contract.
This technique of starting with a web service contract definition is at the heart of the ‘contract-first’ approach to service-oriented architecture implementation and has numerous technical benefits including…
After 5 years of designing and building award winning service oriented architectures, I thought I’d share my top 5 SOA gotcha’s and some general hints on how you can avoid them in your SOA programme.
My journey towards obtaining the SOA Certified Architect status continues…
Module 3 – SOA Design and Architecture marks the half way point in the certification course and covers the service-oriented architectural model and the service-orientation design paradigm. It also covers the unique characteristics and dynamics that constitute service-oriented solution logic.
It’s quite a comprehensive and information packed course with approximately half of the content devoted to the SOA Principals of Service Design as established in the book of the same name. The module covers approximately 10 subject areas as follows:
- History of Service-Orientation and SOA Theory
- Service-Orientation vs. “Silo” based Design
- Distinguishing Characteristics of the SOA Model
- Understanding Services and Service Capabilities
- Complex Service Composition Design, Composition Runtime Roles and Responsibilities
- The Service-Orientation Design Paradigm
- “Contract First” Design, Standardized Service Contracts, and Uniform Contracts
- Service Loose Coupling and Coupling Types, Service Abstraction and Information Hiding
- Service Reusability and Agnostic Design, Service Autonomy and Runtime Control
- Service Statelessness and State Deferral, Service Discoverability and Interpretability
The course materials then conclude with a brief introduction to the contents of the next course module which covers SOA design patterns.
Yet again the content is delivered using a powerpoint-like presentation style which is brief and to the point. The 8 SOA design principals are each covered in roughly equal measure and with good clarity. Some effort is made to show how the principals relate, interact and support each other. It’s also clear that the principles themselves offer a great deal of structure and provide the reader with a valuable cognitive framework that helps you to understand, apply and articulate the benefits of applying each principal during service design.
The exam for this module is as challenging as ever. It takes roughly one hour and consists of around 50 questions that test your understanding of the course materials and the SOA design principals. Obviously, passing the exam is great, but the real long term value of this course module will no doubt come from the cognitive framework that the detailed study of the SOA principles bestows upon you. Definitely highly recommended.
Other blog entries in this series…
SOA Certified Architect Module 1 - Fundamentals
SOA Certified Architect Module 2 - Technologies & Concepts
SOA Certified Architect Module 3 – Design & Architecture
SOA Certified Architect Module 8 – Advanced Design & Architecture
SOA Certified Architect Module 9 – Advanced Design & Architecture Practical (Lab)
Remember the movie “Spartacus” – the Stanley Kubrick classic starring Kirk Douglas? In the movie there’s a famous scene where the bad guy’s (the Romans) want to capture Spartacus (Douglas) who’s the leader of a Slave army. After a huge battle the Slave army is defeated and the Romans promise that no further punishment will be dished out as long as the slaves identify their leader, Spartacus. “Who among you is Spartacus?” ask the Romans. To which, one by one hundreds of guys each reply in turn “I’m Spartacus” thereby protecting their leader by creating a huge array of ‘false positive’s‘ so that the Romans can’t properly identify the one true Spartacus.
What’s this to do with SOA?
In large SOA programmes I’ve seen a similar scenario where all of a sudden, multiple in-flight projects each start to claim that they are delivering ‘the SOA’. However, in reality very none of them are because it all hinges on how you measure ‘SOA’.
This ‘SOA Spartacus’ scenario usually occurs quite soon after SOA is articulated as the primary strategic direction of the programme, but before the organisation’s SOA capability is mature enough to understand what is meant by SOA, and how it should be designed and delivered. The problem occurs because people are inherently good, and they want to be seen to be doing the right thing even when exactly what constitutes ‘the right thing’ is not terribly well understood.
The risk for these SOA programmes is that should this situation be allowed to continue, the organisation may ultimately deliver none of the strategic benefits of SOA because the project teams are not properly coordinated and each ends up doing SOA very differently.
The solution to the problem is in two parts. Part one is to have a clear understanding of what constitutes SOA in your environment by creating a single set of SOA Design Standards. Part two is to provide robust SOA Governance so that adherence to the standards is universally enforced.
1. SOA Design Standards.
Business-aligned and intrinsically interoperable service-oriented architecture can only be created by widespread adherance to a consistent set of SOA design standards. It needs to be made very clear what does constitute good SOA within your domain and what doesn’t. Your service design standards should support the SOA design principals and ensure that the goals and benefits of SOA can be achieved. The overall policy of the SOA programme should be to enforce the SOA standards using SOA Governance…
2. SOA Governance.
In order to avoid deviation from the SOA standards and policies, you need to introduce an element of governance & control across the whole SOA programme that can ensure that the SOA Design Standards are applied consistently by each project team. If you do this it’s far more likely that you’ll get the outcomes you want and that the resulting SOA will meet the strategic goals of SOA.
Finally, a simple shortcut.
If you’re planning a SOA programme, quickly obtaining maturity in SOA design and implementation will save you a small fortune and help you avoid these simple gotcha’s. If you don’t have a SOA expert on your team, then my advice go and get one as soon as possible. It could be the best decision you’ll ever make. I’m confident you’d see a respectable return on that investment in a very short space of time.
It’s unfortunate, but Vendor’s, SI’s and VAR’s regularly mis-sell SOA.
Let me give you one simple example…
About 12 months ago during an RFP demonstration, a big name software Vendor suggested that their “3,500 ready made services would deliver SOA out of the box”. They even claimed that somehow 3,500 services was a mathematically optimum number an implying that everyone would need this number of services eventually- so why try and do it yourself?
Clearly this promise of a ready made service inventory could be very tempting to the uninitiated – but it’s just plain wrong. It’s like someone dumping a keyboard with 3,500 keys on your desk and then telling you that it can make you type faster. It’s simply not true.
In reality this particular vendor’s API had more likely been the result of a quick and dirty hack to expose an old functional API as a bunch web services. They could do this by simply turning each ancient API function into one operation on one web service. But the resulting service inventory would be a vast and unfathomable hodgepodge where every service API was designed at the same level of granularity and with the wrong level of coherence (both OO terms but they’re appropriate here). Ultimately this leads to an implementation nightmare where a considerable amount of complex service composition would be required in order to perform even the most basic of tasks.
Furthermore, regarding the 3,500 web services is optimal claim, the only math that I’m aware of that would make a difference to service interface design is Partition Theory and Partition Theory quite clearly states that a simple 1:1 mapping of services to operations (like those in this particular API) is very rarely the optimal arrangement and would more likely lead to highly inefficient solutions.
When challenged about this, the vendor’s ‘ingenious’ solution (I’m being generous here, I actually mean ‘demented’) was for the client to licence some more of their SOA tools to help with the burden created by this massive inventory of services. They’d need a registry to help with the discovery problem and a process management tool to help develop the large number of service compositions they’d need to build to do anything useful with their 3,500 services. This would of course require additional capital outlay, infrastructure and training and would inevitably deepen the vendor lock-in even further.
Fortunately, my private sector client at the time did evaluate the situation correctly and didn’t take the proposal any further. However, in less experienced teams this kind of mis-selling could go completely unchecked and could end up costing organisations a small fortune in scope creep and additional integration and implementation effort.
So what’s the solution?
I’d like everyone to understand this simple fact and use it to their advantage:
SOA can’t be packaged and sold!
The only way to get an architecture that is naturally service-oriented and fits the way that your business operates is to design it that way. There is no such thing as a pre-packaged SOA that can be bought off the shelf. Service-oriented solutions need to be designed by you, for you.
Vendors, SI’s and VAR’s currently find it all too easy to exploit customers who don’t have an expert SOA practitioner on their team. So my advice is for you to do yourself a favour and go and get one as soon as possible. It could be the best decision you’ll ever make and given the prices quoted by SOA vendors I’m confident you’ll see a phenomenal return on that investment within a very short space of time.