标签: soa

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

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

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

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

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

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

• 从SOA的角度看Registry和Repositry有什么区别？
• 应该使用哪一个？一个人的优点和缺点是什么,反之亦然？

什么是Java,Java EE,C#,asp.net和SOA的Freenode irc频道？

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

要求是:

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调用)

我只使用WCF进行数据服务(即应用程序内部,非常精简,没有会话状态等),以保持我们的Web应用程序的可扩展性.

我们需要为我们当前正在传递的每个服务调用提供一些公共属性.对于每个调用具有单个请求对象并不理想,因为超出这些常见属性,其余的是非常多样的并且在开发期间经常变化.

目前我正在考虑使用自定义标头和clientmessageinspector来设置值.对于这种情况,这是最简单的推荐方法还是有更好的方法？

更多详情..

下面的红点是我不确定正确的方法(或如何去做).

发送了什么

发送的数据是一组简单的id(3或4用于userid,clientid等) - 所有这些ID都会对安全性和性能产生影响(在某些情况下,它决定了要访问的数据库).

我们还将扩展它以获得更复杂的权限 - 不需要Windows工作者.

调用者将是一个Web应用程序,它们来自会话对象,或者是一个手动填充这些应用程序的Windows服务工作者.

当前的思考

理想情况下,调用者工作流的getinstance会自动使用会话对象填充这些属性,还是使用windows服务调用(不同的构造函数？)手动填充.

然后,我们将确保这些参数始终可用,无需任何考虑或在整个代码中没有常量引用,以便在调用它的每个函数上构造契约.我们目前有很多服务调用(由于应用程序的规模/复杂性,而不是由于糟糕的工程:)),因此这扩展到复杂的权限,以自我文档的方式强制执行规则变得有点困难.

从概念上讲,会话是你在应用程序中处理这个问题的地方,但服务实际上只是一个数据访问层(具有视图映射,页面调度和来自存储库调用的最后调用安全性)所以我们不需要那种重复或复杂性,只包括要包含在查询中的关键标识和权限字段.

问题

这感觉非常像我们应该对调用的标题做的事情,因为我们总是需要这些字段,但我不确定set和get应该位于端点和客户端接口的生命周期中的哪个位置.我也很高兴错了.

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

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

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

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

谢谢!亚历克斯.

在SOA中,如果一些DTO类具有一些重复的字段.使用Composition或Inheritance是否更好,所以没有重复或只使用一个封装所有字段的DTO类.随着我的DTO类的增长,我看到很多重复的字段名称和Sonar报告是哭泣的家禽.什么是最好的方法(或替代方案).

例如

public class DocDto{
private Long id;
private String name;
private String docType
}

public class DocReviewDto{
private Long id;
private String name;
private String status;
private String comment;
}

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

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

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

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

我是一家大型金融公司的架构师,我们正在开始在不同国家实施一个新的面向业务的信息系统.

从很早开始,核心思想就是尽可能遵循面向微服务的原则(并确保工程师阅读Sam Newman撰写的"构建微服务"一书).

到现在为止,我已经到了十字路口.我们的服务主要是使用Swagger进行自动化文档的JSON REST服务,但是为了在我们的业务流程中使用这些服务并确保不将业务逻辑写入这些服务域之外的服务,我们一直使用Camunda作为编排工具.而且Camunda很好(虽然有些人认为Corezoid是另一种选择),但在一套优雅的服务中却有些笨拙.

现在,服务编排是大多数工程师都非常熟悉的概念.但由于仍然拥有驱动一切的中央引擎,因此我并不完全满意.在以后的路上更换是非常昂贵的(虽然替换比单块更便宜).即使这个中央引擎被分成多个引擎(实际上就是今天的情况),它也不一定能让它变得更好.

近年来,有一种微服务向精心设计(接近事件驱动)架构的运动.正是在这一点上,我正在寻找那些面临类似十字路口决策点的工程师和建筑师的建议.

我非常喜欢分离式架构的想法,尽管在杀死巨型组件和拥有优雅的独立服务方面感觉良好,但我仍然在当前的协调解决方案中检测到业务流程中的许多依赖关系,而这些解决方案实际上并不存在.

这并不像我们正在避免事件.我们实际上已经在我们的体系结构上实现了事件,以便将许多进程与核心原则分离,如果您不需要同步响应并且只需要通知发生的事情以启动另一个进程,则可能会发生一个事件.被另一个开始执行的进程捕获.并且编排更容易解释和可视化,更容易被更具技术头脑的业务用户调整和修改.我认为从业务角度来测试和验证更容易.像这样的协调体系结构(通常)也期望良好的服务发现和高质量的自动化文档和非功能性需求,这些都是我非常重视的.

所有这些对我来说都是编排问题的问题,因为我没有大规模运行这个问题的第一手经验 - 只是一些本地测试原型.

但我想你知道我来自哪里.我试图考虑替代方案,而不必后悔以其他方式驾驶公司.

也许你可以分享自己与类似情况的经历或分享一两个有趣的链接？或者我在寻找一个尚不存在的银弹？