For some time now, I've always had this vision to do three things:
1. Find a way to emulate the passing of instanced objects via SOAP.
2. Have a reusable mechanism that could dynamically populate an object instance and return an XML document so that it could be recreated the same.
3. Mimmic the same logic on another platform as Unix/Linux so that the two could operate as if they were on the same machine.
The very first attempt at the second part wasn't possible with the first version of Visual Studio. The second version was possible using C#, but not Visual Basic .NET. So a few years ago, I managed to create it. There is a copy of the document in another thread within this particular forum. It works. It's been implemented in a few places.
Once that was done, the next step was to take that XML describing an instanced object, and passing that via SOAP and web services. That was done, and it worked. The issue is that you could only do that a few years back with Microsoft exclusively. It was possible that if someone wrote a like mechanism with Java, it could be targeted to other platforms that support SOAP. However, a nice easily maintained mechanism was in place, and it would allow one primative to be passed that fully described a stateful object over an HTTP boundary. That-was cool. It was also cool that the other end might anticipate one of a few types of objects, and know to dynamically discover the interfaces of those objects, and use those to validate the XML being passed to it. From there, after instantiation, an object could be cloned.
There was no Java person to tinker with what I had done. There was nobody that I could envision wanting to do it for the sheer hell of it. It took some time for me to develop it, but it had more uses than one. There was no ready means to just plop it on something like AS400 and say, "Voila!".
However, in the course of searching for things, the Mono project came into play. What the Mono project is in a nutshell is pick your favorite standardized language, and pick your target platform. That way, the code you use on one platform can be used for another. That sounds cool. What is even more cool is that you can port your code you wrote with Visual Studio on Windows, and port it over to Linux. With some limitations, it works. It works more effectively with C#, so I had the perfect project to try it with.
Mono Developer works well for the most part. It's not quite Visual Studio, but it will compile code that can run on either Windows or Linux. So I had to wonder, is this the missing piece that solves the case of the missing Java person? Could I just port this code to Linux, clone a web service, and finally realize the vision? There was only one way to find out. Test it.
I first tried Mono Developer to see if it in fact worked. It compiled my old C# code with the .NET 3.5 Framework without issue in Windows7 . I created a simple test harness, and that worked as it did before when I wrote it using XP and Vista. I ported it over to Linux. I got a copy of openSuse 11.2 and installed an applicable version of Mono Developer on that. Guess what? It worked. Certain things like config files don't work, but other than that, the test harness worked. I had a desktop client with the same code in Windows running on a Linux system.
So after that, I made sure that this thing could serailize my documents for the next experiment. I wanted to see how well I could write a web service, and run it under Apache or some Linux based web server. I was running XSP2, which to my understanding is a sub system of Apache. Regardless, the trick was to see if I could get a functional web service that I could reference through something like a Windows desktop client.
The first attempt with Mono under Suse wasn't sucessful. The IDE on that doesn't do a very good job at all of making these things work. If you use the Windows version, or Visual Studio, it's another story. The thing is, it won't compile under Suse without taking out certain parts of code. You have to resort to a very minimalist code and know what to strip out under Suse to get it to work. The end result is a little ugly in refernece land, but it works.
So after that and realizing I didn't have to emulate what web services did like I did years ago, I had a working web service. I managed to run my code, and write a test file that was an XML descriptor of an instanced object. With that, I figured I could send that XML out, and have it read on the other end. Meanwhile, this web servic was sitting on a virtual server. I tested it, and sure enough. Out came the very XML I expected just as I had it under IIS in other implementations.
So back to my test harness in Windows land I went. I simply added another button and a web reference to a virtual machine. I used Sun's Virtual Box, and I opened up the firewall for my web service. I was able to obtain a reference to it from Visual Studio under Windows 7. I compiled it. I ran it. I was hoping that the XML coming in would be recognized, and be able to be passed into my simple stateful object. From there, I should be able to populate the presentation tier from that stateful object. That object gets it's data from a clone of an XML document passed over SOAP from a Suse server.
I clicked the button. I saw nothing happen. I clicked again. Nothing! The next thing I know, things suddenly populated. I rest the project and tried to debug it. There were no errors. I tried again thinking that perhaps there was some lag. Sure enough, that was the issue. When you first run the thing, there can be a considerable lag. I went to my Suse directory and altered the XML file. I figured that would guarentee that there was no reuse of code that should have been destroyed explicitly.
Well sure enough, it took. It took faster while I had things running and eliminated the lag. Whatever changed in the XML is what changed in the UI for my Windows 7 desktop client. So now instead of passing multiple primative arguments across SOAP boundaries, I can pass one. I can take that on arugment and use it to populate an object with very little code. The mechanism is reusable. That mechanism emulates passing an object instance across the web.
What's even more cool is this. I now have realized the vision of taking a representation of a stateful object in a single paramater, and consistently making a clone of it on another platform. In the process, when things change, you just change your stateful object and not the interfaces of the endpoints.
So what does this mean in a nutshell? It's simple.
Suppose company A lives in LA, and they run Windows. Then we have company B in London running Linux. Company A needs to talk to company B. That's doable through networking protocols.
Company A needs to integrate their software with company B. SOAP allows them to do that. The thing is, if some piece of information such as a credit card transaction has 10 pieces of information to it, that's 10 arguments that need to be passed. In 6 months, we have 12, and in some cases more or less. So things can get really ugly on either side. Things could break, and things live on opposite sides of the pond.
Now, company A can pass 1 argument in code to company B, and vice versa. If things change, they can leverage the benefits of OOP without breaking the interfaces on either end. If there are other stateful objects nested within that first stateful object, there is support for that too. It can all be recreated on either end. So it's then as if a Windows server could work with a Linux server as if they were on the same machine.
So what if something changes on either end? Fine. Add another property to your stateful object. Recompile it. Push the latest version to production after testing, and that's it. There is no need to break the interfaces on either endpoint. As such, you can have all the benefits from a more traditional OOP type of environment, and the same impact as if you architected and implemented things correctly.
So now that DCOM as we once knew it to be is dead, SOAP has taken it's place. However, the emulation of passing an object over a network boundary or an HTTP boundary is not just possible. It's possible to effectively pass objects of like kind to different platforms relatively seamlessly. In the case of the example above, someone in London enters certain information that lives in Linux. The same middleware is targeted on a Suse platform in London as it is on Windows in LA. Someone in LA can use either the web or a desktop client to interface readily with a business tier in London quite seamlessly.
The vision has finally emerged as a sproutling of reality. The operating system is now becoming less of an issue, and existing resources could be leveraged a lot more effectively without necessarily having to scrap what's there. The two can now be as one-and more simplistically.