SOA Simplified

It's come to my attention that a lot of folks have questions about this thing called "Service Oriented Architecture (SOA)". What is it? Why do I care? How does it help me make better software?

The reason I know people have these questions is because I've done a mediocre job of explaining it. I've described it as one of the selling points of the onTap framework, hoping for that "aha!" spark of recognition. Instead it's produced more puzzled remarks of the kind you'd expect from folks who haven't been properly introduced to a concept yet.

I had another look at the overview page of the framework documentation, thanks to some comments Ziggy offered in a previous blog. He was right, that overview page needed a lot of work! In the process of revising it I think I've developed a reasonably effective way of simplifying the need for "service oriented architecture".

I've also coppied this overview content to a new Project Goals page on the wiki. There's more on the goals page, but I wanted to share the SOA explanation here so this will go out on cfbloggers and may be useful to the broader ColdFusion community.

Let me start with the Wikipedia definition:

Service-oriented architecture (SOA) is a method for systems development and integration where functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are often seen as built upon, and evolving from older concepts of distributed computing and modular programming.

This is a serviceable explanation, but it's awfully dry, as you might expect from a wiklopedia. And while you can glean some information from it the mere style of the writing may make it difficult to really grok what all these words mean when you put them together in that particular order. I've heard in the past that when learning something new it's a good idea to have two books on hand - a fact/reference book and a tutorial book. Or in some cases a book that combines both of these aspects. So with Wikipedia as the "reference" part of the equation, here's a more tutorial-esque explanation of what the above means. (Or at least what it means when I talk about SOA.)

Ray Camden created BlogCFC and TJ Downes created Kalendar. These are both good tools and we're grateful to Ray and TJ for making them available.

What if you wanted to have Kalendar integrated into your BlogCFC blog. Why not? You could be writing a blog and want to insert an AJAX widget that shows an RSVP for a particular calendar event. Or maybe the reverse, you want to associate a blog entry with an event in the calendar.

You can do these things now however, YOU have to write the integration code yourself. Plus EVERY change you make to integrate them increases the difficulty of upgrading to later versions of either project!

Why should you have to do that work? Don't you have plenty of your own projects that need your time?

And why should integrating them make it harder to upgrade?!

Why aren't Kalendar and BlogCFC already integrated for you?

I'll take this analogy a little further than the overview doc. You may already be familiar with or technorati.

These kinds of services have been available for a while, but when they first came out you had to manually copy the URL of the blog you're reading, manually open a new browser window, manually navigate to and manually paste your coppied url into their tool.

As the notion of blogging has evolved it's become common for blogging software or services like or LiveJournal to streamline that process for you by integrating links to services like into their blogs. Ray's BlogCFC that runs this blog has links to Technorati and below this entry you're reading right now.

Having those links means not doing that extra work, because the software does the integration work for you.

What a well designed SOA framework like the onTap framework can do for your ColdFusion applications is the same thing. It can eliminate a lot of the work of integrating different applications.

I'm going to give one last example of a service oriented architecture. One you use every day and probably never realized was an SOA.

The web.

What I'd like to point out most specifically about the web is the use of search engines like Yahoo, Lycos and Alta Vista. :P Yeah, yeah, I know... Is Alta Vista even still in business?

But that's actually rather crucial to this point.

Although we generally only use Google now there was a time that there were a wealth of web-searching companies available and in frequent use. All those companies as well as Google relied on and continue to rely on the fact that the web is a service oritented architecture. Because the web is SOA, search providers like Google can discover sites via the prescribed method of service discovery (spidering).

Because these sites are available this way the service provider can provide their services (and here's the key point) independently of the original site. How many site owners do you think knew about Google's new image search on the day of its initial beta release? Probably very few. They didn't need to know. Google didn't need their permission or their help. Google didn't need them to create XML files or databases with lists of the images on their sites.

So there are three parties involved here - there's the search engine service provider (Google), there's the site author and there's the end consumer (us). And what SOA does in this scenario is to eliminate dependencies between these entities, allowing them to discover and utilize each other with minimal prior knowledge. In a traditional software application, Google would be dependent on the actions of the site providers uploading or importing content to them. The SOA nature of the web in this case eliminated that dependency.

So to tie these back together, lets say you've got BlogCFC and Kalendar and you want to integrate these applications. An SOA framework like the onTap framework would allow TJ to create integration for BlogCFC that comes already bundled with Kalendar. But what's even more cool about this SOA is that when you install these two applications (Kalendar and BlogCFC) that integration between them is automatic - the framework does the work for you.

Ben Nadel's Gravatar Isaac, all of these terms are a bit new to me, so I am still a bit confused. Is SOA something that is only applicable when you have two or more apps merging? Or is this something that is helpful if you have just one application that you are building from scratch?
# Posted By Ben Nadel | 9/25/08 1:53 PM
ike's Gravatar Thanks for the comment Ben. Yes the definition of SOA implies that what we're talking about is multiple applications talking to each other. Another term I've seen people using more lately to describe this kind of thing is "mashup". But where a "mashup" involves applications from different domains (which is the bias from which much of the Wikipedia article is written), what I'm talking about with the onTap framework is on the local scale where the services occur within the context of a single framework instance on your server or a cluster of servers you manage.

Within the framework you may have installed services that actually do call apps from external domains. For example you may install a plugin service that connects to the Google Maps API, however from the perspective of your application code you don't necessarily have to know or care that Google is involved. To you it's just a service within the framework. It's the framework that provides methods of discovering what services are available to you.

An example of that kind of discovery built into ColdFusion is the rarely-seen getFunctionList() function that returns a structure with the names of all the native functions available on your server. This way you don't have to know what version of CF you're using, you can just check to see if the server has a "SerializeJSON" function for example and then do your thing if it's available.

And yet another way to look at SOA might be as being like Mach-II's sub/peer applications on steroids. :) The same sub/peer application concepts, but add to that looser coupling and more flexible integration between them.
# Posted By ike | 9/25/08 4:17 PM
Ben Nadel's Gravatar @Ike,

Thanks, that clears things up for me.
# Posted By Ben Nadel | 9/25/08 4:19 PM
ike's Gravatar @Ben - Thank you. :)
# Posted By ike | 9/25/08 4:52 PM
John Whish's Gravatar I've always thought of SOA as communicating via web services. How does onTap support consuming webservices and also direct (local) API calls. If I understand correctly, in your example of BlogCFC and Kalendar you'd either need to write both apps on the onTap framework or build plusings for them to expose the API. Have I got that right?
# Posted By John Whish | 9/26/08 5:24 AM
ike's Gravatar @John - yep the Wikipedia article mentions that as being a common conception of SOA although it's kind of a misnomer. Webservices are just one example of a way in which SOA is achieved when you're talking about SOA across multiple domains or servers. But the concepts of SOA are much more generally applicable in lots of different contexts.

So in my case when I designed the new web service for the plugin manager, I created a pluginstore webservice CFC which I use on the framework site ( :// ). This pluginstore then takes advantage of the IoC Manager (part of the internal SOA structure) to get information about the catalog of available plugins, and wraps that data up in the XML it's going to return. On the other side where you have the framework installed and you navigate to the plugin manager interface it goes back to the same IoC Manager and fetches the plugin agent that consumes that service and translates the result XML for use in that interface.

So you're correct that part of what I'm talking about is having both applications written as plugins. Your plugin becomes available to the other plugins via the IoC Manager and a number of other framework features locally within the application.

But by the same token this also makes integration with external webservices easier because if someone else designs an agent that consumes someone else's webservice API, they can package that up as a plugin for the onTap framework which then brings the power of SOA right into your local app.

So for example lets say hypothetically that both Ray and TJ wanted to integrate the Google Maps API in their plugins for BlogCFC and Kalendar. (This is of course in the hypothetical scenario in which they both pluginized those apps.) Either they could each individually do the google integration (duplicating effort), or someone else like you or me could create a separate Google Maps plugin and then they could just write Kalendar and BlogCFC to detect the Google Maps plugin and use it if it's been installed. If the Google Maps plugin isn't available, then Kalendar/BlogCFC just omit those integration features.

This means a) less duplication of effort for Ray & TJ and b) less work for you when you install those plugins. This empowers plugin authors to better utilize each-other's work. And the likely upshot is that there will be more of that kind of helpful integration in general. :)

Maybe this should have been a follow-up article. :)
# Posted By ike | 9/26/08 2:15 PM
John Whish's Gravatar @Ike, thanks for the reply. To my understanding this is similar to a loosely coupled architecture in OO with a facade, except you are doing it via a web service - is that right? Sorry for being a bit slow to get it!
# Posted By John Whish | 9/30/08 11:01 AM
ike's Gravatar Hey no worries -- new concepts usually take a little getting used to for them to sink in.

Yes at least the example here where I'm using the pluginstore and pluginagent services on either side of my webservice (both publishing and consuming) it is an OO facade system. In this particular system the webservice itself is the smallest part of the system and is really just a communication bridge between local services on either side. The local service on the consuming side is a facade for the webservice, although because it's a facade it also has the potential to consume non-web services. It could get data from an FTP server for example it just happens to be using a web service because that's a convenient transfer medium. To the rest of application however the facade is just a local service irrespective of what powers its data on the back end.

I was actually just preparing to publish another blog that talks a little more in depth about the IoC Manager and why I describe it as being an SOA feature.
# Posted By ike | 9/30/08 2:31 PM
BlogCFC was created by Raymond Camden. This blog is running version 5.5.006. | Protected by Akismet | Blog with WordPress