In a previous blog I highlighted the different aspects of a logical reference architecture for SOA. The logical architecture defined six logical categories of Services – Presentation, Business Process, Business Activity, Data, Connectivity and Utility Services.
This classification of services has caused a lot of discussion in the SOA community. From not practical, not realistic, too slow, reuse is impossible, etc. So I want to use this blog to highlight some of my experiences in using this service classification scheme and also to address some of the concerns, criticisms, and misconceptions I have heard.
Reuse of Business Services
Business Services are the most commonly talked about Services in a SOA. They expose business operations via Service interfaces to establish a single, rationalized way to perform business functions.
In my experience the reuse of Business Services tends to be low (not non-existent but low), but can have significant value to the enterprise. For instance, the reuse potential of Business Services is generally less than say Data services. As the level of complexity increases, the likelihood of reuse is reduced. For this reason Business Services offer more value as a way to rationalize IT operations and achieve agility than as a way to promote reuse. By abstracting the users of Services from the system interactions needed to perform those Services, they provide a way for IT to evolve its systems without a direct impact to the users.
I Will Never Use a Connectivity Service
I was contacted by a reader who told me that Connectivity Services were pointless and that no-one will ever use them.
- First of all, no enterprise should use a reference architecture off the shelf. Rather then enterprises starting from scratch in building their own reference architecture, it makes sense to use one that comes closely to their own requirements AND most importantly customize it to their environment. So if an enterprise does not believe they will ever utilize a connectivity service then remove it from the reference architecture
- Secondly. I have used a connectivity service. I used the service to abstract away the highly complex nature of connecting to a proprietary hardware/software solution that I did not want to live in a code library due to the changing nature of this system. The imporant aspect here is to make sure that these services are stateleess and contain no business logic.
- Lastly, as more COTS and Partners systems adopt REST then the need for a connectivity service will start to diminish.
Layered Architecture are Always Non-Performant
This criticism reminds me of the saying – “You don’t get something for nothing”. The “logical” service layers are defined to assist with the separation of concerns and enablement of reuse as identified by the different types of services. But it is true that if you were forced to go through all of the service layers of the reference architecture that I highlighted there it will not perform as fast if all of the code existing in one big monolith application. So how to address this without losing the benefits of SOA?
The layered architecture is in fact a “relaxed layered architecture” as can be seen here as the service bus enables to start consuming services at any level. It is true that once you start to consume the service you can not then jump over the layers. For instance if you start to consume a Business Activity Service then that service must consume a Data Service.
The next push back I tend to encounter is that the marshaling/de-marshaling of the service payloads kill performance. The first question I ask is what performance criteria do they have in mind. “As fast as Possible” is not an acceptable answer to me. I like to see the business requirements that justify a 10ms vs 100ms latency. If there is a real business concern around performance then this is where service encapsulation comes into play.
As you can see from the above diagram the encapsulation rectangle is suppose to signify that the “logical” service layers” can if justified leave in one physical deployable service. So a Business Activity Service may encapsulate (“include”) the code required for accessing data. When this is required I still advise to have clear separation in the code between business logic, data logic and connectivity logic.
Microservice
Anyway I’m sure I will encounter more criticism of SOA and when I do I will attempt to address them here. SOA is not perfect but it does address some of the challenges we have had over the last couple of decades.
I recently heard a talk on microservices which seems interesting. It seems to ignore reuse to address developer agility. Giving the challenges around implementing a proper governance regime for reuse this might be a good ploy. I will watch with baited breath.
Good Luck, Now Go Architect.
An Enterprise Architect's Musings 