Con-Way: use semantic objects for event-driven SOA |
 |
By Rich Seeley, News Writer
31 Jan 2007 | SearchWebServices.com |
|
|
Maja Tibbling, lead enterprise architect, enterprise services at Con-way Inc., encourages enterprise architects to develop a canonical model of key business objects in their organization, but she discourages them from attempting a big bang approach to it.
|
|
|
|
|
In the middle, it's all XML, but as you translate it to the end points, it's translated to whatever they require.
Maja Tibbling
Lead Enterprise Architect, Enterprise Services, Con-way Inc.
|
|
|
|
|
|
|
|
|
|
Developing a canonical object model to aid data transformations was a key recommendation in her talk during the opening session of this week's Open Group's Enterprise Architects Practitioners Conference in San Diego. Tibbling has led development of SOA applications for Con-way, a $4.2 billion freight transportation, logistics, supply chain management and trailer manufacturing company, so when she speaks the architects and would-be architects in the room tend to listen.
"The canonical model is key," she said in an interview after her talk, "because SOA and event-driven architecture are really about integration. What the canonical model provides is semantic abstraction of the input, semantic abstraction of consumers, target systems, external users, customers. All these things can be abstracted in the integration layer in the canonical model."
But when it was suggested that an architect might become overwhelmed at the prospect of defining all the possible objects in an organization, she was quick to say, "That's not what I'm advocating at all."
She advocates a simple approach based on four principles. First, only define the objects as needed for the project at hand. Do not go off, trying to define every imaginable object throughout the organization. Second, accept the fact you won't get even a limited set of definitions right the first time, so be flexible about making changes. Third, do the canonical model in XML so it is extensible. Fourth, avoid being so specific in the definition that you discourage reuse.
"The process for creating a canonical model is not to follow the big bang and try to define everything," Tibbling explained. "But as you have the need for services, you do what's needed there, but with enough architectural sense to not embed too much of the project into the context. You need to understand where the boundary is for the canonical object that you're going to reuse. For example, getting a clear understanding, let's say there's a change to a contact name in the accounts receivable (AR) model. Obviously, the AR system has its own view of what is a contact, but what I wouldn't want to do is include AR information in my canonical form for contact. What we're talking about at the canonical layer is a clear object without business process content, so you can reuse it over and over again."
Since an object library is going to take some effort even when starting small and evolving, the question arises as to why it is important to the successful SOA implementation. Tibbling offers an example of what it does and why it's important.
"Let's say we need to propagate a customer change of address, for example, in the AR system," she says. "What we end up doing is getting an event triggered on the customer system side that says, 'This is an address change.' We take the form that comes from the customer and now translate it into our canonical version of the customer. It is then republished back out into the bus as an event, but it's in canonical form now."
While the canonical model is in XML at the integration layer, from the enterprise service bus it can be translated into whatever format the consuming system, even a pre-XML legacy system needs it in, she explained. XML is important to the canonical model, since that standard can be translated into a variety of data formats.
"I publish the address change in canonical form and every system that cares about that customer change can subscribe to that change, but then translate it in their own processes to their own semantic version. In the middle, it's all XML, but as you translate it to the end points, it's translated to whatever they require."
All this is important because without the canonical model, the developers would have to publish an event such as the address change in every format that the various legacy systems might require, a proliferation of data models that would defeat the goal of SOA, Tibbling explained.
|
|
|
|
