![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
A domain model can be thought of as a conceptual model of the system being built. It describes the entities in the system and their relationship. The domain model is used to establish the boundary and concepts of the system. The domain model also helps identify the attributes and important methods of those entities.
When you apply OOP (Object Oriented Programming) principles to the domain model, it gets the object flavor. Martin Fowler defines domain model as An object model of the domain that incorporates both behavior and data. This is one way to realize the domain model, but not necessarily the only way.
Most of the traditional OO systems and programs consist of business objects manipulating hierarchies of domain data objects. The data objects are generally thin wrappers around the business data in tables with typical data access and relationship navigation methods. They capture the core data model from the database and also the business rules that apply to this data. A typical example of this pattern is the Java™ EE session bean and entity bean, where session beans act as business objects, while entity beans are data objects. Good or bad, this practice is sometimes referred as the Anemic Domain model. (See Resources)
The object oriented domain model has its use cases, and works well in closed systems, such as gaming systems. I will not try to reiterate the benefits of OO systems here. On the other hand, the object domain model also has its limit, particularly in SOA environments, where flexibility and solutions spanning multiple layers and systems are of paramount importance. Let's examine these limitations, and look at other possible domain models.
Problems with the object domain model
Anybody who has experience with the object domain model will testify that to build a system based on the object domain model, a major part of the coding effort is dedicated to creating object wrappers around the applications business data. Suppose you have a simple domain model for a banking application, like this:
Figure 1. Simple domain model of a banking application
In the object domain model approach, the first thing you do is to create a separate thin wrapper class for Customer, Account, and Transaction. These wrapper objects will need to define attributes to hold business relevant data. Furthermore, these wrapper objects have to be augmented and implemented with these behavior methods:
- Persistence methods: load from and save to persistence store.
- Validations methods: validate data conforming to business rule.
- Relationship methods: navigate the containment relations among objects.
That's a lot of code to write and maintain, even though modern languages may provide some frameworks and code-gen tools to automate part of it, such as Toplink or Hibernate.
You can have either a simple object domain model, which looks very much like a relational database schema model, or a complex rich domain model, which can look different from the database design. Either way, you have to write or generate code to do the object-relational mapping.
Automated object-relational mapping may seem easy to get started, but it will get more complicated as time passes. It is a very tough problem to solve because it is trying to bridge two fundamentally different domains: the way in which a relational data store is designed is subtly -- and yet profoundly -- different than how an object system is designed. See Resources for more information on issues around object-relational mapping.
The solution? Give up on objects! In certain scenarios, an object-oriented approach creates more overhead than it saves, and the ROI simply isn't there to justify the cost of creating a rich domain model, let alone spending tons of money and effort to map it back and forth to a relational database.
Simple navigation between the object hierarchies is inherent in the data object model, but advanced search and navigation capabilities in the object hierarchy must be implemented for each search criteria (for example, findTransactionsByCustomer for the scenario given above). To implement these kinds of queries, you will need intimate knowledge about the database schema, and will end up with a fairly complex logic implementation.
Objects have no inherent constraints, so explicit coding is required to implement the data validation.
As you can see from the above, data object wrappers constitute a major part of an application's code. During any project implementation, you will find yourself spending a lot of effort on managing the data objects instead of implementing the business logic. You have more code to develop and maintain, resulting in longer application development cycles, more bugs, and more cost. Furthermore, if any data schema changes, you will need to modify the whole object hierarchy. If you use third-party mapping tools to do the mapping, then your application is tied to that tool, creating a tight coupling between the domain layer and database layer.
Service-oriented architecture (SOA) is an architectural style with the goal of achieving loose coupling among interacting software agents. It is an evolution of distributed computing and modular programming. SOA assembles applications out of software atomic services, which are reusable components, but at a much coarse-grained level. Although different styles of services, SOAP services and REST services have different ways to describe services; both prescribe service messages in XML, confined by a schema written in a language such as XML schema from W3C. We can claim that XML is the "currency" of SOA. There are some recent developments which will further facilitate faster adoption of XML as a first-class domain model in SOA solutions.
To become agile and responsive enterprises, it is vital that business goals and requirements drive IT development projects. SOA is gaining much support in the industry because it views enterprise solutions as federations of services connected by well-specified contracts that define their service interfaces and data format. In the SOA world, the domain object is not created by the programmer programmatically using a particular language, but increasingly by the business analyst (or industry standard) using an XSD declaratively and a language independently. This is the philosophy of "schema first" Web services -- or "interface first" programming for SOA.
With the publication of XQuery 1.0 and XPath 2.0, there are more powerful and efficient tools available. These work together to let XML users locate and interrogate XML documents in general, and to navigate around inside a tree-structured representation of such documents for systematic end-to-end processing. XQuery handles the interrogation, and XPath the navigation, saving both time and code for XML data manipulation.
Newer releases of databases, such as IBM DB2® v9, support XML data as a first class type. DB2 is extended to include:
- New storage techniques for efficient management of hierarchical structures inherent in XML documents.
- New indexing technology to speed searches across and within XML documents.
- New query language support (for XQuery), a new graphical query builder (for XQuery), and new query optimization techniques.
- New support for validating XML data based on user-supplied schemas.
- New administrative capabilities, including extensions to key database utilities.
- Integration with popular application programming interfaces (APIs) vides native support.
DB2 enables client applications to work with both tabular and XML data structures through either SQL (including SQL with XML extensions, often referred to as SQL/XML) or XQuery. Therefore, even if your data is still stored in relational tables, it can be queried and published as an XML stream for your application layer.
Figure 2. Integration of XML and relational capabilities
In the SOA world, we know XML Web services are the answer. But using our favorite object-oriented languages, such as Java or C#, we have a tendency to create and use object proxies to send and receive Web services, and expect our XML messages to be automatically bound to objects by the underlying Web service engine toolkit. Arguably, XML maps to objects better than tables map to objects. The simplest cases will always work, but if you throw in industry standard XML language, like OAGIS, HL7, ACORD, IFX, or OTA, your toolkit's code generator may not be able to handle the complexity of the XSDs. Even if your toolkit is up to its task, creating and maintaining tons of generated objects are just burdensome and inflexible. Any change in schema requires full code regeneration. Furthermore, navigating those generated XML-based objects is not intuitive at all.
Adopt XML as a first class programming model
If:
- Business applications predominantly focus on creating, manipulating, storing, and presenting business data,
- Business data is increasingly modeled as XML,
- Databases already provide native XML support, and
- The newer version of XPath and XQuery allow us to navigate and manipulate XML much more efficiently,
then why can't we use XML as our first class data and programming model, given all the problems we learned the hard way with object-relational or OX mapping?
In this model, the application code can use the DOM, JDOM, SDO (and so on) API to perform the business logic. Using XPath for navigation makes the application code more understandable by illustrating the relationships in the business data that are being manipulated. Ideally, the data should be persisted as pure XML in the database, but even if the data is stored in relational tables, it can still make sense in many cases to first transform it to XML for manipulating in the application.
Since XML inherently maintains the relationship between data structures, the need to create a separate object hierarchy to capture the relationship between the individual data structures is irrelevant. Besides, XML already has a standard object model called the Document Object Model (DOM). Implementations of this model handle construction, modification, and serialization of the XML data. It is a trivial task to load, modify, and save XML data in a business application. Also, you don't need hand-coded validation logic anymore, since constraint checks and schema validation are built into the XML model. All of this translates into less code (which is always a good thing), fewer chances for bugs, and decreased maintenance.
Easy navigation and flexibility
Business logic code is easy to read because XPath describes the exact nature of the data and its relationship to the business structure. XPath 2.0 gives you additional capabilities for search and navigation. Furthermore, XPath expressions can be very easily externalized, giving the ability to path an expression without changing code, even when the XML structure changes. This is a very much desired flexibility, especially in an SOA environment.
You should expect better run time performance using this XML-centric approach, since you do not create extra objects, which requires garbage collection. You will appreciate this even more when you are dealing with very large XML files.
In a typical SOA solution, data needs to be serialized across different layers (the client, process, service bus, and service layers) of the application. The most suitable data format for the flow is XML. In each layer, the data can be queried, transformed, and updated, so as long as the XML nature of the data is maintained, then it is possible to use a different language (like Java, JavaScript™, PHP, or XQuery) to manipulate the data. Even though the surrounding languages might be different, the language used to traverse the XML document is the same in all the layers: XPath, with expressions that can be externalized and shared across all layers. This seems to be a much elegant and consistent way to build distributed SOA systems.
-
AnemicDomainModel, Martin Fowler
-
Object-relational impedance mismatch, Wikipedia
-
Example of OR Mismatch, Ted Neward
-
OX Mapping, Joe Wood
-
FastSOA: Accelerate SOA with XML, XQuery, and native XML database technology
-
Service Data Objects (SDO) 2.0: Create and read an XML document based on XML Schema
-
Understand the XML Data Model
-
Service Oriented Architecture and IBM
-
IBM developerWorks Web services and SOA zone
Table of contents
Next steps from IBM
Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.
- Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
- Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
- Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
- Buy: Rational Service Tester for SOA Quality
