Questions tagged «soa»

编辑： 为了避免进一步的混乱：我不是在谈论Web服务之类的东西。我说的是内部构造应用程序，而不是计算机如何通信。它涉及编程语言，编译器以及命令式编程范例的扩展方式。 原版的： 在命令式编程领域中，我们在过去的20年（或更长的时间）中看到了两种范例：面向对象（OO）和面向服务（SO）。基于组件（CB）。 两种范例都通过引入它们自己的模块概念来扩展命令式编程范例。OO将它们称为对象（和类），并使它们将数据（字段）和过程（方法）封装在一起。相反，SO将数据（记录，bean等）与代码（组件，服务）分离。 但是，只有OO具有本机支持其范例的编程语言：Smalltalk，C ++，Java和所有其他JVM兼容，C＃和所有其他.NET兼容，Python等。 SO没有这样的母语。它仅在过程语言或OO语言之上才存在：COM / DCOM（二进制，C，C ++），CORBA，EJB，Spring，Guice（所有Java），... 这些SO框架显然遭受其概念缺少本地语言支持的困扰。 他们开始使用OO类来表示服务和记录。这导致在设计中，仅具有方法的类（服务）与仅具有字段的类（记录）之间存在明显的区别。然后，通过类的继承模拟服务或记录之间的继承。从技术上讲，它并没有那么严格，但是一般来说，建议程序员使类仅扮演两个角色之一。 他们使用其他外部语言来表示缺少的部分：IDL，XML配置，Java代码中的注释，甚至像Guice中的嵌入式DSL。由于服务的组成不是服务代码本身的一部分，因此特别需要但不限于此。在OO中，对象创建其他对象，因此不需要此类工具，但是对于SO而言，是因为服务不会实例化或配置其他服务。 它们在OO（早期的EJB，CORBA）之上建立了一个内部平台效果，程序员必须在其中编写“驱动” SO所需的所有代码。类仅表示服务性质的一部分，必须编写许多类才能一起形成服务。所有这些样板都是必要的，因为没有SO编译器可以为程序员做。就像有些人在没有C ++的情况下在C for OO中所做的那样。您只需将保存对象数据作为第一个参数的记录传递给作为方法的过程。在OO语言中，此参数是隐式的，并且编译器将生成我们为虚拟功能等所需的所有代码。对于SO，显然没有此功能。 特别是较新的框架广泛使用AOP或自省功能将缺少的部分添加到OO语言中。这没有带来必要的语言表达能力，但是避免了上一点中描述的锅炉平台代码。 一些框架使用代码生成来产生样板代码。XML的配置文件或OO代码中的注释是此信息的来源。 并非我上面提到的所有现象都可以归因于SO，但我希望它清楚地表明需要使用SO语言。由于这种范例如此流行：为什么不存在一个范例？或者也许有一些学术论文，但至少该行业不使用。

11 object-oriented  soa 

