wiki:XasDocsBasics
Last modified 2 years ago Last modified on 06/29/15 10:47:11

The Basics

After working on several large systems, writing similar code, it becomes obvious that certain standards need to be implemented if the system is to be reliable and maintainable. This system uses Perl, and Perl's motto is roughly "there is more then one way to do something". Which is true. but if you want a reliable, maintainable system, you need to set some standards.

Object Environment

XAS is an object oriented system. Everything is based on objects. Perl has at least five different implementations of OO environments. This either shows the versatility of Perl or a lack of forethought. Either way, you need to pick one and stick with it. XAS uses the Badger OO framework. I feel that this is a better fit then brand M.

Event Environment

Many parts of XAS are event driven. Once again, Perl has many ways to do this style of programming. POE was chosen, mainly because 12 years ago POE was the only game in town. It was either that or reimplementing POE's functionality with Event.pm. Also I don't feel the newer packages are significantly better to implement a rewrite of core functionality.

Date Time Usage

There are several Perl modules for date time manipulation. XAS uses the DateTime suite of modules. They are complete and easy to use.

Database Access

When access to a database is needed, DBIx::Class will be used. This the most complete and robust ORM available.

Parameter Validation

I fell the Params::Validate is the best way to validate parameters. Parameter validation is built into the base class. For command line options, I feel that Getopt::Long is the best option. This is built into the application framework.

Message Passing

Another core functionality of XAS is messaging passing. There are a lot of ways to pass messages around. XAS was developed on a WAN, WAN's are inherently unreliable. So a robust message passing facility was needed. After several false starts, a methodology using "store and forward" technology was implemented. It works like this.

                         (message queue server)
                              /         \
                             /           \
          +----+            /             \               +----+
          |    |           /               \              |    |
          |    |-->[spooler]                [collector]-->|    |
          |    |                                          |    |
          +----+                                          +----+
     spool directory                                     datastore

Which makes for a robust message passing environment.

Interoperability

XAS was designed to be interoperable. It is not a monolithic system. This lead to the consideration of the protocols that were to be used within the system. The message passing protocol is STOMP. STOMP is a text based protocol that every major programming language has a library for. XAS supports v1.0 - v1.2 and had been tested on RabbitMQ. In the past if has also used POE::Component::MesasageQueue. STOMP is the messaging protocol, it is not the message itself. Since the messages are basically Perl data structures, a portable way was need to serialize them. JSON is the defacto serialization and data interchange method used in web applications. Every major programming language was libraries to interact with JSON. JSON-RPC v2.0 is used as the RPC protocol were it is needed. This allows anybody using any programming language to be interoperable with XAS.

Portable

XAS was designed from the ground up to be portable. It will run on any major Unix/Linux flavor with Perl v5.8.8 or later installed. If you install Strawberry Perl on Windows, the code runs unchanged. This includes the daemons, on Windows they will run as native Services, and are controllable from the Service Control Manager. Alas, XAS is not self contained and does need additional modules from the CPAN.

Consistent

The programming environment is consistent. Any method with more the two parameters, uses named parameters. All parameters in pubic interfaces are checked to see if they are correct. Private methods are preceded with an underscore. Package level variables are capitalized. Constants are used for common defaults. All procedures have the same set of core command line options. Commonly used modules are auto loaded when they are first accessed. The operating environment can be redefined through environment variables.