InfoQ Article: Incorporating Enterprise Data into SOA

Posted by Miko Matsumura on Nov 21, 2006

Sections

Enterprise Architecture,

Operations & Infrastructure,

Architecture & Design,

Development

Topics

Data Access ,

SOA ,

Patterns and Practices ,

Architecture ,

Enterprise Architecture ,

Patterns ,

Database

The majority of today's SOA design techniques are centered around definition of services. They use 1service-oriented decomposition, based on the business processes, enterprise business/functional model, required long term architectural goals and reuse of the existing enterprise functionality. This approach usually incorporates one of the most important assets of the modern enterprise - enterprise data as an afterthought. In this article we will revisit a typical SOA architecture, outline the complexities of dealing with the enterprise data and discuss several design patterns for incorporating of this data into SOA implementations.

Read Incorporating Enterprise Data into SOA

The article starts off explaining the typical layers in an SOA, followed by some of the issues related to data access:

• Consolidation of data between multiple applications.
• Ownership of enterprise data by services.
• Interface definitions

Boris then presents several patterns for incorporating enterprise data into SOA implementations:

• Aligning enterprise data support with the business services
• Enterprise data access as a business service
• Enterprise data bus

Boris concludes:

As the scope of SOA implementations expands from limited in scope departmental implementations to enterprise-wide undertaking the issues of enterprise data access are quickly starting to become one of the most important implementation issues. If not architected correctly from the very beginning, enterprise data access can become a major problem down the road. Design patterns presented in this article define different approaches to dealing with the enterprise data in the SOA environment along with the drawbacks and advantages of each approach.

1. Back to top

   Layering

   by Du Hong

   "You can always handle complex problems by layering".That's true.

   Reply

2. Back to top

   The advantages of Enterprise Data Bus

   by Hu Hu

   "Because any of the service implementation, in this case, has an access to any of the enterprise data it requires, such implementation allows to significantly reduce coupling between service - service invocation contains only data references (key), which change extremely rarely, while the actual data access is implemented by the service itself using enterprise data bus. This means that if the service implementation requires additional data for its processing, it can access it directly without impacting its consumers."
   
   Can you talk more about the "data references(key) mapping to actual data"?
   How does the service use the key to get the actual data through Enterprise Data Bus?

   Reply

3. Back to top

   Doesn't this confuse logical with physical? And miss a pattern?

   by graham berri

   In Pattern 1
   I'm pretty sure the so-called business services will include at least some services that Boris would regard as data services in other circumstances. I don't mind that, except that it undermines what follows.
   
   In Pattern 2
   If only some data access routines are presented as business services, then pattern 2 is no different from pattern 1.
   If *all* data access routines are presented as business services, that seems like a pointless academic exercise.
   
   Pattern 3
   This seems to add another tier in the platform, meaning extra message passing and network use, and impose another a layer on all applications, meaning extra dev and test effort. For what?
   
   I see the benefit to vendors - more service bus sales. I see the benefit to enterprise architects - one technical architecture imposed on everybody. The benefits to app dev teams are obscure. Extra tiers and layers can complicate more than they simplify.
   
   Missing Pattern 4
   Where BEA sell to an enterprise both an ESB (enterprise service bus) and a DAT (data abstraction technology), then what is to stop the enterprise implementing some "data services" on the ESB and some "business services" on the DAT?
   
   Nothing, unless Boris can redefine for us a data service so as to distinguish it from a business service which (directly or indirectly) accesses enterprise data.
   
   Can you tell the difference when you look at the invocation/reply interface? If you can tell, then how? If you can't tell, then how can you judge whether somebody has implemented any of these patterns or not?

   Reply

4. Back to top

   Re: Doesn't this confuse logical with physical? And miss a pattern?

   by Boris Lublinsky

   Thanks Graham for detailed response.
   One of the things that was important to me when I was writing this article was to try to distinguish purely data service from the business services (I probably did not do it clear enough)
   Business services are autonomous and are designed to minimize coupling, where coupling has many many facets, including temporal one. This means that asynchronous invocation is preferred interaction paradigm for business services invocation. Data services, especially data retrieval often play by completely different rules, they are often synchoronous in nature and require very fast responce time.
   This alone makes you want to logically separate the two.
   The other issue, typical with update services is requirement for multilevel transactional support, which is not the major strength of services implementations.
   These two alone vouch for trying to approach data services differently from business services.

   Reply

5. Back to top

   Re: Doesn't this confuse logical with physical? And miss a pattern?

   by Eric Roch

   Related post (mine):
   
   Data Services

   Reply