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:
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
- Aligning enterprise data support with the business services
- Enterprise data access as a business service
- Enterprise data bus
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.
Community comments
Layering
by Du Hong,
The advantages of Enterprise Data Bus
by Hu Hu,
Doesn't this confuse logical with physical? And miss a pattern?
by graham berri,
Re: Doesn't this confuse logical with physical? And miss a pattern?
by Boris Lublinsky,
Re: Doesn't this confuse logical with physical? And miss a pattern?
by Eric Roch,
SOA Data Services go beyond ESB/BPEL
by varun sharma,
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.
thequintessentialinquisitor.blogspot.com/2012/0...
This conversation can be explored beyond boundaries I guess :)