LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

SOA Begins at the Data Layer


By David S. Linthicum
July 1, 2007 — 
Those who build SOAs have one thing in common—the use of services to create an architecture that’s both agile and better supports reuse. While services are a key component to SOA, the “A” in SOA stands for “Architecture,” and that’s where you need to begin...working from the data up to the services.

Think of SOA in layers, as with most architecture. Typically, at the lowest level you have information, either existing in databases or enterprise applications. The services sit on top of the data, both as transactional services that are more behavior-oriented and as data services that are more data-oriented. From there you move up into messaging (ESB, for instance, and it’s optional), and perhaps a process/orchestration layer for forming and reforming the services into true business solutions. Of course, you have to keep track of the services using registries and repositories (SOA governance really), and security systems to ensure that no bad or dumb people access your services.

So, given that SOA is so complex, why focus on the data first? It’s really about building the right foundations for your architecture, and data is the place to start. Indeed, as we build SOAs, the first step is having a clear, semantic understanding of the problem domain, and then dealing with logical abstraction of the data, and how the data exists within services. Let’s start from the beginning.

Having a semantic understanding of your problem domain means that you know information about all of the information aggregated and abstracted within your SOA, including what, where, why, who, how and validation. This, in essence, becomes the SOA metadata layer that allows you to mix and match the right data within the right services to make sure you have all of the services exposed to solve any potential business problems, now and into the future. This means that all databases and enterprise applications must be understood at the semantic levels, including their interfaces, security issues and anything else that matters to other entities that are consuming the information.

This is where most SOAs fall down, considering that the architects are just not willing to gain a complete understanding of the application semantics, and thus can’t build useful services, and thus the services can’t be orchestrated into solutions. So, you need to bite the bullet now, and gain a complete semantic understanding before moving up the stack.

So, what does this mean? It means going over data dictionaries, reverse-engineering database schemas, actually reading ERP and CRM application manuals, and other unnatural acts that most are not willing to do. Moreover, you must understand as well as record, including entering this semantic information into a design repository, design-time governance system, or worst case, Microsoft Excel.

Next, let’s think about abstraction, or the ability to reshape the underlying, typically ugly structures into something that’s useful for our SOA. There are two components of this abstraction: logical and physical.

Logical data abstraction is a design-time concept, meaning that we are taking the existing physical and logical database structure and remapping it so that it has better logical order for the services we are exposing. We create general entities for particular concepts such as customer, product, sales and the like. Typically these entitles are made up of many different and diverse databases that are combined together through a virtual schema that only exists within middleware, but is an abstraction of many back-end physical databases of all shapes, sizes and types.

Next we think about the physical abstraction, or actually selecting database abstraction software, and creating the physical maps from the back-end databases to the virtual representations. Guys like Composite Software typically work well here, providing a configuration layer between the back-end physical databases, no matter how bad the designs, to a well-defined virtual schema, but with improved logical mappings of the information to meet the needs of our SOA. Moreover, since the mapping exists within the configuration layer, the physical database is not coupled to the abstraction, thus is changeable at any time, and thus provides better support for agility.

So, while the data is indeed boring to many developers, not paying attention to it means not building the proper foundation for your SOA. Those who miss this step will fall down later, claiming it was the concept of SOA that caused their issues, when really it was their own darn fault. Neglecting the information is the most common mistake being made as organizations implement their first SOAs. Don’t be part of that crowd.

David S. Linthicum is the CEO of the Linthicum Group. Reach him at david@linthicumgroup.com.


Share this link: http://www.sdtimes.com/link/30805
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading