This post is part of my Popping Bubbles series. If you’re new to the series, you should really start at the beginning. If you don’t have that much time, here’s a small recap: the Bubbles are the silos, the Popping is me, trying to bring the silos down with all kinds of technology and failing magnificantly. Like I said, you should really start at the beginning…
After writing about eight pages on how Service Oriented Architecture in practice also isn’t able to pop bubbles, I decided I had to write a prelude before I could get into the details of applied SOA. Theory before practice, so starting with Principles and Patterns before explaining about Service Orientation makes sense. SOA, after all, is a type of Architecture. And Architectures are all about Goals and Benefits, Principles, Methods, and Patterns (in others words, no solutions, only some vague guidelines). Even starting with Patterns before Principles feels better than the other way around, which is normally done, because Patterns put my previous posts in perspective. Famous last words: Watch and Learn.
Patterns first
You see, my previous posts were really describing SOA Design Patterns, which I disguised as IT history. BPM actually is the Process Abstraction Pattern, CDM is the Canonical Schema Pattern, and EAI uses a whole bunch of Design Patterns also used in SOA. So before I can really go into the nitty gritty of SOA, I first have to explain about Design Patterns.
At the risk of being asked not to do so, I will start by quoting something about Patterns in general and then highlight some parts of it so you can see for yourself why Patterns are popular among architects: nothing is enforced. Patterns only describe what could happen if you choose to adopt one and what could happen if you choose not to, yet no guarantees are given either way. Lovely.
Here we go:
“Design patterns are helpful because they:
- represent field-tested solutions to common design problems
- organize design intelligence into a standardized and easily referenced format
- are generally repeatable by most IT professionals involved with design
- can be used to ensure consistency in how systems are designed and built
- can become the basis for design standards
- are usually flexible and optional (and openly document the impacts of their application and even suggest alternative approaches)
- can be used as educational aids by documenting specific aspects of system design (regardless of whether they are applied)
- can sometimes be applied prior and subsequent to the implementation of a system
- can be supported via the application of other design patterns that are part of the same collection
- enrich the vocabulary of a given IT field because each pattern is given a meaningful name
Furthermore, because the solutions provided by design patterns are proven, their consistent application tends to naturally improve the quality of system designs.
Note that even though design patterns provide proven design solutions, their mere use cannot guarantee that design problems are always solved as required. Many factors weigh in to the ultimate success of using a design pattern, including constraints imposed by the implementation environment, competency of the practitioners, diverging business requirements, and so on. All of these represent aspects that affect the extent to which a pattern can be successfully applied.”
There you have it. This is what being an architect is all about: recommend some stuff, but don’t enforce it and don’t give any guarantees. Easy job, pays well I suppose. But no, I’m being unfair. It really does depend on the competency of the Practitioners. That’s why I am writing this blog, to educate the Practitioners, i.e. everybody who, in some capacity or other, works within a Service Oriented Architecture.
Like all topics I have written about so far, I have seen them work and not work. Just like Schrodinger’s cat, which is both dead and alive at the same time (don’t you just love philosophy). As long as you feed the cat, the chance that it doesn’t die vastly increases. The same goes for Patterns. You just have to provide the right food: teach, apply, and govern.
- Teach:
What I try to do with this blog, and what every self-respecting, and knowledgeable SOA architect also does. We teach, evangelize, show the pitfalls, and guide everyone during the process of applying SOA. - Apply:
Use tried-and-true Patterns in situations that they can and should be applied to, but nowhere else. A pattern is not a one-size-fits-all thing. You should always think first: does this pattern make sense here? Does it break more than it solves? - Govern:
When you stop after the first two meals, it will not stick. Set up Governance! End all your discussions with “…do it like this, or else…!”. (And use Gandalf’s voice, too, so they know you’re being serious: you shall not pass!)
Principles later
Belief it or not, the SOA Patterns are actually based on Principles, and the application of these Principles should accomplish the goals (and benefits) of SOA. How cool is that?! Every pattern eventually serves a goal that you have set at the start. It’s like saying: my life should be about such and such and then have every 2-minute-action you subsequently perform contribute to your life’s purpose. That’s architecture for you.
What-is-a-service interlude
We will now make a quick side-step to answer the question that has been bothering you from the start of this post and then smoothly land back to Principles. Observe.
You are of course wondering: what is a service anyway? Officially…
“Services exist as physically independent software programs with specific design characteristics that support the attainment of the strategic goals associated with service-oriented computing.” That’s a nice circle I suppose.
But not only that, also “Each service is assigned its own distinct functional context and is comprised of a set of capabilities related to this context. Those capabilities suitable for invocation by external consumer programs are commonly expressed via a published service contract (much like a traditional API).”
Let me translate for you what that means. A service is a small program. Someone first thought a bit about this program and asked a couple of easy questions:
- What small piece of my company should this program be about? (functional context)
- Within this context, what should this program be able to do? (capabilities)
- Which of these capabilities should be available to others? (invocation by external consumers)
- What kind of information is needed to make the program do its job? (service contract)
- And some related stuff like: who may use it, how many times, etc. (service policy) (ooh, I got one extra! Bonus points for me.)
So a service can do some stuff, it has a contract to call it into action, and perhaps it gives some answers. Simplistically put. Very simplistically.
So in order to “…support the attainment of the strategic goals associated with service-oriented computing…” a service needs to adhere to the Principles that make it do just that. And we’re back to the Principles. Smooth.
The Principles in general describe that things should be done in the same manner by all services. Word combinations like ‘specific considerations’ and ‘appropriately granular’ are used, just like we are used to when dealing with architects. Nothing is written in stone yet, but everything is well considered and appropriately applied.
Great!
Anyway, the Principles tell us e.g. that services should have standardized Service Contracts. No specifics yet, just A Standard Way of doing it. The specifics will be described in the Patterns. You remember the Patterns? These things of which you can choose whether or not to use them and then have no guarantee they will actually get you the result you were after… Well, we have to start somewhere. Besides a standard way of having a contract, services should:
- Abstract the internal working of the service
- Be loosely coupled
- Be reusable
- Be autonomous
- Be stateless
- Be discoverable
- Be able to be part of a composition.
Principles in Detail
Some of these Principles are simple, others need a bit more explanation. Also, Principles can always be applied “to a certain extend”. At first glance you might argue that this gives so much freedom that in a range from SINO (SOA In Name Only) to as SSAH (SOA Strict As Heck) (yes, I just made that up) you could claim to be working in a SOA environment. But the truth is that Service Oriented Architecture just gives us these Principles as handholds to think about how useful and important each of these aspects of SOA is in our unique environment. So again: think first!
Now, let’s start with an easy one so we can get the hang of it. Service Abstraction. That’s just difficult language for a service saying: “I’m a black box, it’s none of your business how I work on the inside. I have this capability (= I perform this specific action) as explained in my Service Contract, take it or leave it.” How the service actually performs this capability is called the Internal Working of the service. The Internal Working is hidden (abstracted) from the users of the service and can even change during the lifetime of the service and no-one should even realize it. The service will still perform the capability as advertised.
Loosely coupled on the other hand looks easy, but is not. Coupling refers to how dependent something is on something else. As we have seen, a service has a Contract and an Internal Working. Service Abstraction explained that we could swap Internal Workings of a service without anyone noticing, so the Contract is Loosely Coupled to the Internal Working.
A service also has consumers. When designing a service, you should make sure to make it independent of the Potential Consumers. Service design should only be concerned with transforming a business capability into a service. The Contract is Loosely Coupled to Potential Consumers. But once the service is running and has a number of Actual Consumers, the Actual Consumers depend on the service to perform its capability as advertised. Changing the Service Contract at that moment will have a huge impact on the Actual Consumers. So the Service Contract is Tightly Coupled to its Actual Consumers. Hence the word ’appropriate‘ to describe, at the Principle stage, the level of coupling. Leave it to the Patterns to describe the exact nature of each coupling.
Reusable , Autonomous, and Discoverable mean what they say. Though Autonomy will be a biggy in my blogpost-to-come-somewhere-in-the-future about microservices (spoiler). In the next post, popping bubbles with SOA, Discoverability is discussed in more detail.
Stateless means that a service should not keep track of which consumer asked what. Huh? OK, imagine the service called Car. This service has two main operations: go! and stop!. The service can be called by several consumers, so the service has to have a car for each consumer that calls it. Why? Because when the first consumer calls the operation go!, his car is moving. All other consumers are not yet moving, because they have not yet called the go! operation. The more consumers call this service, the more cars it needs to keep track of and in the end it will just give up. So no state! Except that sometimes you need to have a service like Car. Luckily, the principle says: “try to not keep state in a service where possible. Yes, we realize it’s not always possible, so that’s why we introduce a special layer for special process-services using special process-patterns. The rest of the services can go in the entity-layer using special agnostic-patterns.” In a nutshell, use the proper Pattern to work out the details.
A service should also be able to be part of a composition. A composition is really a possible Internal Working of a service, which is nobody’s business according to the abstraction principle. But each service should in essence be able to be a part of the Internal Working of another service. Also a good reason not to keep state in a service, by the way.
Patterns again
Where the Principles keep things high level and sort of give general guidelines, the Patterns are more concrete. Except in giving any guarantees. A pattern first describes a problem: a situation that could manifest itself in your company. Depending on whether you like the situation, you can apply the pattern to solve it, or not. At the moment of writing 97 SOA Patterns exist, distributed over 18 categories. Let’s go over each one in detail! …just kidding, that’s not a good idea. I have some nice statistics, though. Most Patterns carry names made of two words, like ‘schema centralization’ or ‘utility abstraction’ but only 125 different words are used. Some words are used a lot, with the obvious winner being ‘service’, which is used no less than 18 times (including combinations and plural form). But also ‘centralization’ (8), ‘capability’ (7), ‘contract(s)’ (6), and ‘canonical’ (6) are used often. Sorting them this way gives a nice insight in what’s important in SOA, besides most of these words starting with the letter c. These numbers confirm that services are indeed manifestations of capabilities, which are accessible through a contract in canonical form (four out of five in a single sentence, not bad). Most associated stuff should be centralized: logic, policies, processes, rules, schemas, metadata, reference data, and contracts. Why? Because of governance. When you distribute all this stuff across your landscape, nobody will know exactly what’s happening where, and in the end nobody will know why things happen the way they do or how to make changes properly without breaking anything.
SOA in practice
After this theoretical overview of SOA Principles and Patterns, it’s very difficult to imagine that in practice you can really screw this up. I mean, the amount of detail, all the books, the courses and certifications: how can you mess this up? It turns out to be very easy. In my next post I will discuss in detail what I have witnessed. I will give one teaser here: as quoted “Many factors weigh in to the ultimate success”, but my favorite is the competency of the practitioners when it comes to applying SOA in practice.
