LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 2/1/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Visual Studio 2010 Release Candidate Available Today
A Visual Studio 2010 release candidate is available on MSDN.
02/09/2010 09:45 AM EST

Is Microsoft eyeing Office subscription pricing?
Microsoft may be preparing to offer a new Office pricing option called "union," which charges the same for cloud as on-premises.
02/01/2010 09:38 AM EST

Facebook rewrites PHP runtime
Facebook is about to open source its own PHP runtime, written from scratch for speed.
01/30/2010 08:53 PM EST

 

Events calendar tab
Macworld 2010
2/9/2010 to 2/13/2010
San Francisco
IDG World Expo

SPTechCon 2010
2/10/2010 to 2/12/2010
San Francisco
BZ Media

PyCon 2010 (Python Conf.)
2/17/2010 to 2/25/2010
Atlanta
Python Software Foundation

Southern Calif. Linux Expo
2/19/2010 to 2/20/2010
Los Angeles
SCALE

IBM Pulse
2/21/2010 to 2/24/2010
Las Vegas
IBM


 
print Printable version 
Most Read Latest News Blog Resources
Facebook brings HipHop to PHP
HipHop compiles PHP to speed up the Web layer at world's most popular social networking si...

Adobe moves LiveCycle application platform to the cloud
Release gives developers just what they need to create targeted business process-oriented ...

Oracle acquires AmberPoint
Today's merger will probably affect most of AmberPoint's existing partnerships with other ...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

The Black Box of SOA


By Andrew Binstock
April 1, 2006 — 
Now that service-oriented architectures are really taking off, the first reports of serious problems are starting to drift in. Not surprisingly, the challenges of SOA are proving that the happy picture of loosely coupled systems communicating over standard protocols hides tremendous complexity. The two key issues—development and management—are driving managers nutty.

Let’s start with development. There are very few tools today that cater to the needs of SOA and Web services development. I am not here referring to design tools, of which there are many— albeit not terribly useful. Rather, I am thinking of true development products. At every step—coding, debugging, implementation—the unique aspects of Web services are poorly supported.

Take, for example, coding. Even today there are promoters of Visual Studio and other tools who still delight in pointing out that a single line of code can transform a function into a Web service. This unreasonable trivialization of the difficulty of writing Web services clouds the issue and makes the problems far more difficult for managers to appreciate.

Really, saying you can write Web services by sticking a function between qualifying statements is like calling a celery stalk a sandwich because you’ve placed it between two slices of bread. It’s the content that makes the sandwich, and not the other way around.

These functions must be designed and implemented from the get-go as stateless entities whose design anticipates and accommodates future changes in such ways that the need for signature modification is greatly minimized. Services are much like reusable objects and components in this sense. And while no one doubts how difficult it is to write reusable classes and components, this same perspective is still not yet applied to Web services.

The challenge is, in fact, greater with Web services due to the coarser level of granularity. Rather than small, atomic functions (compare two strings), whose interface can be worked out in comparative isolation, Web services not only must integrate with the current needs of the SOA, but also must anticipate how things will change. The need to anticipate and preclude change at the signature level must be deeply respected for fear of falling into Web services hell—where there are thousands of services that are all slightly different due to the evolution of the architect’s understanding of business needs.

Debugging is another neglected problem. With monolithic programs, you can step through code, review the calling stack and do all kinds of things to find out why a value is incorrect. In SOA, the error often occurs on a remote system, possibly even a system several hops away from the service interface you’re accessing. Debugging now requires capture of a tremendous amount of state information and visibility into remote systems. And that visibility often entails the participation of developers working on those systems to help track down the problem. Oh, joy!

One company that is addressing some of these issues is Mindreef, developer of the widely admired SOAPscope Web services testing and diagnostic software. Its recently released Coral development platform attacks many of these development issues head-on. It’s definitely worth evaluating for nearly all shops working SOA.

There is an additional problem, though, that Mindreef does not address. How do you know what a Web service does behind that signature? Putting aside the trivial examples, Web services in IT can be segregated into two broad categories: data fetching and transformation and decision services. The latter category refers to services that, for example, accept a mortgage application and return a yes/no decision or other evaluation result.

Often, these services are highly complex and rule-based. The question is, how does the owner of the service know what it does exactly? Likely, he or she can’t know the details without consulting the developer. So then, how is this service properly described in a directory? Moreover, how are updates to the inner workings handled, and how are those changes reflected in directory entries?

What you frequently find behind the signature of a decision service is a black box. Without consideration of how the functionality can be communicated, managers of SOA will soon find themselves managing farms of black boxes. And figuring which service does what and which black box needs to be modified will prove to be a daunting challenge.

In this regard, some vendors of rules-based systems, such as ILOG, are designing ways to provide transparency to decision services, but their efforts can only go so far. Web services in SOA need to be thought through far more carefully than they have been if they are to be at all manageable once implemented.

Andrew Binstock is the principal analyst at Pacific Data Works.


Share this link: http://www.sdtimes.com/link/29215
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading