This is supposed to be huge in 2007. Are any of you using SOA yet?

For those that don't know:



To me, SOA seems like a good idea. But I'm interested in real world implementations and hearing what you've done or seen done with SOA.

The big problem/limitation on what you can do with them is the insane amount of overhead that they have. Like SOAP for example runs on top of HTTP which runs on top of TCP/IP etc etc. So for getting the "accessed without knowledge of their underlying platform implementation." you need higher level protocols to run on, more abstraction means less performace.

However for some applications that is OK, some it is not. You really need to look at what your project requirements are, always.

I've messed with this a little bit, but the project is only 1/2 working. A package managment system using XML-RPC. I have the system taking to a PHP web app, and a python CLI client. However in my experience with it, its good for pulling data from the service, other that feeding data to it, and having it perform a large operation.

I used a download service once that my company paid for. The client (our side, another server actually) just logs into the server and downloads a list of file names. The client then downloads all the XML files from another URL. It then parses the XML files for required data and pushes the data from the files into a flat file in a MySQL database. The last thing the tool does is to acknowledge to the server each file that is received. The server then deletes the files. This tool was built using Java and XML tools - mainly XPATH.

It is really a glue or interface tool. The server is responsible to continually produce xml files and delete them after they have been downloaded. The client tool is responsible to run as a cron job on another server running every hour, or half hour, parsing xml files, placing them in the database, and then telling the server they have been received.

Finally, another program periodically takes records from the flat file in the database, parses them and places the data into the main program's database for production use. The main part of the program that parses and places the data is very large and expensive, in every sense of the word. It is all written in Java, because Java is a very large and scalable language with a lot of tools and libraries already built.

We did this also by setting up an email server and having the tool grab email messages using the POP3 protocol. The email version was rather clunky and was probably phased out.

I think the most important thing that got the ball rolling, with this, was to get all the people and servers communicating. And most important on my end was to get my program to grab the data and display it on the screen in different stages. It was very easy to get the data to go where I wanted it to, once I could see it.

I've met it twice:
I attended a SUN course about it, and it seemed something really interesting, but it was obvious, that it is really a big gun, and sould not be used without a good reason (I am really waiting for a Bitter SOA book).
Then I had to choose between two jobs, one would have been taking part in designing and implementing the first SOA system for a telco here, the other was a J2EE system for the banking sector. It was a hard decision, but I went with the second...

I have personally done quite a bit with SOA, personally I love the stuff, but before I go further here are the areas I have found SOA to be lacking...

• real time systems
• music
• video
• encrypted data
• compressed data

Real time systems tend to have strict performance bottle necks. While I believe it can be made to work, I think the cost to make it to work with real time systems is more expensive than simply doing each integration individually (cost of increased bandwidth and server space).

The problem with music, video, encrypted data, and compressed data is SOA works well with metadata but not so well with data that is better represented as a matrix or a vector. The best litmus test to see if it should be added to this category is: would the xml version of the data look like a bunch of numbers? Or would it have meaningful text. If the answer is a bunch of numbers, SOA is proably not the right solution.

Now that being said. Where I love SOA is with product integration. Personally given two perfectly equal products, one supports an xml (with a schema) stream of some kind (doesn't have to be SOAP over http can be for example straight xml over tcp) and the other is only binary data; I would take the first one hands down. Integration of xml streams is so much easier than integration of binary streams.

The biggest problem with binary data, is the lack of metadata. While xml data is verbose enough, with a little domain knowledge I can generally figure out what it is doing. Also there are enough standards (for example xquery, xslt)out there, that with xml data I can split and recombine xml data into a new compiled document from seperate services which may no nothing as each... kind of like a distrubited dynamic database where any program can represent a set of tables, and their information can be accessed and manipulated at will.

Salindor

You've pointed out a good point. There are many critics of XML and why XML is terrible at this and at that. This is one place where it really shines.