I actually have this in an MS Word document.

Here is the reason I wrote this to begin with, and then I realized the potential this had that I didn't at the time.

I know Sun has their agreements in place to support SOAP. I don't care for anything non-MS related. However, there is this ugly thing called reality. The entire world isn't going to just flip a switch to MS stuff. However, they need to work together, and SOAP is a great starting point for that.

So....I figured, it would be nice if there was a way to use OOP and SOAP. Well, any idiot (well almost anyone that is with some know how) can describe any object instance and it's data in a string like an XML document. The thing is, when you get past the end point, you have a load of extra work.

So....I figured, there has to be a way to pass an XML document as a string such that at the other side of the endpoint of a web service, some framework can say, this document describes this particular object. So let's create an instance, and we know from what's here there are n possibilities. Let's validate this schema against what interfaces are in the current assembly on the fly, and if it washes, cool. Let's populate it with an overloaded construct that accepts this XML document, and then everything is object oriented.

The other thing I thought about was in the event that you have a serviced component and you're limited to a strict type or primative, I remember a senior developer who said put in an XML string. Then you can just do what you need to before you start the actual transaction. So that thinking is what inspired me years ago.

The technology to support it wasn't there till VS 2005 came out, and C# was the only thing that would support dynamic interface discovery that I needed to pull this off to validate it against the XML document coming in. So that's how it started, and I added to it.

So my vision was this. Assume we have some IBM (cough) dinosaur running some SOAP endpoint. I have my MS stuff here. I can take care of the maintenance part on the MS side of the endpoint. If you could have some java thing to do the same thing on the other end, you could basically say, here is an object. Convert it to an XML document that's formated and well described so that the other side can parse it, validate it, and accept it as if it were all part of one system.

The first time I ever used it for a web application like that was for an n-tiered application for my final project. For each tier, I implemented a SOAP endpoint. So if I had one thing in Honk Kong, another in LA, and something else in who knows where, I could integrate them all and essentially pass objects across the globe as metadata. On the other side of the endpoint, the entire thing is dynamic as if everything was traditional OOP.

Long story short, on my laptop, running SQL and everything else on a single machine, I benchmarked 1800 messages a minute across a single domain (support for many) with an MTA service running and interacting with SQL to archive the mail messages across 10 test accounts. I used this API to do the conversion so that the maintenance time would be nothing.

I tried to send the document to various people. That, and $4 will get you a cup of coffee at Starbucks. On some bigger stuff, you could save some serious engineering resources up front and in the long term by integrating different platforms with this sort of thinking.

However, that just doesn't seem to phase anyone at all for some reason when I put it all strictly in writing. (((shrugs)))

-joe