问题
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).
回答1:
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.
来源：https://stackoverflow.com/questions/38041582/can-soa-be-applied-for-a-final-year-project-or-its-only-an-architecture-that-is