Facilitating the spread of knowledge and innovation in professional software development



Choose your language

InfoQ Homepage News InfoQ Article: Incorporating Enterprise Data into SOA

InfoQ Article: Incorporating Enterprise Data into SOA

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.
We need your feedback

How might we improve InfoQ for you

Thank you for being an InfoQ reader.

Each year, we seek feedback from our readers to help us improve InfoQ. Would you mind spending 2 minutes to share your feedback in our short survey? Your feedback will directly help us continually evolve how we support you.

Take the Survey

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Layering

    by Du Hong,

    Your message is awaiting moderation. Thank you for participating in the discussion.

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

  • The advantages of Enterprise Data Bus

    by Hu Hu,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    "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?

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

    by graham berri,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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?

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

    by Boris Lublinsky,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

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

    by Eric Roch,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Related post (mine):

    Data Services

  • SOA Data Services go beyond ESB/BPEL

    by varun sharma,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    SOA Data Services are not just services operating on XML. Instead SOA Data Services are enterprise data management end-points that expose highly optimized engines for working on all types of data.

    The inherent inefficiencies of XML, associated with large data handling, and the fact that almost all SOA suites are built upon Java containers – it necessitates the use of a highly optimized caching server within the MW tier to Federate IA using SOA. This added setup/maintenance cost of Caching server basically veers us to utilize SOA Data Service alongside Data Federation Tier.

    This conversation can be explored beyond boundaries I guess :)

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p


Is your profile up-to-date? Please take a moment to review and update.

Note: If updating/changing your email, a validation request will be sent

Company name:
Company role:
Company size:
You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.