标签: soa

有人知道SOA治理的全部意义吗？SOA治理和IT治理之间的区别(或相关性)是什么？如何使用市场上可用的SOA平台应用它？

在不应用SOA治理的情况下,构建在SOA平台上的项目能否成功？怎么样？我是从实际的角度来谈这里的.

从过去几个月开始,我正在研究最新的dot net框架项目.

我觉得在最新的dot net版本中,鼓励"服务"而不是组件.那是对的吗？

我在银光中看到过(我是银光初学者)所有数据库层操作都作为服务公开.我不知道现在组件程序是否可用？

有什么好处？如果所有层都作为服务而不是DLLS公开,那么性能如何呢？

请通过这个主题的一些说明,我应该从哪里开始正确理解这个概念？

谢谢

SC

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

有可能(甚至可能)我只是没有完全理解"工作单元"的概念.基本上,我将其视为面向对象环境中使用的广泛事务.启动工作单元,与对象交互,提交或回滚.但是,这如何分解为这些对象背后的数据存储的实际事务？

在具有单个DB和ORM(例如NHibernate)的系统中,它很容易.可以通过ORM维护交易.但是,自定义域模型隐藏了许多不同数据源的系统呢？并非所有这些数据源都是关系数据库？(这里的文件系统已经做了很多.)

现在,我坚持认为"你根本无法在同一'原子'业务操作中跨SQL2005数据库,SQL2000数据库,DB2数据库和文件系统维护事务." 因此,目前,团队中的开发人员(通常彼此独立工作)负责在代码中手动维护事务.每个DB都可以在其上进行适当的事务处理,但是整个业务操作都是手动检查并在每个重要步骤中进行平衡.

但是,随着域和标准开发人员流动的复杂性增加,这种方法将变得越来越困难并且随着时间的推移而容易出错.

有没有人有任何关于如何最好地解决这样一个领域的建议或例子,或者之前如何处理它？在这种情况下,实际的"域"仍处于起步阶段,随着原型的发展,有朝一日扩展并消耗/替换大型不同遗留应用程序的生态系统.因此,有足够的空间进行重新设计和重新分解.

作为参考,我目前的目标是10,000英尺的设计视图:大量的小型as-dumb-as-possible客户端应用程序调用基于消息的中央服务.该服务是"域核心"的入口,可以被认为是一个大型MVC风格的应用程序.对服务进行请求(很像"动作"),由处理程序拾取(很像"控制器").任何程序都在那里.它们与包含所有业务规则的模型进行交互.模型发布的事件是监听器("服务"？这部分在设计中仍然是多云并且需要改进)通过与存储库(数据库x,数据库y,文件系统,电子邮件,任何外部资源)交互来获取和处理.所有的快乐依赖注入相应.

抱歉所有的冗长:)但如果有人有任何建议,我很乐意听到它.即使(特别是)如果这个建议是"你的设计很糟糕,试试这个......"谢谢!

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

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

人们对此有何看法？

SOA概念很容易掌握,但我对BPEL和Apache Camel等企业服务集成架构和技术并不熟悉.

我知道BPEL有助于协调服务,而且Camel是企业集成模式的实现.我目前正在阅读着名的企业集成模式书.

但EIP和管弦乐之间的界限对我来说似乎很薄弱.在我看来,Camel还以自己的方式协调服务.此外,Camel提供了许多连接器,因此可以轻松使用不同的协议.

Camel比BPEL更好吗？
或者是否可以使用您无法使用Camel执行的BPEL操作？
哪个？
关于我所阅读的内容,似乎Camel比BPEL更好地协调REST服务:这是真的吗？

我试图围绕Apache Camel,这似乎是一个轻量级的ESB.如果我正确理解Camel/ESB,那么您可以将Camel Route视为节点和边的图形.每个节点都是路由上的端点(可以使用/生成消息).每条边是两个不同端点(1个生产者和1个消费者)之间的路径.

假设这是正确的,我有一个实际的问题:最佳实践是如何规定部署应用程序的ESB/Camel Route的？我应该将其打包为自己的JAR,还是值得成为自己的充满EJB,Web服务和其他JAR的EAR？

我想我是在询问如何部署/构建Camel Route或ESB,例如:

my-esb.ear/
    ejb1.jar/
        MyEJB_1.class
    ejb2.jar/
        MyEJB_2.class
    webservice.war/
        MyWebService.class

要么...

my-esb.jar/
    MyEJB_1.class
    MyEJB_2.class
    MyWebService.class

阅读了有关SOA,Web服务和客户端 - 服务器架构主题的一些文献.我对这些术语感到困惑,因为看不出它们之间的真正区别.有人能解释一下SOA和Client-Server之间的实际区别是什么吗？我可以使用Client-Server来实现SOA,还是前者是一个不同的概念？客户端服务器现在已经过时了吗？这里的网络服务在哪里？Web服务只是一个客户端 - 服务器架构吗？

如果有人帮助我澄清这些概念之间的所有这些术语和差异,我将非常感激.

我们god object在我们的系统中遇到了一个.该系统包括public service暴露给我们的客户,middle office service和back office service.

流程如下:用户注册一些交易public service,然后经理middle office service检查交易并批准或拒绝交易,最后管理者back office service完成或拒绝交易.

使用我'这个词transaction,但实际上这些都是不同的类型,如操作的CRUD on entity1,CRUD on entiny2......不仅CRUD操作,但其他许多操作,例如approve/send/decline entity1,make entity1 parent/child of entity2等等...

现在WCF服务合同只是根据系统的那些部分分开.所以我们有3个服务合同:

PublicService.cs
MiddleOfficeService.cs
BackOfficeService.cs

每个都有大量的运营合同:

public interface IBackOfficeService
{
    [OperationContract]
    void AddEntity1(Entity1 item);

    [OperationContract]
    void DeleteEntity1(Entity1 item);

    ....

    [OperationContract]
    void SendEntity2(Entity2 item);

    ....
}

所有3项服务的运营合同数量已经达到2000个,每个服务合同约为600个.它不仅打破了最佳实践,而且只需更新服务引用就会非常痛苦,因为它需要很长时间.并且系统每天都在增长,并且在每次迭代中将越来越多的操作添加到这些服务中.

现在我们面临两难困境,因为我们如何将这些神服务分解为逻辑部分.有人说服务不应包含超过12~20次操作.其他人说一些不同的事情.我意识到没有黄金法则,但我希望听到一些关于此的建议.

例如,如果我只是按实体类型拆分这些服务,那么我可以在项目中获得大约50个服务端点和50个服务引用.在这种情况下,可维护性是什么？

还有一件事需要考虑.假设我选择了按实体拆分这些服务的方法.例如:

public …

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

• 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