Transact XML – Abstract Platform
Abstractions allow software to handle multiple specific tasks in a common way. For example: Getting data from an Oracle database is one specific task and getting data from a DB2 database is another specific task. A “Data Retrieval Abstraction” is developed so that the software works the same for any specific task. A publicly published abstraction is a blueprint for other programmers to extend the software to handle specific tasks of any kind providing a flexible and extendable application platform.
Two kinds of abstractions – software and binary
Software abstractions are the most common; some programmers refer to them as a ‘base class’, or ‘template’, or simply an ‘abstract design’. All programming languages support software abstractions to one degree or another. They define how architecture should be extended for future use – while maximizing reuse. Software abstractions deliver on ‘extendable architecture’, and well defined ‘blueprints’, but they are not easily extended by outside sources because “for each specific implementation of a software abstraction the software product must be rebuilt” and “the application source code is required to make the enhancement“. Generally the software gets a bigger version number, and another bullet point is added to a list of features. This is an excellent design for “in-house” software development projects, or public source projects.
Binary abstractions sometimes called ‘Drivers’ are even more powerful. They also provide the ‘extendable architecture’ and well-defined ‘blueprints’, but they do not require any changes to the software product as new implementations are introduced. Binary abstractions allow one company to easily extend another companies software. ODBC drivers are an example of binary abstraction to data access. This creates an opportunity for software vendors to implement drivers. They do not need the platform source code – only the published interface to build a new driver. They own the drivers and can resell them independently. It also provides an option for pre-existing proprietary information systems to develop a custom driver, and plug-into new technology systems.
TransactXML Server uses Binary Abstractions to achieve ultimate extendibility through applied software engineering.
The following diagram depicts the TransactXML server with emphasis on the abstraction layers:
This diagram depicts the abstraction implementations in black, with “in-progress/planned” implementations in red. The image is a bit outdated as Perl and a few other Language Drivers have been created, as well as more Data Drivers, and other transport mechanisms. While the abstraction does not cause Transact XML to support every technology used by the business world, it provides the foundation architecture to get there.
A design paradigm
Open Architecture is a concept than can be achieved at every layer in software development. TransactXML Server is a central building block in an XML based application. Open Architecture B2B implementations use abstractions at every other layer also, for example: When selecting a “message queue”, the abstraction allows for implementation choices, (MSMQ, MQSeries etc.) This affords vendor technology freedom, and the ability to build an implementation with mix and match best fit components.
© 2015 United Business Technologies, Inc. All Rights Reserved.