我正在考虑设计一种本质上是模块化的新解决方案，并希望创建一个支持该设计的结构，以便将来轻松进行扩展，明确分离关注点，按模块进行许可等。在网络上发现的关于模块化或组合应用程序的是以UI为中心的，专注于Silverlight，WPF等。就我而言，我正在开发WCF服务应用程序，该程序将由从事各种UI项目的其他开发人员使用。 背景 我的项目的目标是创建一个集中的业务/域逻辑源，以支持我们的多个当前重复流程，规则等的业务应用程序。虽然并非可以实现模块化的所有好处，但我想抓住建立一个可以利用我们可以利用的那些部分的框架的机会。 我通过查看服务应用程序公开的API来开始设计。显然，可以按照我所考虑的模块化路线来隔离服务。例如，我将拥有FinanceService，InventoryService，PersonnelService等服务，这些服务将我的服务操作分组以在API中提供高内聚性，同时保持较低的耦合度，因此客户端仅需使用与他们的应用程序相关的服务。 对于我来说，我可以为每个服务分别拥有单独的模块，例如MyApp.Finance，MyApp.Inventory，My.Personnel等。跨领域关注点和共享类型将在MyApp共享程序集中。从这里我有点束缚。 （哦，我应该提一下，我将使用IoC容器进行依赖注入来保持应用程序的松散耦合。我不会提及哪个容器，因为我不想打开Pandora的盒子！） 在MyApp.ServiceHost中，我将创建一个与每个模块相对应的服务宿主文件（.svc），例如FinanceService.svc。服务主机需要服务的名称，该名称与配置文件中的信息相对应，该配置文件包含定义服务合同的接口。然后，将IoC配置用于映射要使用的接口的具体实现。 1.服务层应该实现API并委托给模块，还是应该使模块自包含（因为它们包含与该模块相关的所有内容，包括服务实现）？ 解决该问题的一种方法是拥有一个MyApp.Services“模块”，其中包含服务合同的实现。每个服务类都简单地委派给包含该操作的域逻辑的相应模块中的另一个类。例如，MyApp.Services中的FinanceService WCF类委托给另一个接口，该接口在Finance模块中实现以执行操作。例如，这将使我能够维护精简的服务外观并将实现“插入”到服务实现中，并且无需使模块担心WCF。 另一方面，也许每个模块都是独立的，因为它具有接口和实现。服务主机引用模块中的服务合同接口，并且IoC也配置为使用模块中的适当实现。这意味着除了添加新的.svc文件和IoC配置信息外，无需更改服务层即可添加新模块。 我正在考虑如果从标准WCF切换到RESTful服务接口，或者转而使用RIA服务之类的影响。如果每个模块都包含服务合同的实现，那么如果我更改服务技术或方法，则必须在每个模块中进行更改。但是，如果外观是其自己的模块，那么我只需要换出该部分即可进行更改。然后，这些模块将必须实现一组可能在共享程序集中定义的合同（接口）的不同集合？？？ 2.处理模块之间的资源共享和/或模块之间的依赖关系的最佳方法是什么？ 以接收操作为例。乍一看，这很有意义，因为进货是库存功能，因此进入库存模块。但是，在财务方面，我们还需要生成收据并授权付款。 一方面，我希望使用某种类型的域事件/消息传递来传达操作。库存模块引发一个GoodsReceivedEvent，该事件由Financial模块处理以生成收据并启动付款过程。但是，这意味着财务模块需要了解已收到的库存项目。我可以简单地通过ID来引用它们，但是如果我需要收据的其他信息，例如名称和/或描述，单位成本等，该怎么办？每个模块都拥有自己的版本的清单项目以适应该模块的需求是否有意义？在这种情况下，财务模块在处理GoodsReceivedEvent时将必须执行自己的库存项目查找。 ... 我之所以使用此示例，是因为我已经与各种ERP系统进行了大量合作，并且知道它们是采用这种类型的模块化设计的-我只是不知道如何操作。我上面也没有明确提及，但是我更喜欢遵循域驱动设计原则来设计解决方案，并相信这种类型的模块化恰好适合该领域。 非常感谢我对此有所帮助。

11 architecture  domain-driven-design  wcf  soa  modules 

免责声明 我希望我不要踩任何人的脚趾或冒犯任何一个概念的狂热者 背景 我一直在寻找面向服务的体系结构和微服务之间的真正区别，而没有找到明确的答案。 我读到以下内容： SOA的副作用 SOA是反模式 微服务来修复SOA的故障 ESB并不是真正的ESB，而是EAI 对消息中介的过度依赖 供应商正在滥用SOA的概念并试图出售其产品 SOA不受控制地增长 但是，仍然没有明确定义面向服务的体系结构（作为一个概念）和微服务（作为一个概念）之间的体系结构差异 据我了解，它们都具有： 服务提供商，只做一件事 服务网关/ ESB将这些服务提供给消费者 服务使用者，通过ESB /服务网关访问服务 题 那么，除了将SOA重新标记为微服务之外，还有什么不同吗？限制微服务成为宏的技术约束吗？ 注意：我不是在寻找观点，只是在寻找事实，希望在要点中 参考文献 软件工程问题 马丁·福勒（Martin Fowler）的网站（我认为他讨厌这段时间） 信息世界 迈克尔·富瑟斯的网站 堆栈溢出问题 更新资料 似乎在Stack溢出问题中也发生了类似的辩论，无论是否区分微服务都是变相的面向服务架构。 SO问题的结论： MS是SOA 的特例 MS支持较小规模的应用程序托管服务 MS取决于技术（使用HTTP而非开放协议选项） MS依靠技术来加强纪律（服务的自动部署） MS考虑使用ESB（邪恶），但使用API​​网关，IMHO是ESB的一种 如果满足以下条件，那么可以得出结论，MS是SOA： MS是否支持编排概念？一个或多个主流程管理工作流程 MS中是否有消息代理层？一组适配器，将消息格式从服务生产者的消息空间转换为服务使用者 微服务可以从整体企业应用程序读取数据吗？可以是单片应用程序的API吗？还是必须是能够独立运行的独立的自包含应用程序？ 如果最后一个问题的答案为否，那么微服务将无法处理复杂的工作流程系统，例如信用卡管理系统或对帐系统

10 microservices  enterprise-architecture  soa 

当我在该网站上阅读有关微服务的信息时，遇到了以下声明。规范架构是什么意思？与域模型不一样吗？ 微服务架构模式还拒绝了SOA的其他部分，例如规范架构的概念。

9 web-services  soa  microservices  nginx