News

Using Model-Driven SOA

• By Lee Thé
• April 7, 2008

Balcer said he believes you have to look at SOA from both sides now: from the top (business level) down and from the bottom (IT level) up.

For the top-down view he quoted the Cutter Consortium's Mike Rosen: "SOA is concerned with the independent construction of services, which can be combined to realize meaningful, higher level business processes within the context of the enterprise."

For the bottom-up view he quoted from the book "Service Oriented Architecture for Dummies," which calls SOA a "software architecture for building applications that implement business processes or services by using a set of loosely-coupled black-box components to define a well-defined level of service."

SOA still can use some defining. Conferences like this tend to get the early adopters, yet when Balcer asked how many in the audience were actually doing SOA, only about half raised their hands -- and none reported smooth sailing.

Modeling Can Sidestep SOA Pitfalls
Balcer proposed that you can avoid many of SOA's sophomore slump pitfalls if you model your project properly beforehand. Some IT people have already modeled their business processes, using mature BPM techniques, which break down business processes into distinct activities. So you can simply implement those activities as services and you're good to go – right? Wrong, said Balcer. "Just connecting BPM activities to existing APIs through service wrappers fails to produce SOA's promised benefits."

This wasn't much of a pitfall for the audience, however, since only about a quarter raised their hands when Balcer asked how many have been doing BPM. And only one of them actually generates code from the model. The rest use their BPM modeling as "a basis for discussion."

With that reality check in mind, Balcer explained that SOA isn't just about building and exposing individual services. According to Balcer, "the agility and flexibility promised by SOA requires a sophisticated, layered, service-oriented architecture that addresses the relationships between services and the relationship of those services to a common semantic information model."

Modeling Keeps Coding and Business Goals in Synch
Such an architecture goes beyond modeling business processes. It also models processes within IT and systematizes relationships between all these models, so that your SOA works as software -- and as business activity, according to Balcer. This requires mechanisms to formalize architectures, coupled with development techniques that reduce or eliminate design deficiencies, as well as enforcing architectural constraints.

The business process model comes first. The world's more elegant, stable, speedy software is about as useful as a two-legged stool if it doesn't do something useful. A business process model diagrams the logic and flow of what to do and who does what in particular processes, such as sales order fulfillments. This generates the use cases needed to build the architecture.

Use cases deal with what systems do with external inputs. The use cases describe the flow of events in business processes, almost always incorporating multiple scenarios (what if the check bounces, or the purchase exceeds the customer's credit limit, or the item ordered turns out not to be in stock, even though the inventory said it was?).

Follow the Data
Balcer said he doesn't always see people "following the data when they do their business process models." So not only are business processes organized by who does what but also the business data needs to be organized by who gets what. Then the use cases become business process models, which in turn divide into business process steps and business entities. Then you can create the services and documents needed to realize those steps and entities. For example, a shipping service would include data (documents) providing shipment confirmation, and operations including Request Quote, Request Shipment, Get Status and Cancel Request.

Done right, Balcer said, such services are business-focused, coarse-grained, technology-independent, and they possess interfaces that don't mandate a particular implementation. You also have to resist the temptation to produce traditional object-oriented programming (OOP) objects, he said. "One of the first things people encounter when going from OOP to SOA," Balcer explained, "is that good objects can make terrible services." You have to get away from the idea of just manipulating little things to manipulating business operations.

The challenge is that as soon as you put up a model that looks like a class diagram, developers immediately put an OOP focus on things. However, "when I indicate 'customer'," Balcer warned, "it doesn't mean that all the customer data is stored together."

SOA Isn't Exactly OOP
And it shouldn't matter which technology/products are being used to implement a service. Those BPMs will be realized against business systems -- often multiple kinds that you already have in place.

Balcer defined a service as "the encapsulation of a cohesive set of capabilities, expressed as an interface decoupled from its implementation." You need to be able to partition a problem in such as way as to get a good set of organized services. Balcer asked how many in the audience had heard about "service hierarch" or "service taxonomy." About an eighth had. Balcer urged listeners to break engineering problems apart to make the process steps more understandable, and get to the rationale behind those steps. Then you find the steps that make good candidates for automation.

But you need a tolerance for incompleteness, because it's a continuous process. Hence the saying "eventually you have to shoot the engineers and begin production." He cautioned the audience against "boxitecture" modeling that tries to capture everything, tries not to miss anything, is more elegant than reality, and creates a veneer of organization. It makes for great slideware.

Keep the Models True to the Business
Above all, in order to get to a model-driven architecture, your models need to be exact representations of the problems themselves. Services tend to deal with big chunks of data -- not just isolated things, but formal, defined things that are connected to your model dynamically.

And the model has to nail down what really has to be there, so the person making the XML schema doesn't make something required when it's not, Balcer explained. The IT people have to corner the business people and make them get far more specific than they'd get if left to their own devices.

At the other end, the model absolutely has to match the real organization of things in the real world, whether that's easy to implement in a particular programming language or not. "Models can't be constrained by implementation technologies," Balcer said.

Good modeling keeps IT in synch with the needs of the business. And using model-driven architecture for SOA helps SOA live up to the promise of it being faster, better, and cheaper. But, he said, you need to build the right services, build the right "consumers" for the services, remember that building SOA is still coding, code smart using "one fact in one place," and always keep the architecture in mind. Do these things and Balcer promises you'll be glad you modeled your services properly.