Download this document as a PDF from here.
“Any” data source means that by the nature of the design “Any” data source can be supported without making “Any” change to TransactXML server. This is accomplished with the Data Abstraction. “Any” output is accomplished with DesignerXSL. Small and Fast are accomplished by using the best algorithms available and by designing new algorithms when needed and by fully understanding Distributed System Design.
Currently all the major databases are supported, but data sources include non-DBMS sources as well, such as one client who has asked if we can make a driver for a hardware interface as a data source – YES – Any source capable of producing data can plug into the functionality of TransactXML without making any special changes to TransactXML to handle the new data source.
“Any” platform means that the source code has been carefully built on a very portable subset of C++. Consider that the Java kernel (aka the JVM or Java Virtual Machine) was written in C++, and the Perl processor was written in C. By using a very standard subset we have ported this software far beyond the 3 initial targets of Linux, Windows, and Solaris that were complete in the year 2000. In 2015 “Any” mobile platform is supported with implementations already complete for (Windows Mobile, Windows Phone, iPhone/iOS, Android)
TransactXML is a type of 4GL language in itself, however because integration is a key purpose – Transact XML makes NATIVE calls into Java, VB, Perl, Python, C++. Preexisting systems written in Java will plug into TransactXML just like every part of it was a Java Application, and the same is true for COM and CORBA. TransactXML provides 100% NATIVE support.
One of the most elegant and seamless features of this XML Document rendering system is how the diversity of data sources work together like they were designed to. Consider the following example that joins Oracle and SQL Server without using slow logical views configured in the DBMS.
Because TransactXML uses native access to data on various platforms and converts the results to standard XML, joining diverse data sources is very easy. It is not necessary to import a foreign a DBMS or “Attach” it underneath another DBMS simply include one rule script within another. This is not “concept technology” or “vapor ware”. UBT presented the first working model of what we call “Grafting” at www.DISA.org in the year 2000. It is stable, refined, and ready to be the foundation that will support a componentized application design that takes distributed objects to a whole new level. An outline of the XML Document Rendering Process is documented here.
The transport of the request for an XML document and the results, the XML, are independent of the transport protocol. Therefore we could use FTP, IIOP, RPC, or whatever preexisting protocol is a best fit solution. UBT has also engineered an advanced proprietary protocol called Xfer that can do more than any of the preexisting protocols.
Bridges normally work at OSI model layer 2, and are unaware of protocol. They just forward data from one network to another. UBT has built a protocol with network bridging built into the protocol, so this is a protocol that can truly go where NO OTHER PROTOCOL can.
Tunneling is the act of packaging one protocol inside another, this same protocol also tunnels through HTTP. The concept of tunneling has never previously been applied as a feature of a protocol, rather it stood as a networking configuration on its own such at Tunneling Transmission Control Protocol that was designed to pass DCOM through firewalls and causes a significant amount of runtime configuration to be properly employed in an application. Other attempts at tunneling have employed an even more invasive requirement of replacing the entire firewall. This is how Visigenic’s Gatekeeper and Orbix WonderWall proposed to pass CORBA’s IIOP through the firewall. It should be noted that NEITHER of the aforementioned solutions addressed how object data could cross networks that need to be bridged.
By building this into a protocol, documents, transactions, and distributed objects can reach deep into corporate networks – around firewalls, through firewalls, and across platforms WITHOUT REQURING ANY SPECIAL NETWORK CONFIGURATION, without requiring special hardware, and without requiring special ports to be opened.
In addition to routing and tunneling, this same protocol supports a unique concept never before used in any protocol, that is: When one computer cannot physically reach another (suppose an NAT router is in the way) but each computer can reach a common machine (a domain server on a LAN or a server on the internet) then the connections can be joined at that server, called “the switchboard”. It’s a revolutionary concept and breakthrough in connectivity options. This too is also contained within the same protocol. This is a real time connection junction server, not a store and forward scheme. The switchboard never queue’s data or writes it to disk, it serves as connectivity junction similar to an instant messaging hub. It has been tested as way to make Telnet connections that were otherwise not possible, and move common protocols like POP3, SMTP, and VNC through networking environments that they could not enter naturally.
Because all 3 connectivity schemes are within the same protocol, they can be used in combination with each other. For example a connection may meet at a switchboard, then tunnel through HTTP, then bridge into a corporate subnet via Xfer.
This is a very significant achievement and essential to a complete end-to-end integration solution. The implementation is non-trivial, but the usage is and it requires very little or no runtime configuration for an application integration.
Once again, this is not vapor-ware, the first implementation of Xfer was created in 2002. It has been refined, debugged, tuned for scalability, and it stands as a production ready tool in a class of its own.