0

Basically with my research, SOA (Service-Oriented-Architecture) is a broad topic, and it has many definitions, some say that is only used for business applications and some just give an IT related definition like "is an architectural pattern in computer software design in which application components provide services to other components via a communications protocol, typically over a network".

I'm currently on my final year project, and I basically want to develop an recommendation engine based on web services, where any kind of web application can use the recommendation engine.

So my question is, what it takes to be considered a SOA solution, and since it's a project with no enterprise specific (it's a general software), should I consider it a SOA?

My second part of the question is that if for instance it can be considered a SOA project, i'm planning to use a software development methodology especifically for this kind of projects, and it's name is SOUP (Service Oriented Unified Process). The problem is that this methodology takes insight concepts such as SOA strategy (which i couldn't find any information on that, so I hope that someone can explain), and SOA governance (which basically in my opinion doesn't make sense for a final year project who doesn't have a entreprise specific client).

John Newman
  • 66
  • 9
  • You have two different questions, so you should use two different posts. Secondly, I advise you to discuss it better with your academic adviser - you need his support for you project to be accept. Finally, a simple answer is "the use of services to couple software components" is enough to define your project as SOA and find a book like: http://www.ibm.com/developerworks/library/ws-soa-method3/index.html. "SOA strategy: A high-level plan that explains how the project will be execute." If you refine your question I can provide a better answer. – darlinton Jun 27 '16 at 10:03
  • 1
    Google is one example. While it was not as diverse as Amazon's SOA architecture it was at least as complex as Twitter's. Google was a final year project and the final architecture by necessity needed to have shard servers, mapreduce dispatchers/routers and front-end load balancers. The dissertation concentrated on the sharding which allowed it to have a database much larger than the largest available hard disk and mapreduce which allowed it to search such a large database in real-time. – slebetman Jun 27 '16 at 11:24
  • @darlinton, when i say SOA strategy, i refer do the deliverable that SOUP methodology proposes in the incept, as I'm not being able to understand what should it contain, like can you suggest me a template document or what key topics should it have. – John Newman Jun 27 '16 at 13:01
  • @JohnNewman I looked at the explanation provided by IBM (url in previous post) and I guess it can be a block diagram to illustrate the project big picture plus some text explaining the process how to accomplish it. I was unable to find a template. If you are unable to find better description of this process, don't use it. – darlinton Jun 27 '16 at 13:40
  • Thanks @darlinton. I will try my best to use this methodology. – John Newman Jun 27 '16 at 13:42

1 Answers1

4

So my question is, what it takes to be considered a SOA solution, and since it's a project with no enterprise specific (it's a general software), should I consider it a SOA?

I don't think that the fact that the software is not enterprise specific means that you could not consider it to be SOA. Put another way, SOA does not depend on being within a business context.

I think SOA is one of those problematic terms in that it is basically meaningless unless you are actually doing it. So what does it mean to do SOA?

Well, one way would be to consider the first and second tenets of SOA, Boundaries are explicit and Services are autonomous.

So what do we mean in this case by boundaries? Well, we could interpret this in simply technological terms, eg the boundary between the inside and the outside of the service is explicit, in that there is a well-defined interface. However, this interpretation is shallow in my opinion.

When we talk about a boundary, what we should be talking about are capability boundaries. A service should embody single (or related multiple) capabilities, and the boundary between one capability and another should be explicit. There are capabilities X and Y and an absolute line between them.

So this gives us our first clue about how to do SOA. Clearly, we need to understand what capabilities our system will support, and then plan a service for each of them.

This brings us onto the second tenet. Autonomy is probably the most important consideration in SOA. So what does autonomy actually mean? How do you make your services autonomous? In one sense it means that where there is a natural capability boundary as informed by tenet one, autonomy dictates that there be no "leaking" of capability across that boundary, or put more simply, that services should be decoupled from each other.

So this gives us our second clue for how to do SOA. If we want to fully respect autonomy we should be looking at building each capability completely in isolation to other capabilities. So this means building each service as a separate application, sharing very little with any other services.

There are many practical consequences to this approach.

One of the more important consequences of this is that we cannot share a database between services. Each service is responsible for its own data model. Importantly, this will mean that certain types of database entity common to more than one service or capability may well be duplicated across many different services and that these different representations of the same entity are allowed to become inconsistent.

Another consequence is that it is arguable that services should use HTTP to exchange data with other services outside of the business capability. Consuming a resource based URL can imply a dependency on the other service's capabilities too direct to allow for real autonomy. Instead, true autonomy may only be achieved by using eventing.

So as you can see, as long as you can build your application keeping in mind the first two tenets of SOA, you do not require a business enterprise to make sense of the design. The design makes sense without it, as long as you can model your system's capabilities and then make you services autonomous.

tom redfern
  • 30,562
  • 14
  • 91
  • 126