0

场景:将数据库操作作为web服务

在我的项目,我们有一个Web服务(Apache的CXF,Hibernate和Spring),以用于开发暴露给第三方的一些服务,门户网站(Spring MVC的,门户网站和Hibernate)前端Web应用程序和一些批处理(Spring Batch,Hibernate)操作单独运行。

所有3个应用程序使用相同的数据库并在应用程序级别具有映射&实体管理器。

问题:

上述场景创建更新几乎是在3个地方相同的映射的问题,我们能不能也启用缓存,由于同样的实体将在多个应用程序进行更新,并各自具有独立的实体经理。

我的解决方案:

我已经计划推出一个网络服务,将采取所有数据库操作的照顾,并会由其他3个应用程序使用。所以它会避免上述问题。

您能否帮我调整我的解决方案或者帮助获得新的最佳方法?

回答

0

Ganesh,将您的更新数据集中在一个位置,就像您所描述的那样可以帮助您解决这种情况。你没有描述的是你如何公开Web服务以及理解表关系的实际工作。

通过进行更改可以获得的真正优势是在同一Web服务(或可能在其他位置)集中关于表更新的业务逻辑。 Web服务可以揭示业务对象。

一个典型的简单的例子:

 

    Business Purchase Order = Table Purchase Order 
          + Table Purchase Order Lines 
          + Stock Available reduced by Order Quantity 

过去的事情我想是多个应用程序需要管理这些表的更新,或者调用在一个紧密结合的关系,以减少库存的股票应用程序可用。但是,公开采购订单并担心新的Web服务中的相关表更新会确保每次增加系统的可维护性时发生相同的方式。

如果您将Web服务暴露视为一个对象组合,如下所示,那么您可能会考虑是否要重新考虑Web服务实际上在做什么以及是否需要另一个抽象层,但这是一个更长的时间讨论。

 

        WEB SERVICE 
       +-------------------+ 
       | Service Contract | 
       +---------+---------+ 
    Message -> | Message | Core | 
       + Parsing | Service | <-> Backend <-> Persistent Storage 
    Message <- + Logic | Logic |  + other 
       +---------+---------+  Services 

我希望我没有说明明显,这有助于。祝你好运。

+0

谢谢@geoffc ..我已经有了一些想法,但是你给了我一个很好的想法,可以在所有领域思考......现在与团队一起讨论这一变化。谢谢你的帮助。 – Ganesh 2013-05-06 09:13:16