标签: soa

SOA的原则之一是:"服务是自治的".我有2项服务.服务A取决于服务B.除非服务B启动并运行,否则服务A无法为客户端提供服务.我是否违反了这一宗旨？

或者,如果自治必须意味着"解耦",那么如果我有故障保护,我是否满足了这个原则(例如,如果主要实例已经关闭,那么另一个运行在其他地方的服务B的实例是连接到的).这可能满足我的可用性要求,但我不确定这如何可以减少我的依赖性.是的,故障保险甚至可以是来自第三方的服务C,在这种情况下,我确实提高了我的自主权.

或者这个原则是否意味着必须将服务设计为"fifedoms",并且具有明确定义的接口,用于获取和输出数据.然而,一些大师似乎认为你甚至需要存储你在内部收到的这些数据,以减少依赖并维持你的自主权......

如果我将服务视为具有消息传递的组件,这是一个错误吗？:)

思考？

我的公司(一个大型组织)正在开发一个"路线图",用于将他们相当古老,纠结的系统联盟发展为SOA模型.一些人正在努力使用Websphere Integration Developer和Websphere Process Server作为开发未来应用程序的事实平台......因为他们认为IBM是一个稳定的供应商,这些工具是为企业制造的,他们喝了"业务敏捷性" BPEL kool-aid等

有没有人对这个平台有积极或消极的想法？GUI工具是否有助于消除单调/冗余编码......或者只是模糊不清并使事情难以维护？基本上,这些好处是否证明了复杂性？

一些SOA基础是:

• 松散耦合
• 可重用性
• 无国籍服务
• 服务之间的正式合同
• 粗粒度
• 异步
• 摘要基础逻辑(黑匣子)
• 可组合(作为构建块的服务)
• 可发现的服务
• 自治服务

其中大部分都可以应用于云计算,所以我的问题是云计算是SOA思维的产物还是这两种不同的怪物？

我开始设计一个现在很小的wcf服务总线,但随着我们的业务增长而增长,所以我担心一些问题,并且也没有尝试过太多YAGNI.这是一个电子商务平台.问题是我对于把东西放在哪里有太多的想法.我将给出一个场景来展示我的所有问题.

我们有一个电子商务网站,销售产品并最终交付产品.为此我们有一个PlaceOrder服务,除了其他参数之外,还需要一个Address对象,在这种情况下(我们的网站下订单)由City,Street和ZipCode组成.

我们还与仅使用我们平台销售产品的合作伙伴开展业务.他们负责交货.对于这种情况,我们有一个PlaceOrderForPartner服务,除了其他对象之外,还需要一个Address对象.但是,在此上下文(合作伙伴下订单)中,Address对象由不同的信息组成,这些信息仅与合作伙伴下达的订单相关.

鉴于这种情况,我有几个问题:

1)如何在我的解决方案中的命名空间和文件夹中组织此DataContracts对象？我考虑过为每个上下文(合作伙伴,客户等)提供一个文件夹来保存服务和DataContracts.

所以我会的

- MySolution.sln
-    Partner (folder)
-        PartnetService.svc
-    DataContracts (folder)
-        Address
-    Customer (folder)
-        Customer.svc
-    DataContracts (folder)
-        Address

使用这种方式,我将有一个命名空间来放置我所有特定于上下文的数据交换.

2)服务设计怎么样？我应该为可能放置的每个人创建一个服务,并在其中订购和创建一个PlaceOrder方法,如下所示:

Partner.svc/PlaceOrder
Customer.svc/PlaceOrder

或使用PlaceOrderForPartner和PlaceInternalOrder创建订单服务,如下所示:

Order.svc/PlaceOrderForPartner
Order.svc/PlaceOrderForCustomer

3)假设我选择了上一个问题中的第一个选项,我应该如何处理订单上的操作以及合作伙伴和客户的共同操作？

4)我应该将DataContracts和Service定义放在同一个程序集中吗？每个一个？一切都与服务实施？

5)如何为操作命名输入和输出消息？我应该使用实体本身还是使用OperationNameRequest和OperationNameResponse模板？

最重要的是,我的问题是:如何"组织"服务创建中涉及的数据交换和服务？

提前感谢您对此的任何想法!

我们正在以Udi Dahan的方式实现SOA架构,这意味着服务是业务一致的自治组件(我们拥有的服务很少,每个服务都拥有一部分域,并且不允许彼此调用).我们正在使用nservicebus pub/sub.我试图找出处理"跨领域"数据问题的最佳方法.

让我给你举个例子:

我们有一个游戏服务,用户可以用来玩游戏.游戏有截止日期,我们希望在截止日期结束时通过向用户发送邮件来发出警告.邮件将包含来自多个服务的数据.现在,由于服务无法调用其他服务,我看到了几种不同的方法:

1)在游戏服务中处理它

