Thursday Aug 02, 2007

SOA lessons learned from business process automation

Business process automation taught us to separate business process logic from execution of business activities. Today, it teaches us about reuse of services in SOA-based systems.[Read More]

SOA services != RPC

So where do services come from?

That's actually a more profound question than it appears at first blush, especially if you are a hands-on, code-first sort of developer like me. Profound, for it goes directly to the value (potential value, perhaps) of a system built using a service-oriented architecture.

What is the value of SOA? Reuse. That has always been its strength, or at least its promise. But this is not the same as code reuse, the holy grail of software design since the invention of the subroutine.

Where then, do services come? We must look not to code, or other artifacts of service implementation. Instead, we must look to business processes. The elements of reuse in a business process are business functions. Reusable business functions are what enable the quick, reliable creation (or modification) of business processes possible. Business agility (I hate the phrase; it sounds like market-speak) depends on such services. Shorter time to market, high quality, avoiding any code creation: all things that help create business value.

How do you create such services? Simply by looking at business processes, mining the common activities that comprise them. Do some processes involve a credit check of a customer? Sounds like a candidate for a service. Notable SOA thinkers have developed nuanced models of services in a layered fashion (John Crupi's "lasagna" model, for instance), but the basic principle applies: the high-value reuse occurs at the business process level. It's what makes modern SOA worthwhile, and not simply a language-neutral way of packaging libraries: reuse at the service composition level.

This is in sharp contrast to how a lot of services are identified and implemented today. Many developers, with a very code-centric world view, very naturally look to their available reusable code assets (libraries, APIs to useful applications, and the like) when then look to service creation. After all, these are proven candidate for reuse already, and wrapping them with more technology-neutral interfaces (web services and the like) should make them even more reusable. Very logical.

Logical, but off target. This completely misses the value of reusable services, as discussed above. Repackaging code assets is really an exercise in RPC. Does it create the benefits of reusable services that can be used for process composition? No, for such code assets are the fine-grained stuff from which such business functions \*may\* be created, but aren't those business functions themselves. It is rather pointless to use a lot of RPC to write somethng that is more easily, and efficiently, realized in native languages (C++, Java, etc.).

So what is the lesson here? As the title of this piece says, RPC is not equal to SOA services. Services must be designed from a different centre than code reuse. Process composition is the proper centre of service design.

This is, in many ways, what the business process automation folks have been telling us for years, but that is for another entry.

Tuesday Apr 24, 2007

What makes a service reusable?

A typical scenario: a department in a company deploys a service into its production environment. It turns out the service is quite useful, and gets reused in a variety of business processes supported by the department. We have a success story, a poster child for SOA adoption, right? All too often the answer is "wrong!"

Why wrong? Just wait for the second shoe to drop... the service is too successful, and is reused by consumers far and wide in the company. Suddenly it slows down, adversely affecting business processes. People get grumpy, and fingers are pointed, and emergency plans must be hatched to scale the service to cope with its own success.

This scenario plays itself out every day, and it points out a lot of different deficiencies that all point to the need for both design- and run-time governance of any SOA system. I'll save design-time governance for another day, and dwell on some aspects of run-time governance of the system.

First, a definition, then an assertion. A policy enforcement mechanism (PEM) is a mechanism in the SOA infrastructure where run-time policies (security, SLA and the like) are enforced. The PEM can enforce access controls, ensure schema compliance, guard against over-use of a service, load balance, do content-based routing and much more.

Now the assertion: a service isn't really reusable unless it is offered through a PEM. The PEM gives you operational control of the service that is completely unrelated to the logical function provided by the service. SOA enables reuse, but unregulated reuse can result in an inability to control that reuse in any fashion. In some environments that might be just fine, but in most commercial environments such a collegial situation is rare, and the risks of suffering a meltdown (as illustrated in the little scenario above) quite real, and very costly (not to mention career-limiting :-) ).

This bears restatement: a service offered without run-time policy enforcement mechanisms is not truly reusable.

Regulating reuse is just the tip of the iceberg. It is an instance of a more general problem of ensuring that services comply to all applicable policies within the production environment. Examples include auditing requirements, privacy controls (e.g., all SSNs are to be encrypted), and even service mediation (versioning, or perhaps protocol). And just to make things worse, compliance is a moving target: legal requirements change (both over time, and by legal jurisdiction), as do internal policies.

This sounds like it is pointing to a massive application maintenance headache. How it the world do I write services that comply to all these extra, changing requirements, when it is tough enough just getting the core service functions right in a timely fahsion? How do I respond to what are operational issues and needs from within the normal software development life cycle?

Fortunately, there is a better way than brute-force, code-first solutions. The good old trick of "separation of concerns" is very handy here. Our PEM can be completely removed from service providers, and placed into a Policy Enforcement Point (PEP) in the SOA infrastructure. This separates the concerns neatly: the service provider concentrates on supplying the core service, and nothing more. The PEP "protects" that core service by acting as an intermediary between the service provider and the service consumer, enforcing all applicable policies so that the provider will only receive messages that are compliant. Further, the policies enforced by the PEP can be changed without affecting the service provider, allowing policies to be changed quickly and frequently, and completely outside the service's software development life cycle.

The service consumer, obviously, deals not with the service provider, but the PEP. The service offered by the PEP is often referred to as a "virtual service".

There is a lot more to be said about this. If you are interested in practical, policy-guarded service reuse (and that should be most of you SOA folks), and you are attending JavaOne in May, please attend TS-8459, titled Service Virtualization: Separating Business Logic from Policy Enforcement, Wednesday May 9th, at 6:35 PM. I'll be co-presenting this talk with Scott Morrison, from Layer 7 Technologies, who has a lot of experience with service virtualization in SOA systems. I hope to see you there!




« June 2016