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
  • 2
  • 6
  • What does the term "SOA" mean to you? I hear SOA, I think: outdated marketing buzzword, associated with bloated, overengineered systems like CORBA. Most of the actual benefits of SOA can be obtained without using things like Service Buses and the like. – Robert Harvey Jan 27 '14 at 02:20
  • @RobertHarvey my apologies for the lack of definition. I'm referring to "Service-oriented architecture". – kedoska Jan 27 '14 at 03:11
  • @marcocs: "SOA is the technique of functionally decomposing the application functions of a large organization into a set of interoperable services that can be accessed through 'network APIs'" . Writing one service that exposes HTTP REST doesn't generally quality as an "architecture". Hence, Robert's question – DXM Jan 27 '14 at 03:22
  • Then I guess I have to ask you what your actual question is. Should you always consider SOA? Of course, if it is relevant to your project. The middle of your question reads like an Architectural Digest blog post, and the last question is quite random. – Robert Harvey Jan 27 '14 at 03:26
  • @DXM exactly that: to break down the features, and thereby increase the number of components in the design of a system, are the basis of my questions. – kedoska Jan 27 '14 at 03:28
  • @RobertHarvey design software, oriented to services, it is a starting point even for no-enterprise clients? – kedoska Jan 27 '14 at 03:33
  • @marcocs: I think they key is "large organization" and typically a good number of services, often produced by different business entities (hence where it became a business buzz word). In my curiosity search to see how SOA relates to CORBA (still not sure btw), I came across this interesting read: http://www.eriktownsend.com/doc_download/12-1-the-25-year-history-of-service-oriented-architecture.html – DXM Jan 27 '14 at 03:33
  • 4
    May I humbly suggest that an increase in the number of components in a system (and the corresponding increase in complexity) without good cause is unnecessary, and may actually decrease the quality of your software? See also http://www.codinghorror.com/blog/2004/12/it-came-from-planet-architecture.html – Robert Harvey Jan 27 '14 at 03:36
  • @RobertHarvey "Architecture Astronauts".. ok I guess that answers to my questions. – kedoska Jan 27 '14 at 03:46

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