VB.NET will implement many Java features, in most cases using Java syntax. For example:
"Imports" statement to create references to external objects
Inheritance via "Extends" statement (but only single inheritance AFAIK)
Support for constructors
Ability to "throw" exceptions. Exception handling will now have a Java-like syntax, and client classes can choose which exceptions they will handle, as opposed to VB6's clumsy Err handling.
There are also other major syntax and implementation revisions in VB.NET which make it incompatible with VB6. Nice touch!
Both these solutions use XML as a transport mechanism for RPC. Don't know about the Sun product, but BizTalk (the framework, not The Server(TM)) is essentially a wrapper around SOAP (see W3C standard). SOAP sends in/out parameters in plaintext with a few wrapper XML tags to tell the server what to do with it. The preferred method of SOAP transport is HTTP POSTs.
The difference between these products is how they unwrap the XML to actually make the procedure calls. In any case one could easily write an application to do the unwrapping and call the procedures. BizTalk (The Server(TM)) creates a visual drag-n-drop interface that allows the user to never even learn XML. This is its selling point (at $25K+ -- ouch!)
If you don't mind getting your hands dirty with the XML, there's no reason to bother with these products for small to medium scale projects, since bare SOAP is easily implemented using server side scripting or even CGI.
Slashdot Mirror
Ah, but the real question is whether you are using the 16-bit or 32-bit version!
VB.NET will implement many Java features, in most cases using Java syntax. For example:
There are also other major syntax and implementation revisions in VB.NET which make it incompatible with VB6. Nice touch!
J++ lives, it just has a new name.
Both these solutions use XML as a transport mechanism for RPC. Don't know about the Sun product, but BizTalk (the framework, not The Server(TM)) is essentially a wrapper around SOAP (see W3C standard). SOAP sends in/out parameters in plaintext with a few wrapper XML tags to tell the server what to do with it. The preferred method of SOAP transport is HTTP POSTs.
The difference between these products is how they unwrap the XML to actually make the procedure calls. In any case one could easily write an application to do the unwrapping and call the procedures. BizTalk (The Server(TM)) creates a visual drag-n-drop interface that allows the user to never even learn XML. This is its selling point (at $25K+ -- ouch!)
If you don't mind getting your hands dirty with the XML, there's no reason to bother with these products for small to medium scale projects, since bare SOAP is easily implemented using server side scripting or even CGI.