The most of the things we do have two sides - purposeful and contra-purposeful. The easier one can cross the line between them, the higher risk acquired. This directly relates to technical solutions - the easier to use it in the wrong way, the weaker the solution despite how elegant it is. Since a creativity of human beings is endless and unpredictable, all solutions can be turned in-out. The strong solutions differ from the weak ones by the degree of difficulty to alter the major, conceptual and principal aspects of the solution. If the conceptual and principal aspects of the solution are not protected from dummies, you know what to expect.
The last issue of The SOA Magazine has published the article "SOA with Spring" where Rizwan Ahmed describes the Spring technique of attaching Web Service interface to a POJO. From the technical perspective, it is a good, strong and useful article. The only surprise here is why this had not been done before. Indeed, in the early days of Web Services, the most popular solution for creating Web Service was automated extracting of WSDL from an arbitrary Java class. If you ask developers, they confirm that this feature exists in the majority of tools today. If you ask SOA Architects and experts, you will learn that a) Web Services are not SOA services but rather service interfaces, and b) extracting a service interface from its internal implementation is the sin № 1 in SOA. I am afraid that injecting a Web Service interface into a POJO is conceptually quite similar in weakness/risks to extracting service interfaces from the service implementation.
Here is why I suggest so. Let's start with what task we try to solve. If the task is integration utilizing a technology of stnandardised integration interfaces, I think that this pure technical task has a quite good solution described in the Rizwan's article. Certainly, 'contract-first' approach is much better for integration than extracting implementation specific (proprietary) interfaces. However, if we talk about SOA and its realisation, the idea of the 'service-class'-first is as wrong as an implementation specific service interface. In my publications about DOSOM ('Ladder to SOE' and 'A Domain Service-Oriented Modelling or How SOA Meets DDD') wrote that there is a crucial difference between OO oriented design capabilities and function/process oriented service capabilities. If we start with a 'service-class', we design an object structure that has a tremendous risk of crossing the boundaries that to-be service might set later in the design process via an injection of interfaces into the POJO 'service-class'. As a result, future services will be tied and coupled via their implementations, which is unacceptable in SOA: the only interaction between services may be via their official interfaces, no back-door sharing allowed.
Thus, 'SOA with Spring' makes sense only if 'SOA' in this context stands for 'Some Object Adjustment', or better it be POA - Plain Object Adjustment. With such implementation-first approach even with the interface related concerns taken separately, we have practically no choice to be sure that the outcome will be real SOA service. The fundamental concept of service decoupling and separation of concerns ('Principles of Service Orientation Reviewed') not protected in Spring but rather compromised.
The fundamental problem causing described confusions is in that many people still associate Web Service per se with SOA. This is the mistake; they are different even in technical implementation of service-oriented architecture.
Leave a comment