ACMQueue ACM ACM: Association for Computing Machinery
Fri, Sep 19, 2008
Columns: Curmudgeon Geek@Home Interviews Kode Vicious Opinion | Conference Calendar Issue Index Site Map Videos |




Springer Print + eReference
Poll
Apart from your colleagues, what is your primary source of technology trend analysis?

Television
Radio
Newspapers
Magazines (commercial)
Journals (academic)
Web sites - commercial
Web sites - government
Web sites - academic
Web sites - personal blogs



Results
Polls

Votes: 416
Comments: 0

What's New
on ACM Queue
·A Conversation with Steve Bourne, Eric Allman, and Bryan Cantrill
·The Five-minute Rule: 20 Years Later and How Flash Memory Changes the Rules
·Enterprise SSDs
·Flash Storage Today
·A Tribute to Jim Gray
go to issue index
Most Popular Articles
1Scalable Parallel Programming with CUDA
2Data-Parallel Computing
3GPUs: A Closer Look
4A Conversation with Jason Hoffman
5Network Virtualization
 more

Services-Oriented Architecture -> Opinion -> File Systems and Storage issue

From Here to There, The SOA Way

by Terry Coatta, Vitrium Systems
  printer-friendly format
  recommend to a colleague

SOA is no more a silver bullet than the approaches which preceded it.

Queue Digital Edition
The digital edition of the January/February issue of Queue is now online.
View and download here

DOA with SOA
Adoption of SOA did not constitute authorization for Marty to ignore best practices.
ASPs: The Integration Challenge
Tips for integrating with application service providers using Web services.
A Conversation with Leo Chang of Clickshift
In the world of component software, simplicity, not standards, might be the key.

Things I Learned in School
As we continue to develop the new UI for our product, we'll definitely be using FSMs wherever possible.
Only Code Has Value?
Even the best-written code can't reveal why it's doing what it's doing.
Ground Control to Architect Tom...
Are you diverting the technical efforts of your program from following a realistic and value-added trajectory?
more Opinion

Back in ancient times, say, around the mid '80s when I was a grad student, distributed systems research was in its heyday. Systems like Trellis/Owl and Eden/Emerald were exploring issues in object-oriented language design, persistence, and distributed computing. One of the big themes to come out of that time period was location transparency—the idea that the way that you access an object should be independent of where it is located. That is, it shouldn't matter whether an object is in the same process, on the same machine in a different process, or on another machine altogether. Syntactically, the way that I interact with that object is the same; I'm just invoking a method on the object.

Now the people who were building those systems realized that there were inherent differences in performance associated the different locations at which an object could reside. There were a number of ways that one could address this problem. The simplest tactic was to assume that, despite the syntactic advantages of location transparency, the software developer would have to understand where objects were located and code accordingly. For example, if an object was known to be remote, the developer wouldn't execute a series of fine-grain invocations against it. Needless to say, there was something vaguely unsatisfying about this. The more satisfying, and unfortunately more complex, route was to create a caching infrastructure that would mask latency concerns. For example, the first time that a method was invoked on a remote object, the system would actually transfer some or all of the state of that object to the local system. Subsequent invocations on that object could then potentially be served very quickly from that cached data. Had this caching problem been easy to solve, we'd probably be using systems like that today. Alas, it is not an easy problem, due to issues such as cache invalidation, partial failures, etc.

Fast forward a little to the late '80s and early '90s and we have the first commercial distributed object systems being developed. The big two were CORBA and DCOM. Both of these were heavily influenced by the distributed systems research of the time, and so it comes as no surprise that both provided location transparency for accessing objects. Neither, however, provided an out of the box solution to the caching problem that addressed the latency issues inherent in distributed computing. The result was, at least in hindsight, predictable. Given tool kits that provided location transparency, programmers frequently built systems in which they carried out fine grain object access without much regard to where objects were located. Naturally, such systems failed to perform particularly well, and fine-grain access to distributed objects was tarnished forever.

That brings us to services. Objects are still a very good way to model systems and they function reasonably efficiently in the local context. But they don't distribute well, particularly if one tries to use them in a naive way. A service-oriented architecture solves this problem by dealing with the latency issues up front. It does this by looking at the patterns of data access in a system and designing the service-layer interfaces to aggregate data in such a way as to optimize bandwidth, usage, and latency.

To be more concrete, suppose I've got a system that manipulates Questionnaire objects. Each of these Questionnaire objects contains a number of Question objects and those, in turn, contain a set of Response objects that represent responses collected from users. Now if someone is building an application to manipulate these questionnaires, you can be fairly certain that at some point they will want to display the set of questions in a particular questionnaire. So, in building the service layer for this system, I would create an operation that returned all of the questions from a particular questionnaire, and also some or possibly all of the properties of those question objects. Thus, in building the application, the developer would be able to display all of the questions in a particular questionnaire by making just one service call. Using a fine-grain object system, on the other hand, would have incurred a latency penalty for each access to each property of each object displayed.

I've seen a lot of claims that there is something fundamentally new about service-oriented architectures. I don't buy it. Distributed computing has always been about the same set of problems. The speed of light is fixed, bandwidth is finite, and networks can be relied on to fail periodically. What we discovered in the 80's and 90's is that it's hard to build a completely general-purpose system that deals with these issues. Service oriented architecture is all about solving these problems in the context of a specific set of domain objects and business needs; that is, defining restrictions which make a viable solution easier to create. But SOA is no more a silver bullet than the approaches which preceded it, and the fundamental techniques and strategies used for the previous generations of distributed systems are the foundation of a well-designed SOA.

ACM Queue vol. 5, no. 6 - September / October 2007
by Terry Coatta, Vitrium Systems

TERRY COATTA is a member of the ACM Queue editorial advisory board. He is product manager at Vitrium Systems Inc., which produces software for tracking and controlling access to PDF documents. Past positions include vice president of development at Silicon Chalk, which created realtime collaborative software for use in higher education, and director of development for distributed systems at Open Text Corporation. He has a Ph.D. in computer science from the University of British Columbia

Submit this story to one of the following blogs:
Slashdot   del.icio.usdiggtechnoratiblinklistfurlreddit

Related Stories
The Next Big Thing
- This month Kode Vicious considers the future of functional programming and then offers up his top five protocol-design tips.
Kode Vicious

Only Code Has Value?
- Even the best-written code can't reveal why it's doing what it's doing.
Terry Coatta, Vitrium Systems

DOA with SOA
- Adoption of SOA did not constitute authorization for Marty to ignore best practices.
Alex Bell, The Boeing Company

Discuss From Here to There, The SOA Way
 
Latest Comments
 
What do you mean by building an application... - The use of coarse grained services to mediate between the user interface and the business logic of a...
 
Coatta's SOA article... - Those who are ignorant of history are condemned to repeat it. (Santayana, paraphrase) Perhaps as ...
Post your comment now!
name:
email:
subject:
comment:
note: only <b>, <i>, and <br> tags allowed
Please type in the captcha number below
 

Free QueueNews Email Newsletter
QueueNews is a weekly newsletter featuring a listing and excerpts of the latest articles to appear on Queue's Web site.
Subscribing is quick and easy! Just fill out the form below.
- HTML version
- plaintext version
Please type in the captcha number:
 
privacy policy

ACM


ACM Home
About Queue Advertise with Queue Advisory Board Back Issues Contact Us Dev Tools Roadmap Free Subscription Privacy Policy RSS feeds
© 2008 ACM, Inc. All rights reserved.