<main>

Welcome to XOT

XML Object Transport (XOT) is the latest development in distributed object models. It finds its birth in the frustration over today’s models for using distributed objects. Without going into a lengthy history of distributed object models, I want to outline what some of these frustrations are.

Procedural in nature

A fundamental difference between procedural code (such as COBOL) and object oriented languages, is the combination of data and behaviour. In a procedural language, I define my data structures and define the operations of the system. The operations take a data structure as a parameter and work with the data provided. In OO, I define the classes of objects in my system, thier behaviours and the attributes which affect those behaviours. I tie all of these together in a class and at runtime create instances of that class, called objects. Each instance has it's own state, independant of the other objects of the same class (i.e. two "People" (class) in the system can have different "First Names" (attribute or state)). When I execute one of the available actions of the class, it runs in accordance to the attributes of the object I invoked the action on. Basically, this can be boiled down to: In procedural code, I call runPerson(myPersonStruct) and in OO I call myPerson.run().
The benefits of doing things this way have been enumerated many, many times, so I won't go into them here. However, my point is that in today’s distributed object models, we have reverted to procedural code. In EJBs, best practices say to use Stateless Session Beans (Function Libraries) to retrieve Entity Beans (Data Structures). In SOAP, I call a remote web service defined by WSDL and get back dumb data again. This limitation really influences a designers ability to adequately design a good, maintainable code base of distributed objects.

Feature Loss

In many distributed systems, we have lost key features of object oriented programming (inheritance and encapsulation come to mind) in order to accomodate the need to integrate to legacy systems. While this need is a valid one, I would like to XOT to grow independant of integration to legacy systems and focus on building new, independant ones. I realize that this will affect the adoption of XOT in the enterprise, I think that this is an important step to take.

Ease of Use

Despite marketing hype, none of the feature rich distributed architectures are easy to use and implement. SOAP today is an exception, but SOAP is missing many services of the other models. As these services are added, SOAP stands a good chance of becoming as cumbersome as the others.

</main>