User Login

Help Community Login:

The work around for the absence of OOP and SOAP-and cross platform at that!

3 replies [Last post]
Uncle Freakin Joe's picture
Uncle Freakin Joe
Premium Member (Silver)I'm a Code Monkey!I use Internet ExplorerWindows User
Joined: 07/04/2009
Posts: 53
Drops: 95

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.

I Averaged: 0 | 0 votes

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
SloPoke's picture
Premium Member (Gold)I use FirefoxI use Internet ExplorerWindows UserI donated more than $20+ to GeekDrop!I donated to GeekDrop simply because I love it!The Dr. put the stem on the apple!STaRDoGG <3's you ;)
Relationship Status:
Joined: 08/30/2009
Posts: 140
Drops: 205
Mood: Tired
Re: The work around for the absence of OOP and SOAP-and ...

I got lost about 3 sentences in Laughing what is SOAP?

Smartmom's picture
Wellington Florida
Banned Member (Way To Go!)
Relationship Status:
Joined: 01/15/2009
Posts: 6392
Drops: -21
Mood: Giggly
Re: The work around for the absence of OOP and SOAP-and ...
SloPoke wrote:

what is SOAP?

Its that stuff you use in the shower Tongue
I dunno I was lost after the first few sentances. STaRDoGG is a programer as some of our other members here so I'm sure they understand it but me - clueless. I wish I knew C++ but I don't Sad

STaRDoGG's picture
Head Mucky MuckJoined the Dark SidePremium Member (Gold)I'm a Code Monkey!The Steel CurtainI use FirefoxI use Google ChromeI use Internet ExplorerI use SafariLinux UserMac UserWindows UserI donated to GeekDrop simply because I love it!Booga Booga BoogaI took a bite of the AppleFormer Phrozen Crew MemberI'm MagicMember of VileThe Dr. put the stem on the apple!The JokerSomeone thinks you're udderly delightful!
Relationship Status:
Single & Not Looking
Joined: 01/14/2009
Posts: 2604
Drops: 3076
Mood: Energetic
Re: The work around for the absence of OOP and SOAP-and ...
SloPoke wrote:

what is SOAP?

Lesse if I can explain this in a sort of Layman's way Smile

SOAP stands for Simple Object Access Protocol, and OOP stands for Object Oriented Programming.

These days most programming languages use "objects". An object is anything that has a bunch of "properties". Just like if you look at your coffee cup, a property of it might be that it's color is white, another property might be that it's 5 inches tall, another property might be that it's half full, etc., all of these "properties" make up the "object" of a coffee cup.

So in programming terms, a Button you click in a window might have the properties, height, width, color, and what the label on it says.

SOAP is used in web services to transfer info like that back and forth in XML format, which can contain the information about those objects, and be used to populate the properties of the objects.

Never play leapfrog with a unicorn

Who's New

Redneck's picture
juanpabarri's picture
henta2002's picture
Vanillachinchilla's picture
versioniii's picture
xgensolutions's picture
OkwuteAgu's picture
CB_Latin's picture
GrimRapper's picture
glrobins's picture
hady's picture
Jessica Davis's picture
CRowmAN's picture
redd993's picture
Austeen Legitt's picture
facebook codes exploits tips tricks Phrozen Crew
All contents ©Copyright GeekDrop™ 2009-2020
TOS | Privacy Policy