标签: soa

我最近一直在关注SOA.CORBA与SOA完全不一样吗？

我们目前有一个WCF服务,它已经为枚举设置了自己的DataContracts.然后,我们在DataContract枚举和业务层中可用的公共枚举之间有一个映射层.同样的事情发生在客户端 - 客户端枚举和数据协定枚举之间的映射层

我们今天早上一直在谈论通过WCF服务公开我们的常见枚举,然后到客户端,我们不知道这是否是最佳实践.因此,该问题归结为是否允许交叉关注来自我们后端,通过服务和客户端系统的枚举或者我们是否应该继续将我们的数据合同与基本代码库分开是一件好事.我们正在努力为我们的服务实现SOA的最佳实践.

人们对此有何看法？

可以说我有网络应用/服务:

• API
• 应用程序集

API用于管理某些资源(简单的CRUD操作).现在我需要的是订阅应用程序以更改不同的API资源.应用程序将对更改进行一些后台工作.

我想到了回调.因此,应用程序可以oauth orise并发布到API回调配置.

我认为这个配置应该是这样的:

{
  'callback_url': 'http://3rdpartyservice.com/callback',
  'resources':    ['foo1', 'foo2'],
  'ref_data':     { 'token': 'abcd1234' }
}

• resources是第三方服务感兴趣的资源数组
• ref_data是第三方使用的自定义json(例如,用于auth)

这种方式在指定的资源更改时,API会向callback_url发送请求.此请求将包含资源数据,操作(创建/更新/删除)和ref_data.

这里的目的是使这个通用足以允许第三方客户端配置这样的回调.

所以问题是:

1. 有没有最佳做法？
2. 安全潜在问题怎么样？
3. 网上有没有真实世界的例子？

TX

我只是在阅读SOA,并定期提到服务注册表/ UDDI.这听起来不错,但现实中如何使用？

• 注册表是否意味着将逻辑服务与其物理实现(端口,URL等)分离？
• 注册表是否意味着由寻找有趣服务的人浏览？
• 将应用程序硬连接到它使用的服务是否"错误"？

我正在考虑使用MSMQ作为在即将到来的项目中执行异步执行的解决方案.我想知道使用WCF和MassTransit等框架之间的区别,甚至是手写的MSMQ客户端来放置/读取MSMQ上的任务.

基本上,应用程序将是通过服务层(无论是WCF还是普通的Web服务)读取/写入数据的几个网站(内部通过LAN或通过Internet外部).然后,此服务层将执行以下两项操作之一:1.将数据写入数据库2.和/或通过在队列中放置消息来触发后台进程.3.显然它也可以从数据库中检索数据.队列另一端的小代理(Windows服务)将监视队列并根据任务命令执行.

与RPC或分布式执行或其他任何方式相比,此体系结构将非常容易扩展(添加更多队列和代理)并且易于实现.并且代理处理不需要是实时的.代理和服务层是单独的应用程序,除了它们共享公共域对象和存储库等.

你怎么看？欢迎对上述要求的架构建议.谢谢!

Orchestration引擎与消息驱动系统的职责是什么.

如果我必须构建一个系统,必须将不同的独立组件(不需要公开Web服务端点的交叉技术/平台组件)串在一起,这是要选择的工具集？

有更好的选择吗？

让我们想象一下,我们有一个披萨店的订单处理系统来设计和建造.

要求是:

R1.系统应该是客户端和用例不可知的,这意味着客户可以访问系统,在初始设计期间不考虑该系统.例如,如果披萨店决定其许多客户以后使用三星Bada智能手机,为Bada OS编写客户端将不需要重写系统的API和系统本身; 或者,例如,如果事实证明使用iPad而不是Android设备在某种程度上更适合送货司机,那么创建iPad客户端将很容易,并且不会以任何方式影响系统的API;

R2.可重用性,这意味着如果业务流程发生变化,可以轻松地重新配置系统,而无需重写大量代码.例如,如果稍后披萨店将开始接受在线支付以及接收交付司机的现金(在接受订单VS接受付款时接受付款),那么将系统调整到新的业务流程将很容易;

R3.高可用性和容错性,这意味着系统应该在线并且应该全天候接受订单.

因此,为了满足R3,我们可以使用Erlang/OTP并具有以下架构:

这里的问题是这种架构中有很多"硬编码"功能.例如,如果披萨店在订单发出前从接受现金支付转为接受在线支付,则需要花费大量时间和精力来重写整个系统并修改系统的API.

此外,如果披萨店需要对其CRM客户端进行一些增强,那么我们将不得不重写API,客户端和系统本身.

