ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel

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

Updated on May 6, 2015

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

JBOWS

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]

Capabilities
Capabilities

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.

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.

Have you read any books on SOA Design Patterns

See results

Comments

    0 of 8192 characters used
    Post Comment

    • profile image

      maccaroo 

      7 years ago

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

    working

    This website uses cookies

    As a user in the EEA, your approval is needed on a few things. To provide a better website experience, hubpages.com uses cookies (and other similar technologies) and may collect, process, and share personal data. Please choose which areas of our service you consent to our doing so.

    For more information on managing or withdrawing consents and how we handle data, visit our Privacy Policy at: https://hubpages.com/privacy-policy#gdpr

    Show Details
    Necessary
    HubPages Device IDThis is used to identify particular browsers or devices when the access the service, and is used for security reasons.
    LoginThis is necessary to sign in to the HubPages Service.
    Google RecaptchaThis is used to prevent bots and spam. (Privacy Policy)
    AkismetThis is used to detect comment spam. (Privacy Policy)
    HubPages Google AnalyticsThis is used to provide data on traffic to our website, all personally identifyable data is anonymized. (Privacy Policy)
    HubPages Traffic PixelThis is used to collect data on traffic to articles and other pages on our site. Unless you are signed in to a HubPages account, all personally identifiable information is anonymized.
    Amazon Web ServicesThis is a cloud services platform that we used to host our service. (Privacy Policy)
    CloudflareThis is a cloud CDN service that we use to efficiently deliver files required for our service to operate such as javascript, cascading style sheets, images, and videos. (Privacy Policy)
    Google Hosted LibrariesJavascript software libraries such as jQuery are loaded at endpoints on the googleapis.com or gstatic.com domains, for performance and efficiency reasons. (Privacy Policy)
    Features
    Google Custom SearchThis is feature allows you to search the site. (Privacy Policy)
    Google MapsSome articles have Google Maps embedded in them. (Privacy Policy)
    Google ChartsThis is used to display charts and graphs on articles and the author center. (Privacy Policy)
    Google AdSense Host APIThis service allows you to sign up for or associate a Google AdSense account with HubPages, so that you can earn money from ads on your articles. No data is shared unless you engage with this feature. (Privacy Policy)
    Google YouTubeSome articles have YouTube videos embedded in them. (Privacy Policy)
    VimeoSome articles have Vimeo videos embedded in them. (Privacy Policy)
    PaypalThis is used for a registered author who enrolls in the HubPages Earnings program and requests to be paid via PayPal. No data is shared with Paypal unless you engage with this feature. (Privacy Policy)
    Facebook LoginYou can use this to streamline signing up for, or signing in to your Hubpages account. No data is shared with Facebook unless you engage with this feature. (Privacy Policy)
    MavenThis supports the Maven widget and search functionality. (Privacy Policy)
    Marketing
    Google AdSenseThis is an ad network. (Privacy Policy)
    Google DoubleClickGoogle provides ad serving technology and runs an ad network. (Privacy Policy)
    Index ExchangeThis is an ad network. (Privacy Policy)
    SovrnThis is an ad network. (Privacy Policy)
    Facebook AdsThis is an ad network. (Privacy Policy)
    Amazon Unified Ad MarketplaceThis is an ad network. (Privacy Policy)
    AppNexusThis is an ad network. (Privacy Policy)
    OpenxThis is an ad network. (Privacy Policy)
    Rubicon ProjectThis is an ad network. (Privacy Policy)
    TripleLiftThis is an ad network. (Privacy Policy)
    Say MediaWe partner with Say Media to deliver ad campaigns on our sites. (Privacy Policy)
    Remarketing PixelsWe may use remarketing pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to advertise the HubPages Service to people that have visited our sites.
    Conversion Tracking PixelsWe may use conversion tracking pixels from advertising networks such as Google AdWords, Bing Ads, and Facebook in order to identify when an advertisement has successfully resulted in the desired action, such as signing up for the HubPages Service or publishing an article on the HubPages Service.
    Statistics
    Author Google AnalyticsThis is used to provide traffic data and reports to the authors of articles on the HubPages Service. (Privacy Policy)
    ComscoreComScore is a media measurement and analytics company providing marketing data and analytics to enterprises, media and advertising agencies, and publishers. Non-consent will result in ComScore only processing obfuscated personal data. (Privacy Policy)
    Amazon Tracking PixelSome articles display amazon products as part of the Amazon Affiliate program, this pixel provides traffic statistics for those products (Privacy Policy)