Introduction
We estimate the savings made by our company using XPL to be in the USD $10 million per year figure; we have greatly reduced the costs of debugging our programs and, very importantly, when new members join our team, the time they take to understand the software before they can start contributing has been greatly reduced. – Bob Poppino, CEO of BPSystems.
Welcome to XPL, the revolutionary standards-based architecture for robust software development. This page explains the principal design ideas and components behind the whole XPL architecture and how you could use it for your development needs.
The components realizing the XPL vision have been implemented in an open source fashion. Minute attention has been paid to the details, making XPL a pleasure to work with. During the design of the XPL architecture, special care has been taken to ensure that it has out-of-the-box support for the industry best-practices and integrates well with standards and methodologies such as Object Oriented Programming, Aspect Oriented Programming and Extreme Programming.
Note that XPL is architected to address the needs of programmers of enterprise-class systems. Although it can be used, —with most of its advantages—, for rapid application development, the main focus has been on the design of large-scale applications. This is the area where it has the most potential.
Design ideas
Principles
XPL was inspired by the following principles about software development:
- Software should be easy to write. Low level programming languages such as C, Java, Cobol or Lisp (yes, we consider Java and Lisp low-level programming languages; and you'll probably understand why once you're exposed to XPL) can only be used by experts. Programming should be done in a design-oriented, high level, easy to use language, where the emphasis is put in what needs to be done (as opposed to how it should actually be done). We built XPL for this purpose.
- Software should be maintainable. It should be easy to write tools that assist the programmers in helping them analyze and extract information about software.
- Software should be portable. There are very few reasons why programming code specifying how to execute certain algorithms should be written using a syntax that adds burdensome requirements on machines that will execute it.
- Software should be robust while meeting the demands of the industry. This should be a byproduct of software being easy to write, maintainable and portable, but it was, in itself, one of our inspiring principles.
Central idea
With those principles in mind, we designed our architecture around a single idea:
- Software code should be written in standard and portable XML-formats that make its semantic explicit designed specifically to make it maintainable and robust while making it possible to map it to machine-level representations that can be executed quickly.
Advantages
This helps programmers in many ways:
- Software becomes much more re-usable, since XML can be easily adapted to new contexts, using standard XML standards such as XPath and XQuery. You could, for example, easily extract a function from an XML code file and reuse it in a separate program. Keeping the source code for the functions in both files in sync is as easy as automating a few XML transformations.
- Software is easier to write. Instead of using text editors, programmers are now empowered with feature-rich XML editing tools that they can put to good use to express their algorithms in a representation that a machine can run.
- It is now very easy to create programs that analyze our software. The following are just a few examples:
- We can use simple XML tools to verify that the software is well formed and will compile.
- We can write programs to analyze dependencies of programs as simply as parsing XML.
- We merely need to parse XML in order to generate a graph of function calls in the source code.
- Software becomes much more portable, since XML can be easily read from many platforms. To target a new platform one simply needs to implement XPL on it. This requires only two important tasks:
- Write the code that reads XML files in the XPL schema and executes them, following a few simple rules.
- Implement the subset of the XPL API that is used by the specific program being ported (which can be easily deduced from its source code).
Enterprise Ready
Traditional programming languages are quickly reaching their limits, as software grows in size and complexity. XPL supports the state-of-the-art technology and practices required for Enterprise Level Sofware Development (ELSD) today.
- SOA (Service Oriented Architecture)
- Modern architectures have embrassed the notion of Service. Services are a powerful concept: they can be composed, extended, reused, assembled dynamically, provided by different vendors over the internet, etc. XML is the backbone of SOA, thanks to technology as SOAP and WSDL. XML based, XPL is 100% Services ready!
- Patterns
- Design patterns are recognized as one of the industry best practices. XPL makes design-patterns explicit with XML schema, and customizable, with XSLT.
Components
XPL compiler
XPL unit tester
XPL converters
Last update: 2007-11-11 (Rev 13116)