因此,以下架构旨在解决这些问题,从而帮助满足R1,R2和R3:

系统中的每个"服务"都是带有RESTful API的Webmachine Web服务器.这种方法具有以下好处:

• Erlang/OTP的所有优点,因为每个Webmachine都是一个Erlang应用程序,可以监督并可以放入Erlang版本中;
• 面向服务的体系结构,具有SOA的所有优点 ;
• 易于适应业务流程的变化 ;
• 易于向客户端添加新客户端和新功能(例如,向CRM客户端),因为客户端可以使用系统中所有服务的RESTful API,而不是一个"中央"API(就SOA而言的服务可组合性).

因此,基本上,第二张图中提出的系统体系结构是面向服务的体系结构,其中每个服务都有一个RESTful API而不是WSDL协定,每个服务都是一个Erlang/OTP应用程序.

以下是我的问题:

1. 图2:我想在这里重新发明轮子吗？我应该坚持使用纯Erlang/OTP架构吗？("纯Erlang"表示Erlang应用程序打包到一个版本中,通过gen_server相互通信:call和gen_server:cast函数调用);
2. 你能说出建议方法中的任何缺点吗？(图2)
3. 您是否认为维护和增长(R1和R2)这样的系统(图2)比真正的Erlang/OTP更容易？
4. 这样一个系统的安全性(图2)可能是一个问题,因为有许多入口点对Web开放(所有服务的RESTful API)而不是一个入口点(图1),是不是这样？
5. 在这样的系统中有几个"编排模块"还是可以存在一些更好的实践？(图2中的"接受订单","CRM"和"调度订单"服务);
6. 纯粹的Erlang/OTP(图1)在消息传递和协议限制方面是否优于这种方法(图2)？(在我之前的类似问题中部分讨论过,gen_server:调用VS HTTP RESTful调用)

SAML联合软件是否应该接受相同的SAML响应,只要它在允许的SAML令牌生存期内？

简单来说: IDP(标识提供者)发出SAML响应,然后SP(服务提供者)接受/处理它.可以在首次使用后立即重复使用相同的未修改的SAML响应吗？鉴于SAML发布时间戳在允许的范围内.

在安全方面,将SAML令牌(响应)限制为仅一次使用是有意义的,因此即使它被"中间人"窃取 - 它也不能被重用.但是为了实现这一点,软件需要在某处存储有关SAML响应的一些信息:序列号,整个事物的哈希值？

请提供一些链接,说明可能的解释和/或实施示例.

谢谢!亚历克斯.

我正试图解决 REST 中“集合”和“商店”之间的区别。从我到目前为止所读到的，

一个集合是：

 "a server-managed directory of resources"

一个商店是：

 "client-managed resource repository"

我找到了这篇文章： 如何“存储”REST 原型不会创建新资源和新 URI？

但这并没有真正帮助我澄清差异。我的意思是，我知道一个由服务器控制，另一个由客户端控制......但是有人能给我一个具体的例子来说明商店在现实世界的应用程序中可能是什么吗？

我*认为是这样的：

GET http://myrestapplication.com/widgets/{widget_id} -- retrieves a widget from db
POST http://myrestapplication.com/widgets/{widget_id} -- creates a new widget from db
PUT http://myrestapplication.com/widgets/{widget_id},[list of updated parms & their vals] -- update widget
PUT http://myrestapplication.com/users/johndoe/mywishlist/{widget_id} -- updates john doe's profile to add a widget that already exists in the database... but links to it as his favorite one or one that he wants to buy

这样对吗？如果是这样，最后一个 …

我一直在寻找SOA和Microservices架构风格之间的差异，并找到了一个很好的链接https://www.infoq.com/articles/boot-microservices

它说：
作为“面向服务的体系结构”（SOA）的继承者，微服务可以归入同一类“分布式系统”中，并继承了许多相同的SOA概念和实践。但是，它们的区别在于对单个服务的责任范围。在SOA中，服务可能负责处理各种功能和数据域，而微服务的一般准则是它负责管理单个数据域以及该域周围的相应功能。

请帮助我了解：
单个数据域的含义（建议用于微服务）。是说必须构建一个单独的微服务来管理单个域/实体（以及与此单个域/实体相关联/复合的域/实体）。因为如果是这种情况，那么即使要实现基本功能（企业）应用程序，也会有许多（〜20到〜50）个微服务

编辑：我已经看过微服务架构和SOA之间的链接差异，但是它解释说，它在前两个原则上是相同的，在第三点上是不同的（在SOA中，服务共享模式和协定，而不是类），但是是SOAP合同，但是黑白SOA（使用REST）与微服务（主要是使用REST）有什么区别？