VB400,
It'll work for your environment. From the book VB6 XML from Wrox, pg 14.
There is nothing in the XML specification that favors one platform over another. XML is pure text, which make it a platform neutral data format. Just to be clear on this, the specification states that allowable characters are tab, carriage return, line feed and the legal graphic characters of Unicode and ISO/IEC 10646. This simplicity is essential when trying to exchange data between any two arbitrary systems. It has tremendous value even when all of your applications are on the same platform.
Another part of the book that more closely talks about what you're asking about goes as follows. pg 16.
A large software company has different applications in various languages, that run on different platforms. Some are in C, VB, Java, etc... As they continue development, they begin to see that some desired features already exist in some form or another in an existing program. To fully make use of their investment, they decide to make the existing functionality openly available by exposing XML interfaces (meaning that the public methods take XML strings as parameters, and return XML string as the response). So they modify the existing applications to allow transactions via socket requests. An application could listen on a given port, waiting for a connection, and when one comes in, XML could be passed in, the request handled, and XML sent back out. New applications could now request services from any of the existing applications, regardless of the platform.
I wanted to use the verbiage that Wrox had in their book because they explained it to a tee! This is basically the environment that I created for the application that we redesigned. Here was the setup:
Windows NT Server running SQL Server. On the same machine was a custom DLL written in C++ that used with the Microsoft XML parser also known as the DOM (Document Object Model). The DLL made a connection to a SQL Server database when it was initialized and then waited for a transaction. Since this was a DLL, there had to be an application to launch the DLL. I wrote the server side in Visual BASIC and added a reference to the C++ DLL in the server side application. I refer to the Server part I wrote as a BROKER. All it did was open a Service Port on the server and waited for a client to connect to it via a socket. When a connection came in, it was accepted by the VB application. When data came in on the socket, the XML was passed from the VB application to a method in the C++ DLL. The C++ DLL had all the logic in it to deal with the requests. This was done for speed. Once the DLL was done with processing the request, it spit back a string (an XML string) that was just passed back to the client application. When the client received the XML data, it disconnected from server. So the VB Application that ran server side was only passing data back and fourth and had no logic in it what-so-ever.
The VB application that ran server side would make only one connection to SQL Server (thus saving on SQL Server licenses), but the intent was to charge for connections to our server (VB Server).
There was also a client side DLL that was written in Visual BASIC. I wrapped all the DOM calls and XML calls into the DLL so it was totally transparent to the user of the COM object. Basically all you had to do to program the client side DLL was set a reference to it and call a method. The DLL took care of all the connecting, disconnecting and parsing of the XML. In fact if I hadn't told you it was XML based, you would never know it.
In short, a socket is like a pipe that you open up between two machines that allows bi-directional communications over a network using TCP/IP for the protocol. You run the VB server application, it instantiates a C++ DLL and makes a connection to SQL Server. At that point the server is waiting for a connection.
You run the client application and the user does something that calls the client side DLL. Properties are set on the object and then a method is called. Inside the client DLL, the properties of the COM object are picked off and placed into the DOM. The DOM then creates and XML string with Elements and Tags in it. Then the client application makes a connection to the server, passes the XML string up the socket and waits for a response.
The VB server receives the response, takes the XML string and passes it to a method of the C++ DLL and it waits for a response. The VB server then takes the XML string from the C++ DLL and passes it back down the socket to the client.
The client receives the XML string from the server and loads it into the DOM for parsing. The values are pulled off the DOM and placed into properties of the object on the client side. Then the client issues a socket disconnect.
At that point it's ready for another transaction. This may seem like a lot, and it is, but on 95% of the transactions you'd never know the request went across the network and back.
The nice thing about this approach is that if you publish your XML routines and how to use them you could write applications that run on any platform, in any language. The socket part is nice because you can run the server anywhere in the world. Or the client as a matter of fact.
We had a guy on site that was having a problem with the client application. He called me up and I asked him for the IP. He gave it to me. I hooked the server 4 states away, right from my desktop. I was able to debug the application in the VB IDE and be connected to the data on a server 4 states away. Talk about an awesome development environment for debugging! That was sweet. I found the problem, and in 5 minutes I had e-mailed a new EXE to him. As with so many applications, it was a problem with data.
So there’s the long version of how XML was used in an application. There is an XML forum here that’s really good. A lot of it is over my head, but that’d be the place to ask questions.
Hope that helps. Snaggs
tribesaddict@swbell.net
Enter any 11-digit prime number to continue...
