Skip to main content

Building a Service Orientated Architecture (SOA), from JBOWS to Microservices

Service Orientated Architecture (SOA) vs. Service Orientated Application Design (SOAD)

If you Google the acronym SOA and 3 million results come back; clearly there is a lot of discussion going on around this topic.

The trouble is that much of it is sales jargon and opinionated views that cover only a small sub-section of the SOA landscape, one is hard pressed to find any practical advice on actually building service-orientated applications above putting a web service in front of your application and calling it SOA. Other advice pushes you down the slippery path of white box services and tightly coupled, unreliable and unmaintainable systems.

I maintain that SOA is simply to our current knowledge the best and most productive way to build software.

There is a spectrum of SOA goodness; this spectrum perhaps is a result of the path SOA has taken towards its current level of maturity. The problem is that many frameworks and developers have not reached the same destination yet.

SOA Spectrum - Bill Poole

SOA Spectrum - Bill Poole


Bad SOA or Just a Bunch of Web Services (JBOWS) is a relic of the SOA past where the focus was on tooling and technology rather than architecture and analysis, services are exposed somewhat arbitrarily. They do not contribute towards any defined broader architecture. Therefore service contracts will have an arbitrary level of stability.

JBOWS refers to the scenario where random/unplanned functionality is exposed within an enterprise as Web services. It is a build it and they will come mentality. This is common with an IT led, rather than business led, SOA initiatives.

Service Orientated Integration

Service Orientated Integration is slightly better than JBOWS, with this approach; service contracts are centred on applications. They are expressed in terms of the application with which we are integrating. Consequently if the scope of the application changes, or the application itself is exchanged for another (such as exchanging an Suger CRM with MS CRM), the service contract is very likely to change.

Layered Service Models

So what about layered service models? In this case, we have atomic business tasks, business processes and data stores abstracted as services. These concepts are not at all stable. Businesses very often make changes in business processes that in turn require changes in how atomic business activities are defined and how data is represented. With this approach we are very likely to find ourselves changing our service contracts as business processes are updated.

This type of design could also have a negative effect on the reliability of the system we are building. Over time these atomic business tasks, process that are represented as services become referenced from multiple other atomic services, any outage of the heavily referenced service has a catastrophic effect on the system as a whole.

Business Capabilities

Business capabilities are by their very nature incredibly stable. For example, a retail organization may make regular changes as to how it goes about inventory management, the fact is that it will always have an inventory management capability. Moreover, other capabilities within the enterprise don't care how inventory management is performed. They only care that it is performed. [Poole]



Service Taxonomy

With an understanding of a SOA Quality Spectrum the problem then is how one builds a service orientated application that has a firm grip on the technical requirements of; Integrity, Flexibility, Maintainability, Performance, Reusability, Scalability and Security, Usability is not considered as this will be a technical requirement of the client application.

Any application framework also needs to sit at the right of the SOA quality spectrum, be as simple as possible to build by a team of individuals by giving them a set of guidelines of what goes where, a service taxonomy, thus eliminating many of the decisions that cause projects to loose their conceptual integrity before they are out of the development phase.

Scroll to Continue

This framework should build on all the lessons learned from the past eighty years of software engineering and incorporate the patterns and best practices the industry has distilled from this journey.

Sounds like a tall order but it is entirely achievable in a vey productive and repeatable way.

Service Taxonomy - Shy Cohen

Service Taxonomy - Shy Cohen

Why build a Taxonomy?

What is a Taxonomy and why should we have one? The understanding of two concepts is needed to fully answer this question, the first is taxonomy, which refers to the classification of things or concepts, as well as the principles underlying such a classification. The second concept is ontology, which is a representation of the concepts within a domain and the relationships among those concepts.

Having a classification guideline can help when making business decisions around how to partition or obtain a certain business capability, and can assist in the build, lease, or buy decision making process

Attempts have already been made in creating such categorization system, Shy Cohen, from Microsoft has written a superb article about service taxonomy. His article is at the right level for a business executives, and they should have no problem grasping the concepts.

I feel that this article goes a great job in describing the high level concepts, but lacks the depth that architects and developers need to actually build these systems, the suggestions I offer in this hub and the hubs that follow will apply this taxonomy in general, but will partition the pieces in such a way that all non-functional aspects of a system can be met.

Service Orientated Architecture (SOA) vs. Service Orientated Application Design (SOAD)

It is necessary to differentiate between the term Service Orientated Architecture and Service Orientated Application Design. SOA as a paradigm puts forward a specific set of design principles. The application of these principles to the design of solution logic results in service-oriented solution logic, since the majority of developers build solutions at the application level, what they are doing if they build applications using service orientated priciples is building service oriented applications or SOAD, not service orientated architecture.
SOA is both a business and IT architecture approach, whilst SOAD is an application design approach aligned with and supporting SOA.

SOA Composition is a central concept

Composition is at the heart of SOA, we are encouraged to strive to create systems that allow us to create new capability's by re-composing ones we already have.

Many of us have drawn the kind of picture shown below for our clients, we promise that system A, B or C can we snapped out and replaced with another one with a similar capability.

SOA Composition

SOA Composition

By drawing this picture we are acknowledging that in a service-orientated design we should focus less on the blocks and more on the lines, by our own admission we know the blocks will come and go, but the lines are always the same.

By getting the lines right we are easily able to recompose our system out of new blocks that can rely on the same interactions. With the right lines we can achieve composition at all levels, in SOA the lines usually translate to the contracts and interfaces between the different parts of the SOA.

The caveat here is that unless the blocks (applications we seek to re-compose) also contribute to the whole, our attempt will not be as successful as we had hoped.

Tao of SOA

This is why I firmly believe that the path to SOA lies in understanding and creating solid a SOAD base of applications first.


maccaroo on February 20, 2011:

Awesome overview of SOA architecture. Must... have... more...

Related Articles