Free Newsletters

   All InfoWorld Newsletters
Real World SOA | David Linthicum » Service Design for Service Externalization

August 15, 2007 | Comments: (0)

Service Design for Service Externalization

Most of my projects are "real world," and as such things are never perfect. While most think about SOA as the design and development of these new shiny services that are perfectly designed, tested, and implemented, the real world is that most services leveraged within an SOA are from existing interfaces (e.g., APIs) that are abstracted, and exposed as services. That being the case there has not been much thinking around this approach, which is a bit different than designing and building services from scratch.

So, how to you approach service design for services that are externalized from existing interfaces? It's really a matter of understanding, defining, and designing.

Understanding

First, you need to figure out what you're dealing with. There are many types of interfaces that can potentially become services. For instance, APIS, user interfaces, transactions, and direct-to-hardware interfaces (e.g., impeded interfaces). Each type if interface requires different approaches, techniques, and enabling technology. Here, it's best to work back from the interface to a level of abstract data and behavior…that's how you'll feed your services.

Defining

Next, you need to define the interface at a high level. Typically, they produce or consume information, but may provide more direct access to behavior as well. Thus, define the structure of the information, and the functions that act upon the data. In other words, what are the raw structures, and what behaviors are externalized along with the data?

Designing

Once you understand the mechanisms to deal with the interface, and the meta-service information (data and behavior) around it, it's time to design the service. I've written a lot on service design, so I won't discuss it here. However, what is different with externalization, when it comes to service design, is that you really should consider the layers of abstraction under the service, and the unique nature of those interfaces and how they drive design.

You'll find that the interface mechanisms really control how your services are defined, designed, and implemented. For instance, it's difficult to normalize services that are bound to interfaces…one interface-one service. Therefore, it's difficult to break apart the services as autonomous units since they in essence reflect an abstraction of the interfaces, and are indeed tightly coupled to the interfaces.

Not pretty, but not ugly either. Good luck.

Posted by Dave Linthicum on August 15, 2007 03:07 PM


RATE THIS ARTICLE:





 

  •  
  • COMMENTS




What troubles me about this post is that there is very little recognition of the patterns of services that can help reduce coupling between the service provider and consumer.

Services that are used to return read-only data are fundamentally different from services that perform functions. That much is clear. What is not clear, from this message and from prior messages on 'service design' is whether you find 'command and response' services to be a pattern or an antipattern.

I ask because you state that services provide "access to behavior" yet, in order for the consumer to be truly decoupled from the provider, only the most abstract notion of the behavior may actually be shared. Otherwise, you are sharing more than the interface... you are sharing specifics of the behavior, and that creates tight coupling.

Blog: http://blogs.msdn.com/nickmalik/archive/2007/08/07/getting-away-from-request-and-response-soa.aspx

What is your stance on exposing the behavior of a service?

Posted by: Nick Malik at August 18, 2007 09:34 PM

Technology White Papers

 

InfoWorld Technology Marketplace

» Technology White Papers Library

Technology White Papers by Topic

Technology White Papers E-mail Alert

Find out when the latest white paper is available:
 
 
» BUY A LINK NOW

Sponsored Technology Links