标签: soa

根据我的经验,.NET的主要ORM框架(NHibernate,LinqToSql,Entity Framework)在跟踪加载的对象时效果最佳.这适用于简单的客户端 - 服务器应用程序,但在面向服务的体系结构中使用三层或更多层架构与Web服务时,这是不可能的.最终,通过编写大量代码来自己进行跟踪,可以完成,但是ORM不应该简化数据库访问吗？

在服务导向架构中使用ORM的想法是否很好？

在SOA中,我们不应该在客户端和服务器之间构建或保持状态(或设计依赖关系).这是理解的.但是,如果客户想要使用可能返回开放式数量的"行"的实时服务,可以遵循哪些模式？

类似于SOA但允许状态(会话)的Web应用程序已经通过分页解决了这个问题.分页需要(在大多数情况下,特别是使用SQL)服务器保存数据并且客户端以块的形式请求数据.

如果我们在哪里考虑用于Web服务的类似分页的场景,那么这些将遵循哪些模式仍然允许遵循SOA的原则(或尽可能接近).

思想家的一些规则:1)由SQL数据库支持(因此在选择集中没有行号的概念)2)在分页期间不跳过一行或复制一行中的一行很重要3)数据可以随时插入和删除其他客户端进入数据库4)没有必要将数据集视为实时(可更新)数据集

就个人而言,我认为上面的1和2已经通过约束解决方案空间满足要求来拼写我们的解决方案.

我提出的解决方案将数据(选择的数量)存储在只读存储/缓存中,在该存储/缓存中可以为结果集中的行号分配,并允许在此数据快照上进行分页.我将拥有存储快照的基础设施(服务器,外部缓存,memcached或ehcache - 这必须扩展得非常大).此类查询的结果将是快照ID,客户端可以使用快照API(Web服务)和快照ID从快照中检索数据.在x是合理的时间,结果将以只读,仅向前的方式处理x记录.

非常感谢竞争的想法和想法,批评或赞誉.

我必须创建一个Java EE应用程序,它将大型文档转换为不同的格式.每次转换需要10秒到2分钟.SOAP请求将来自我还必须创建的客户端应用程序.

处理这些长时间运行请求的最佳方法是什么？显然,该过程需要花费很多时间来运行而没有任何反馈给用户.

我可以想到以下提供某种反馈的方法,但我不确定是否有更好的方法,也许是标准化的方法.

1. 客户端从线程执行请求,服务器在响应中发送文档,这可能需要几分钟.在此之前,客户端显示"请稍候"消息,进度微调器等(这似乎很容易实现.)
2. 客户端发送"开始转换"命令.服务器返回某种作业ID,客户端可以使用它来频繁轮询状态更新或最终文档.(这似乎是用户友好的,因为我可以显示进度,但也要求服务器是有状态的.)
3. 客户端发送"开始转换"命令.服务器以某种方式通知客户端何时完成.(这里我甚至不知道怎么做)

还有其他方法吗？在性能,稳定性,容错性,用户友好性等方面哪一个最好？

谢谢您的回答.

他们有许多共同的特点.但是有什么区别？

MOM允许异步而SOA没有,这是唯一的区别？

