SOA 可以应用于最后的 Year 项目还是仅适用于企业的架构? [英] Can SOA be applied for a final Year project or its only an architecture that is advisable for entreprises?

查看:76
本文介绍了SOA 可以应用于最后的 Year 项目还是仅适用于企业的架构?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

基本上根据我的研究,SOA(面向服务的架构)是一个广泛的主题,它有很多定义,有人说仅用于业务应用程序,有人只是给出与 IT 相关的定义,例如是一种架构模式在计算机软件设计中,应用组件通过通信协议(通常通过网络)向其他组件提供服务.

我目前正在做最后一年的项目,我主要想开发一个基于 Web 服务的推荐引擎,其中任何类型的 Web 应用程序都可以使用推荐引擎.

所以我的问题是,如何才能被视为 SOA 解决方案,而且由于它是一个没有特定于企业的项目(它是一个通用软件),我应该将其视为 SOA 吗?

我的问题的第二部分是,例如,如果可以将其视为 SOA 项目,我打算专门针对此类项目使用软件开发方法,它的名称是 SOUP(面向服务的统一流程).问题是这种方法需要洞察力概念,例如 SOA 策略(我找不到任何关于它的信息,所以我希望有人能解释一下)和 SOA 治理(在我看来基本上没有意义)没有企业特定客户的最后一年项目).

解决方案

所以我的问题是,SOA 解决方案需要具备哪些条件,以及因为它是一个没有特定于企业的项目(它是一个通用的软件),我应该将其视为 SOA 吗?

我不认为该软件不是特定于企业的这一事实意味着您不能将其视为 SOA.换句话说,SOA 不依赖于业务环境.

我认为 SOA 是那些有问题的术语之一,因为它基本上没有意义,除非你真的这样做.那么 SOA意味着什么?

嗯,一种方法是考虑第一个和第二个 SOA 的原则边界是明确的服务是自治的.

那么在这种情况下,边界是什么意思?好吧,我们可以用简单的技术术语来解释这一点,例如,服务内部和外部之间的边界是明确的,因为有一个明确定义的接口.然而,在我看来,这种解释是肤浅的.

当我们谈论边界时,我们应该谈论的是能力边界.一个服务应该体现单个(或相关的多个)能力,并且一个能力和另一个能力之间的边界应该是明确的.有能力 X 和 Y 以及它们之间的绝对界限.

所以这给了我们关于如何 SOA 的第一个线索.显然,我们需要了解我们的系统将支持哪​​些功能,然后为每个功能规划服务.

这将我们带到了第二个原则.自治 可能是 SOA 中最重要的考虑因素.那么自治究竟意味着什么呢?您如何使您的服务自治?在某种意义上,这意味着在原则一所告知的存在自然能力边界的地方,自治要求跨越该边界的能力没有泄漏",或者更简单地说,服务应该彼此解耦.

所以这为我们提供了关于如何 SOA 的第二条线索.如果我们想完全尊重自主性,我们应该着眼于完全独立于其他能力来构建每种能力.因此,这意味着将每个服务构建为一个单独的应用程序,与任何其他服务共享很少.

这种方法有许多实际后果.

这样做的一个更重要的后果是我们无法共享数据库 服务之间.每个服务负责自己的数据模型.重要的是,这意味着多个服务或功能所共有的某些类型的数据库实体可能会在许多不同的服务中重复使用,并且允许同一实体的这些不同表示变得不一致.

另一个后果是,服务应该使用 HTTP 与业务能力之外的其他服务交换数据是有争议的.使用基于资源的 URL 可能意味着对其他服务功能的依赖过于直接,以至于无法实现真正​​的自治.相反,只有使用事件才能实现真正的自主权.

如您所见,只要您能够牢记 SOA 的前两个原则构建您的应用程序,您就不需要企业来理解设计.没有它,只要您可以对系统的功能进行建模,然后让您的服务实现自治,那么设计就有意义了.

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).

解决方案

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.

这篇关于SOA 可以应用于最后的 Year 项目还是仅适用于企业的架构?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