从其他服务发布足够的消息,以便游戏服务可以存储自己需要的数据版本,因此在编写邮件时不需要依赖其他服务的数据.

缺点:

- 需要发布更多消息 - 数据的异常化 - 富有数据 - 所有权(多个地方的一个事实) - 向邮件添加新数据 - 更多消息,将内容存储在游戏服务中

2)创建聚合服务.

创建一个聚合服务,该服务将监听服务事件,存储创建邮件所需的每一项,并在游戏服务通知截止日期结束时将其关闭.

缺点:

- 与1)完全相同,但数据所有权更加清晰

3)创建一个客户端

创建一个"客户端"(这个客户端将没有gui,将是nservicebus托管,几乎与服务相同,但也有一些非常不同的东西).客户将订阅公交活动,就像2)在截止日期结束时,游戏服务会通知它.客户端将通过查询收集所需信息所需的服务来撰写邮件.

缺点:

- 客户服务(模糊架构) - 撰写邮件所需的一切必须是可查询的(暴露)

你是如何在伟大的pub/sub Udi风格的SOA架构中做到这一点的？:-)

我正处于为应用程序设计工作的初始阶段.将有以下内容:

• Web界面
• 网络服务
• 利用其他预先存在的Web服务

我是Windows服务和SOA的新手,尤其是在Visual Studio环境中.

我的问题是,如何在Visual Studio中设置此解决方案？例如,我会

• 将Web UI和服务调用放在同一个项目中,并将我的服务放在一个单独的项目中,然后将所有上述内容放在一个解决方案中？

开始构建我的解决方案以便可以跟踪和测试的最佳方法是什么？

我目前涉及的项目要求必须在Web服务中实现业务逻辑,该服务将由表示层组件(即Web应用程序)使用.

该公司拥有一个企业服务总线,并且几乎所有开发的Web服务都是通过该总线公开的.我向周围的一些同事询问了何时通过ESB公开服务,我得到了这样的答案:

• 如果有ESB,则通过它公开所有内容:有一些好处,如负载平衡和位置透明性
• 如果ESB只作为代理 - 没有消息转换 - 只是不要使用它:你将超载ESB并失去性能.你最好做一个点对点的连接.
• 如果存在协议转换(如将存储过程公开为SOAP服务),则应通过ESB公开组件.如果没有这个,你最好去点对点.

所以我很好奇是否有通过或不公开Web服务的一般协议或最佳实践.任何阅读/参考都将是一个很大的帮助.

我刚刚开始为一家目前正在经历成长痛苦的小公司工作.我不确定我将在这里描述什么样的系统.基本上我们有一个由许多不同的第三个应用程序组成的大杂烩,这些应用程序通过一个本地的"集成系统"相互交谈,这个系统是SQL作业,用.NET编写的后台服务,FTP传输和SSIS等的混合体.

以下是鸟瞰图:我们面向公众的网站是供应商在场外托管的订单输入系统(第三方购物车软件).我们每天每4小时下载订单信息.然后,我们的本土"集成系统"将这些数据进行按摩,该系统将此信息提供给我们的库存和仓库管理系统(WMS).它还向MS Great Plains,Pulse,PayFuse和第三方CMS等提供信息.

正如您可能已经猜到的那样,这种体系结构非常脆弱,并且轻微的事故(例如SQL作业失败的FTP故障)可能会导致数据差异,从而产生多米诺骨牌效应.有时由于数据相关问题或复制问题可能导致整个仓库停滞不前,我们有时无法接受订单,处理或发货订单.

我的任务是重新构建我们的系统并消除系统的紧密耦合以实现业务增长.我需要研究哪些方面？我一直在研究ESB和SOA,但我被告知,我的公司无法承担与iWay或Talend相关的50万美元承诺.

有什么选择？内部开发是答案,是否比ESB实施便宜？有没有人经历过类似的成长痛苦,如果是这样,你是如何处理整合的？

我一直在研究WebAPI并且非常喜欢我所看到的.

是否有理由不使用WebAPI？如果是这样,在什么情况下？

我最初认为在跨平台的SOA架构中,WebAPI可能不尽如人意,但是我阅读的文章越多,我越发现WebAPI几乎在每个现实场景中都可能胜过WCF.看起来你可以使用WebAPI for android,ios等而不仅仅是.Net; 甚至性能表明WCF REST最慢.http://weblog.west-wind.com/posts/2012/Sep/04/ASPNET-Frameworks-and-Raw-Throughput-Performance

WCF还有更好的"理性"原因吗？

我面临着一个巨大的困境:在我的公司,我们正致力于微服务架构并转向完整的SOA生态系统.

一些顾问和开发人员表示,SOAP for web服务会更好,因为它允许为所有开发团队指定并提供经过验证的格式.我害怕使用SOAP,最后我们会受到限制.

根据您的经验,对于SOA /微服务架构,使用SOAP或REST API会更好吗？

在此先感谢您的有用反馈.