| 10:02 pm on Apr 7, 2002 (gmt 0)|
I apologize for replying to my post but in reading some of the other threads I learned about another technology that I hadn't heard of yet.
I am guessing this is the next wave of setting standards. I am presuming that we have declared a winner in the browser wars and are moving onto the object distribution wars next?
| 2:11 am on Apr 8, 2002 (gmt 0)|
I think that question might be more fairly asked about C#.
Java was developed by Sun as an needed improvement on the existing C++ of its day. C# is a more modern improvement of C++.
.NET is about web services. Web Services are a very general model for building applications and can be implemented for any operation system that supports communication over the Internet.
There are at least two working .Net Framework implementations for Unix and Linux Operating Systems as well as Microsoft's Windows Implementation. Both SOAP and XML are important to the implementation of a Web Service.
SOAP implementation exist for Apache and several Java Web Servers. XML is becoming available almost univerally.
Both Sun and IBM are developing Web Services.
| 4:05 am on Apr 8, 2002 (gmt 0)|
I'm not an expert in this by any means. But here is what I know about web services so far:
SOAP:[/] Simple Object Access Protocol allows for the transfer of files in XML across the HTTP (web) protocols in a standard format.
[b]Web Service[\b] A small application available over the HTTP protocol which can run behind the scenes.
Think of an applet or EJB that can run remotely without human intervention - an applet resides on your server and needs fixed parameters. A "web service" would reside who knows where, and you would call that service from your app, send the necessary parameters and get a response which you would use on your web page.
[b]WSDLWeb Service Description Language - a description of the service and where to find it. things like parameters, etc.
UDDI A repository for descriptions of web services. Almost like a private search engine devoted to these applications.
To learn more, check out www.silverstream.com and IBM's site regarding websphere.
It's complicated, but it's beginning to make sense to me - slowly.
| 4:57 am on Apr 8, 2002 (gmt 0)|
Your description has just turned on a light bulb. Now I just need to see if the light is really bright enough?
So if I understand correctly how this could work allowing the hype to be real.
1) .NET, SOAP, etc... are wrapper objects or maybe what I am sure MS would like is another layer on the OSI model.
2) The compiling of the object takes binary code and puts it in the proprietary interpreted code for transport to whatever destination.
3) The recieving end grabs the object and takes off the wrapping and interprets/deals with the object.
I did something very similar to this. I wrote a library in Java that allowed any class to encapsulate itself within the wrapper class and be passed to the server for execution. Since the only thing the server seen was the wrapper class and the size it didn't matter what was in the wrapper until the recieving module unwrapped it. We used this method to pass both data and code from the client to the server. It made for very clean looking code once you get past having to explain the details of the library.
If I am off the mark than let me know. I think I got a good handle of the basic concept. Now on to reading. Thanks for the link.
| 12:14 pm on Apr 8, 2002 (gmt 0)|
|2) The compiling of the object takes binary code and puts it in the proprietary interpreted code for transport to whatever destination. |
It sounds right to me, except for this part. I think the plan is to not have proprietary code, much in the same way HTML is non-proprietary. The wrapper is right, and the transport is write, but the underlying document is non-proprietary so all web app servers can read it.
| 12:24 pm on Apr 8, 2002 (gmt 0)|
So from your reading, have you heard that this standard spans the different technologies as well as the different languages?
.NET can talk to SOAP or am I lumping too many things together?
| 12:57 pm on Apr 8, 2002 (gmt 0)|
SOAP is completely independent of the programming language or system environment you're using. It works on top of HTTP, defining the way how the CGI backend processes and generates XML data. If you're interested in SOAP, you might also want to look at XML-RPC, which has similar (though less ambitious) intentions, and appears to be simpler to use.