SOA 设计中数据访问层 (DAL) 的使用
由于我们正处于将应用程序重新注入 SOA 设计的初始阶段，所以我有一些问题无法得到明确的答案/图片。
我阅读了大量书籍，主要围绕 Thomas Erl 的书籍，并遵循理解任务服务、实体服务和实用服务的设计模式。
我遇到的问题是 DAL 的整体概念。因此，这更多的是对理解的验证或澄清，以帮助为我们的平台制定最佳方法。
那么背景。我们目前有几个基于网络的电子商务应用程序，这些应用程序几乎都是在孤岛中构建的，而且几乎都是彼此的副本。我们有支持应用程序，例如守护进程和杂项 Web 服务。其中许多应用程序的历史已超过 5 年，并且仅基于技术（模型 1）构建。我们所有的应用程序都以拍卖销售为中心。因此，在销售活动期间，我们将接受用户的出价，确定谁获胜并显示该信息。每个销售活动都有一定的时间可供用户使用。
该公司正在转向 SOA 解决方案，因为我们最终所做的很多事情不仅可以在我们的团队之间共享，而且可以在其他团队之间共享。
所以我对 DAL 的理解是，它本身是一项位于数据之上的服务，在本例中是不同的数据库 - MSSQL、ORACLE、MSSQL。每个数据库都有不同的模式（Oracle）等。
因此服务（任务、实体、实用程序和表示层，如果需要）将调用 DAL 来检索数据。 DAL 的责任是根据消息的内容来确定需要执行哪些操作才能满足请求。
例如，我们有一名安全部门候选人。该服务需要使用 LDAP 进行身份验证，并根据为给定应用程序存储的数据进行授权。
这里的想法是，将创建一个实用程序服务来封装与 LDAP 通信所需的所有操作，并且安全服务将调用实用程序服务和 DAL 来获取授权数据。然后，DAL 有责任访问正确的数据库/模式来检索信息。该信息将采用 XML 格式（标准 SOA 通信）。
那么，我走在正确的道路上吗？其他人是否做过类似的事情？我还需要考虑哪些其他事情（目前正在统计我们在一小时内平均接受的出价数量）。
每个服务是否应该有自己的 DAL - 例如，安全服务是否应该将 DAL 作为服务的一部分，或者 DAL 应该是所有服务都可以使用的共享服务？
As we are in the beginning phases of rejuvenating our application in to SOA design I have some questions that I can not get a clear answer/picture on.
I have been doing a lot of reading, mostly around books from Thomas Erl and following that design pattern of understanding what Task Services, Entity Services and Utility Services are.
What I am stumbling on is the whole DAL concept of how that would look. So this is more of a verification of understanding or a clarification so as to help make the best approach for our platform.
So background. We currently have several web based e-commerce applications that have been pretty much been built in silos and are again pretty much a copy of each other. We have supporting applications such as Daemons and misc web services out there. Many of these applications are older then 5 years and are build on only technology (Model 1). All of our applications are centered around conducting auction sales. So during a sale event we will be taking bids from users, determine who is winning and display that information back. Each sale event has a set amount of time that they will be available to the users.
The company is moving towards a SOA solution as a lot of things we end up doing can be shared across not only our group but across other groups.
So what I understand on the DAL is that it in itself is a service which will sit on top of Data, in this case different Databases - MSSQL, ORACLE, MSSQL. Each of these databases have different schema's (Oracle) etc.
So the services (Task, Entity, Utility and Presentation Tier if needed) will make calls to the DAL to retrieve data. It is the responsibility of the DAL to know, from the contents of the message to determine what it needs to do in order to fulfill the request.
So for example, we have a Security Service candidate. This service needs to authenticate with LDAP and to authorize from the data that is stored for that given application.
The thought here is that a Utility service will be created to wrap up all the operations required to communicate with LDAP and that the Security Service will call upon the Utility Service and to the DAL to fetch the authorization data. The DAL then has the responsibility to go to the correct database/schema to retrieve the information. The information will be in XML format (standard SOA communication).
So, am I on the right track here? Have others done similar things or not? What other things do I need to consider (Currently getting the statistics on how many bids we take in an hour - on average).
Should each service have its own DAL - for example should the Security Service have the DAL as part of the service or should DAL be a shared service in which all services can use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在您的例子中，用于基于 SOA 的完整部署的方法是使用 ESB、身份提供程序和数据服务解决方案。
分解来说，DAL应该使用数据服务来实现，这样，该服务将以语言中立的方式成为全局可访问的服务，并且支持重用和松耦合。因此，您的所有数据访问逻辑都可以作为数据服务中的 Web 服务操作来实现。
因此，对于身份验证和授权管理，在 SOA 世界中，有一个名为 XACML 的标准，它是用于细粒度的授权管理。因此，您将需要一个 XACML 服务器，该服务器将根据特定标准对用户进行授权，并且还应该能够使用 LDAP 进行身份验证。
然后，您的“安全服务”将在 ESB 的服务中实现，该服务将查询身份提供者进行身份验证/授权，并根据其响应，它将调用数据服务中的适当操作，并使用适当的参数来获取数据，并返回给用户。
上述场景可以分别使用WSO2 Data Services Server、WSO2 Identity Server和WSO2 ESB来实现，这些都是开源产品，可以免费使用并找到
In your case, the approach to use for a full SOA based deployment would be to use an ESB, Identity provider and a data services solution.
To break it down, the DAL should be implemented using data services, in this way, this service will be a globally accessibly service in a language neutral way, and will support re-use and loose coupling. So all your data access logic can be implemented as web service operations in a data service.
So for the authentication and authorization management, in the SOA world, there's a standard called XACML, which is used for fine grained authorization management. So what you will need is an XACML server, who would authorize the user according to a specific criteria, where this should also have the ability to authenticate with LDAP.
Then your "Security Service" will be implemented in a service at the ESB, where that service will query the identity provider for authentication/authorization and according it's response, it will call the appropriate operations in the data service, with suitable parameters to fetch the data, and return it to the user.
The above scenarios can be implemented using WSO2 Data Services Server, WSO2 Identity Server and WSO2 ESB respectively, which are open source products, and can be freely used and found here.
我曾经参与（开发）一个使用“数据服务”的 soa 项目。那是前一段时间的事了，我只参与了一些，但我的记忆是，它最终变得太复杂和缓慢。
特别是我们并不真正需要数据服务 - 将相同的抽象放在库层中会更有意义，这会带来更好的效率并且不会真正损失功能（对于我们的特殊需求）。由于往往要求提供许多小"块"的数据，这一事实加剧了这种情况。
我想这取决于实施过程中涉及的权衡。在我们的例子中，通过相对封闭的系统和单一的底层数据库技术，我们可以轻松地利用数据库提供的分布式访问支持；相反，我们最终在一个更慢、更通用的消息总线中复制了这个，这除了复杂性之外没有增加任何东西。但我可以很容易想象不同的情况，其中数据的访问更加“遥远”。
i once worked with (developing) an soa project that used a "data service". it was some time ago, and i was only involved marginally, but my recollection was that it ended up being too complicated and slow.
in particular we had no real need for a data service - it would have made more sense to have placed the same abstractions in a library layer, which would have given better efficiency and no real loss of functionality (for our particular needs). this was exacerbated by the fact that the data tended to be requested in many small "chunks".
i guess it comes down to the trade-offs involved in the implementation. in our case, with a relatively closed system and a single underlying database technology, we could have easily exploited the support for distributed access that the database provided; instead we ended up duplicating this in a slower, more general, message bus, which added nothing except complexity. but i can easily imagine different cases where access to data is more "distant".
如何在设计中使用 SOA 取决于其需求。
一般来说，您可以编写粗粒度服务并将它们公开为 Web 服务。在您的情况下，您可以编写一些调用数据库并生成结果的服务。在这种情况下，授权逻辑也可以与服务逻辑一起编写。
另一种方法是使用 ESB 或 BPEL 引擎编写集成逻辑并将集成服务公开为 Web 服务。在这种情况下，您可以使用一些数据服务以 xml 格式公开数据库数据并集成它们。您可以为不同的酋长使用服务，并使用请求数据调用正确的服务。并且授权逻辑还可以添加到服务集成逻辑中。
身份验证、机密性、完整性等安全方面被视为非功能性需求，因此可以参与任何服务而无需编写显式安全服务。
以下文章描述了第二种方法中提到的可能的服务集成示例。
http://wso2.org/library/articles/2011/05 /集成业务规则-bpel
http://wso2.org/library/articles/2011/06/securing -网络服务集成
How you have to use SOA for your design is depends on the its requirements.
In generally you can write coarse grain services and expose them as web services. In your case you can write some services which calls the databases and produce the results. In this case authorization logic can also be written with the service logic.
The other approach is to use an ESB or BPEL engine to write the integration logic and expose the integrated service as a web service. In this case you can use some data services to expose data base data in xml format and integrate them. You can use services for different sachems and call the correct service with the request data. And the authorization logic can also be added to service integration logic.
Security aspects such as authentication, confidentiality, integrity is considered as non functional requirements and hence can be engaged to any service without writing an explicit security service.
Following articles describes such sample possible integration of services as mentioned in the second approach.
http://wso2.org/library/articles/2011/05/integrate-business-rules-bpel
http://wso2.org/library/articles/2011/06/securing-web-service-integration