标签: soa

什么是面向服务的架构？

什么是Oracle ADF？

在互联网上,我发现了以下定义:

ADF集成了子帧组合,为对象关系映射和其他形式的服务访问,数据绑定和用户界面提供关键功能,以及将所有功能粘合在一起的功能粘合剂.ADF代表"应用程序开发框架",它由Oracle开发.ADF是一个框架,它可以帮助您轻松构建应用程序,因为我们在开发应用程序时执行的许多冗余操作都由框架负责.

但是我对ADF的理解还有几个问题:

1. ADF是Java EE Framework 的扩展,可以使用ADF(包括SOA开发)完成的事情可以通过普通的Java EE编程来完成吗？(如果我错了,请纠正我.)

2. 是否必须学习ADF来执行SOA应用程序？

我目前正在考虑如何保护仅由我的移动应用程序使用的REST API被其他应用程序使用？API密钥可以是一个很好的解决方案,因为只有我知道秘密的API密钥.有更好的解决方案吗？

在面向服务的体系结构中处理实体类型的多态性和继承时,最不邪恶的道路是什么？

SOA的原则(据我所知)是将实体类仅仅作为数据结构,缺乏任何业务逻辑.所有业务逻辑都包含在窄范围,松散耦合的服务中.这意味着服务实现尽可能地进一步扩展松散耦合,并且意味着实体避免必须知道系统可能对它们执行的每个行为.

由于Java决定在决定使用哪个重载方法时使用声明的类型,因此服务实现中的任何多态行为都会被一系列条件检查object.getClass()或使用替换instanceof.在OOPL中,这似乎相当落后.

条件的使用是否是SOA中公认的标准？是否应放弃实体的继承？

UPDATE

我绝对意味着超载而不是压倒一切.

我将SOA定义为系统行为按用例分组到接口中,然后通常每个接口在一个类中实现这些行为的逻辑.因此,实体类(比如说Product)只不过是一个带有吸气剂和二传手的POJO.它绝对不应该包含任何与服务相关的业务逻辑,因为那时你引入了一个耦合焦点,实体类需要知道可能在其上运行的所有业务流程,完全否定松散耦合SOA的目的.

因此,如果不应该在实体类中嵌入特定于业务流程的行为,则不能对这些实体类使用多态 - 没有要覆盖的行为.

更新2

上述行为被更简单地解释为过载路径被选择在编译时,和重写在路径运行时.

对于它所处理的域模型类的每个子类型都有一个服务实现的子类是不好的做法,那么人们如何解决编译时的重载问题呢？

我正在探索面向服务的基本架构,我想知道如何在整个服务中最好地处理用户身份验证.

作为一个非常简单的示例,假设我们有一个博客应用程序,可以调用其他两个服务:

1. 用于存储用户数据和交换访问令牌凭据的用户/身份验证服务
2. 用于管理帖子数据的帖子服务

假设应用程序的用户正在尝试删除特定帖子,并且只允许具有"admin"角色的用户这样做.

需要提出以下要求:

• app - > auth

  验证当前用户(通过某种令牌).如果令牌过期,应用程序可以将用户重定向到登录表单等.

• app - >帖子

  删除帖子.

• 帖子 - > auth

  在删除帖子之前,帖子服务需要确保请求用户有权这样做.验证当前用户(通过令牌)并确保他们具有"admin"角色.

这是一个非常简单的例子,但我很好奇人们如何在他们的服务中处理auth.似乎每个服务都需要单独调用身份验证服务才能授权请求.是这样的吗？在这种SOA中是否有更好的方法来处理auth？

谢谢!

我开始研究面向服务的体系结构,并想知道如何最好地构建进程之间的消息传递.似乎服务和/或pubsub总线之间的直接HTTP调用是两种常见的方法.在哪种情况下比另一种更有利？我可以看到pubsub如何导致更多的解耦服务,但我也得到的印象是,通过系统跟踪消息的路径变得更加困难.

有什么资源可以了解更多相关信息？在非常小的"手动"服务(即Ruby/Sinatra,Node/Express,Redis pubsub等)的背景下,我对此非常好奇,而不是任何规定的SOA堆栈/套件.虽然我确信同样的原则适用.

谢谢!

我正在使用Spring DI连接我的组件,我遇到了这个问题.

我有一个BaseService类,它有多个实现.它上面的层有一个构建器,它调用服务来获取数据来填充POJO.我需要调用的服务实现(ServiceA,ServiceB)根据我需要构建的POJO的类型进行更改.

在这种情况下,我如何自动装配服务,因为它需要后期绑定服务.我该如何处理这种情况？(Spring DI中的例子真有帮助)

我读了类似的问题,但找不到答案.我读到服务主机等SOA模式为确切的用例提供了不同的解决方案.

请帮忙.谢谢

几年前,媒体上充斥着关于代码重用思想如何提高生产力和代码质量的各种文章.

从我定期检查的博客和网站看来,似乎"代码重用"的想法已经过时了.也许"代码重用"倡导者已经加入了SOA人群？:-)

有趣的是,当您在Google中搜索"代码重用"时,第二个结果标题为:

"内部代码重用被认为是危险的"!

对我来说代码重用的想法只是常识,毕竟看看apache commons项目的成功!

我想知道的是:

• 您或您的公司是否尝试重用代码？
• 如果是这样,在什么级别,即低级API,组件或共享业务逻辑？您或您的公司如何重用代码？
• 它有用吗？

讨论？

我完全清楚有许多可用的开源库,任何使用过.NET或Java的人都会以某种形式重用代码.这是常识!

我更多地指的是组织内的代码重用,而不是通过共享库等社区中的代码重用.

我最初问过;

• 您或您的公司是否尝试重用代码？
• 如果是这样,在什么级别,即低级API,组件或共享业务逻辑？您或您的公司如何重用代码？

从我所在的位置,我看到很少有公司试图在内部重用代码？

如果你有一段可能在中等规模的组织中共享的代码,你会如何告知公司的其他成员这个lib/api/etc是否存在并且可能有益？

根据我对N-Tier和SOA架构的理解.

N层

N-Tier意味着将应用程序划分为多个层,示例I正在asp.net中开发应用程序,我将总数据库层推送到WCF,然后将其称为N层.[紧耦合]

SOA [松散耦合]

根据我对SOA的理解,它是非常通用的术语,以及我们如何将松散地耦合到我们的架构,然后称为SOA.SOA服务的最佳示例 - Stock feeds/weather feed.

我的结论:

即使我们使用WCF开发应用程序,如果它与单个客户端/或.net应用程序紧密耦合,也不意味着它只能了解服务.

你能帮助我理解SOA VS N-Tier吗？

让我们想象一下,我们的应用程序需要从关系数据库到另一个关系数据库的ETL(提取,转换,加载)数据.最简单(和大多数性能,恕我直言)的方式是在数据库之间建立链接并编写简单的存储过程.在这种情况下,我们使用最少的技术和组件,所有功能都是"开箱即用".

但这是SOA(面向服务的架构)的良好实践吗？紧耦合怎么样？我们是否永远将数据库强烈地相互耦合？

还有另一种方法:我们在每一侧构建2个Java应用程序,并通过SOAP Web服务进行通信.这更加SOA友好!但性能下降和额外的失败点值得吗？

在这种情况下,最佳做法是什么？ETL如何适应SOA？