环境是Visual Studio 2012,ServiceStack,ASP.NET Web应用程序项目(关注https://github.com/ServiceStack/ServiceStack/wiki/Create-your-first-webservice)

通过查看ServiceStack.Examples中的一些类,我注意到大多数服务只包含一个方法.有些覆盖Execute()或者,如果是REST服务,有些覆盖OnPost/Get/Put/Delete().

我应该如何看待做一个完整的API集,如果我有几我需要实现的功能RegisterUser(),RemoveUser(),AddFriend(),RemoveFriend()...每个方法的一个服务？

public RegisterUserService : IService<User> { public object Execute(User> dto) { ... } }
public RemoveUserService : IService<User> { public object Execute(User> dto) { ... } }
public AddFriendService : IService<Friend> { public object Execute(Friend dto) { ... } }
public RemoveFriendService: IService<RequestDTO4> { public object Execute(Friend dto) { ... } }

我很失落如何开始实现完整的API集.我已经阅读了"创建您的第一个Web服务" 的第一个和第二个 Wiki页面,我已经复制了该服务方法.但现在我想制作10或40种服务方法,我不知道该怎么做.

我注意到,实现from IRestService<T>允许你最多4个方法而不是一个 …

我遇到了DRY原则(不要重复自己)的问题,并最大限度地减少了围绕Rete规则引擎的依赖性.

大型IT组织中的规则引擎往往是企业(注意资本"E" - 这是严肃的业务).所有规则必须表达一次,很好和DRY,并集中在昂贵的规则引擎中.一个组维护规则引擎,并且是规则集的守护者.

当该IT组织是美国保险公司的一部分时,往往会有很多规则.有些规则适用于所有州和产品,但每个州都倾向于为不同的产品制定自己的法律,因此规则需要反映这些怪癖.这些类别很多:精算,承保,甚至是来自第三方机构的订购信用和机动车报告.

从设计的角度来看,我所面临的问题是集中规则和处理当然是好的和干的,但是有成本:

1. 额外的网络跃点访问位于中心的规则服务并返回结果;
2. 如果将规则引擎公开为SOAP Web服务,则会产生额外的复杂性 - 消费者必须将SOAP请求和OXM打包回自己的域;
3. 维护规则引擎的企业组,设置和维护规则的业务以及使用它们的开发人员之间的其他接口;
4. 额外的复杂性 - 有时数据驱动的解决方案可能就足够了.
5. 其他依赖项 - 无法控制自己的规则的组件必须担心规则引擎的外部依赖性,以便进行测试,部署,发布等.

许多其他企业技术(例如,B2B网关,ESB等)都会出现这些问题.

相同的企业集团也将SOA视为基本原则.但我对正确的服务设计的理解是,它们应该平铺业务空间并且是幂等的,独立的和孤立的.如果服务规则在其他地方维护,服务如何独立和隔离？

我想在简单性方面犯错,认为如果规则只能在孤立的情况下应用,那么消除依赖关系应该优先于集中化.我不确定这个论点会赢得胜利.

所以我的问题是:

1. 你在哪里落在集中化与独立论证上？
2. 您对规则引擎等企业工具的体验如何？
3. 我怎样才能让隔离的论点变得更强大？
4. 如果我的观点不正确,你会支持集中化的论点？

虽然我了解系统集成是什么,但我对所有最新方法都有点新意.我非常熟悉Web服务和JMS,但我对ESB的概念感到十分困惑.

我做了一些研究,但我仍然没有得到它.我通过实例而不是理论更好地工作.

那么有人可以说明一个简单的例子来说明为什么人们会使用企业服务总线而不仅仅是队列,Web服务,文件系统还是其他？

我希望这个例子能够放大ESB的功能,这是任何其他常规整合方法无法实现的,或者至少不能以相同的效率实现.

所有回复都非常感谢.

谢谢,鲍勃

在REST服务之前拥有请求队列的最佳技术解决方案(框架/方法)是什么？这样我就可以增加REST服务实例的数量以获得更高的可用性,并将Request队列放在前面以形成服务客户端的服务/事务边界.

1. 我需要Request Queue(java)的优秀轻量级技术/框架选择
2. 用它实现竞争消费者的方法.

我在Rails中创建了一个服务对象,作为我们的应用程序和API之间的接口.

我从http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/得到了这个想法

这是一个小例子:

class PackagesService
  def self.get_package(package_id)
    raise ArgumentError.new("package_id can't be nil") if package_id.blank?
    package = API::get "/packages/#{package_id}"
    package = JSON.parse package,
                          :symbolize_names => true unless package.blank?

  end
end

是否有任何良好的模式来处理验证和/或抛出Service对象的错误？

验证:

• 我必须检查所有输入是否为错误类型.有没有办法轻松验证？也许铁路延伸？

对于错误:

• 我可以捕获所有API错误,然后安全地返回一个零.但是使用服务对象的程序员可能不知道nil的含义.
• 我可以捕获API错误并引发另一个错误,这意味着在所有函数中执行此操作需要付出额外的努力
• 第三个选项是保持原样并让程序员处理来自API的所有错误.

如果您知道任何好的模式,或者您有更好的想法来连接API,请告诉我.

我是EDA的新手,我已经阅读了很多关于福利的内容,并且可能有兴趣在我的下一个项目中应用它,但仍然没有理解.

在举办活动时,哪种模式最适合:

1. 将事件命名为"CustomerUpdate",并包含有关客户的所有信息(已更新或未更新)
2. 将事件命名为"CustomerUpdate",并仅包含实际已更新的信息
3. 将事件命名为"CustomerUpdate"并包含最小信息(标识符)和/或URI,以便使用户检索有关此客户的信息.

我问这个问题是因为我们的一些活动可能很繁重而且频繁.

谢谢你的答案和时间.