标签: soa

我认为在使用MVC或MVP设计模式时,业务逻辑应存在于模型中,但应隐藏在面向服务的体系结构中的服务之后.

软件系统可以在面向服务的体系结构中使用MVC或MVP设计模式吗？如果是这样,模特在哪里？

在我们的分层应用程序中,我们通过WCF调用访问数据库.我们正在根据请求创建和处理上下文.我们也在使用POCO方法.
我的问题是,在纯POCO模型(完全持久的无知POCO)中,是否有可能跟踪变化,而我们正在为每个请求创建和处理上下文(因为之前的上下文是在该服务调用中处理的)？如果是,EF如何处理这种情况？据我所知,2个机制(基于快照的变更跟踪和基于通知的代理变更跟踪)将无法处理这个问题？如果没有,我们应该如何处理上下文,以便我们能够跟踪变化？

我最近一直在做关于SOA和ESB等的大量研究.

我现在正在努力重新设计一些遗留系统,并且希望使用比现有更多的SOA架构来构建它.我们在大约5个网站中使用这些服务,我们现在使用我们的遗留系统遇到的最大问题之一就是我们几乎所有时间都在进行错误修复或更新时需要重新部署我们的5个网站,这些网站可能是非常耗时的过程.

我的目标是使服务之间的接口松散耦合,以便可以在不必重新部署所有相关服务和网站的情况下进行更改.

我需要能够扩展现有的服务接口,而不会破坏或更新任何依赖项.有没有人遇到过这个问题？你是怎么解决的？

我想在没有TCP通信开销的情况下(即使在同一台机器上)将SOA引入低延迟系统.Thirft看起来非常合适,因为我有Java和php进程.是否有针对节俭的IPC传输实现,或任何其他有益于这种情况的好主意？

在阅读了面向服务的体系结构原则网站和相应的维基百科文章之后,我想到了:Erlang/OTP平台可以被视为SOA平台,SOA应用程序可以构建在它上面.

唯一的事情是这样一个系统中每个服务的服务合同是非常具体的:为了在Erlang/OTP中调用服务,Orchestrating层必须通过Erlang消息调用或调用gen_server(取决于实现) .

这不会让任何对Erlang/OTP平台范围之外的服务的调用.

但是,如果我们尝试通过将所有相应的服务功能移动到基于Erlang的Web服务器(如Mochiweb)并基本上从gen_server更改每个服务的接口来调用XML来构建每个服务,该怎么办？

这将允许从基于WSDL的通用服务合同的标准化"砖块"组成各种应用程序.

此外,这种方法将让我们继续使用OTP主管和其他OTP功能,因为这样的服务仍将是OTP应用程序.

因此,问题是:您是否认为使用OTP Web服务器(Mochiweb)作为服务构建具有面向服务的体系结构方法的软件应用程序是一个好主意？附加的XML处理层能否破坏这种方法的所有优点？

是否有可能在来自.NET或Java等不同平台的不同SOA服务之间传播事务？

我知道事务可以在来自.NET的WCF服务之间流入和流出.但我不熟悉Java平台.

现在我在一个项目中工作,该项目从不同的平台传达服务.

如何保持业务的一致性？

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

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

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

更多详情..

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

发送了什么

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

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

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

当前的思考

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

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

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

问题

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

在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;
}

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

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

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

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

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

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

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

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

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

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

我需要创建一些DTO类来跨WCF传输业务对象.

由于这些只是没有功能的数据包,有什么理由我不能只使用字段,还是有一些很好的理由将它们作为属性正确地公开？

//fields
[DataContract]
class CustomerDTO
{
    [DataMember] public int     Id;
    [DataMember] public string  Name;
}

//or properties?
[DataContract]
class CustomerDTO
{
    [DataMember] public int    Id               { get; set; }
    [DataMember] public string Name             { get; set; }
}