0

While I think how to direct the future development:

Mini-introduction

As a fixed rule, I start with SOA (and REST as protocol) then I work on the interfaces (and that interface is a customer of my service, and usually is a separate project). I assume my deviation is because I'm first of all a back-end developer (with poor drawing skills).

Considering:

  1. The BIGs are making a great effort in making quick and easy to use tools for creating interfaces. (I am referring to projects such as the bootstrap, angular, android studio, and many others); This is a relief for those who develop platforms, opens the door to many new applications for their platforms.
  2. MV*, JSON, Javascript are becoming a standard in building (even) complex applications; It does not matter if the interfaces are all the same, the boilerplate today have reached a level that can be considered viral.
  3. The increasingly common repository of modules (ex. NPM), enable even novice programmers the use and implementation of external APIs with great ease.
  4. fate can always kiss our products and this maybe become the new facebook (with this I am referring to the fact that a product, even if required as a standalone, it can easily attract the interest of many, and it is very likely that new interfaces are required out of the initial planning).

Questions:

  1. Is SOA an approach that architects (and programmers) should encourage and consider starting new design?
  2. Is SOA the most suitable architecture to react to unplanned expansion?
kedoska
  • 321

1 Answers1

1

Is SOA an approach that architects (and programmers) should encourage and consider starting new design?

Services Oriented Architecture (SOA) is an approach worth considering, but it is not an end-all, be-all methodology. Nor was it ever truly intended to be despite over-zealous marketing. SOA is useful in large environments where you can have a high order of n:n interactions from various applications and other services. Using an SOA approach in this case makes it easier to encapsulate your offering and shield its internals from public view.

But in other environments SOA is not the right approach at all. For example, an embedded developer may not be able to afford the overhead SOA incurs within their selected chipset.

Is SOA the most suitable architecture to react to unplanned expansion?

Maybe; maybe not. It depends upon where the change creeps in.

SOA does a great job of masking change that is internal to the service. So long as the service's interface or API is maintained then callers don't care how it's actually implemented.

In cases where the change involves the interface, SOA doesn't do a great job of masking those changes. Since services are intended to be designed without much / any knowledge of the caller then it can be harder to implement a change at the interface layer. A non-SOA approach has more knowledge of the callers and that makes it easier to identify what additional areas need to be modified or tested based upon the changes.

Part of the challenge here is that Public APIs are forever.

Community
  • 1