|
|
AS OF 7/4/2008 8:23PM EST
|
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.
|