AltioLive Presentation Server features
The AltioLive Presentation Server (APS) provides a lightweight and powerful mechanism to integrate a rich web application with data sources. APS can be deployed to Apache Tomcat or to a enterprise J2EE environment such as IBM WebSphere or BEA Weblogic. This means that a solution can be scaled to meet the appropriate business and technology demands without the need for software re-writes.
This entry describes some of the main features of APS focusing upon items that should be considered when designing an Altio framework solution.
Service Requests
A connection to a data source in the Altio framework is called a Service Request. A Service Request can be made to a message bus using JMS, a database using JDBC, webservices through a WSDL service, HTTP services or direct to java classes. Service requests are configured through the Altio Application Manager administration screens.
As discussed in other blog entries ( SOA + RIA - The AltioLive Solution ) a well designed client to server integration enables the underlying technology to be abstracted behind service requests. This makes it possible to change the service request technology without modifying client applications.
Modular re-usable integration services
Because of the composite nature of the Altio framework it is possible to write data services and use them across multiple deployed applications. As the use of Altio grows within an organisation then reusability can be achieved by sharing service requests across multiple solutions, reducing the cost of testing and maintenance. At some point in the future Altio may even start producing pre-built data connectors to popular commercial and consumer products.
Being able to modify one file and deploy it reduces testing and deployment time, and because the configuration are XML files it is possible to easily verify the dependencies. It can be argued the same reuse can be achieved through code reuse or library reuse. But, can a development and configuration team truly be sure that all modified functionality is identified without the use of complex auditing and verification, especially when a file is in binary format.
Composite Service Requests
An important aspect of having server side integration is the control that an IT department has over the data made available to applications.
Composite Service Requests provide a mechanism by which data from multiple disparate data source can combined into one XML block. The results of one service request in the composition can be used to execute subsequent requests providing the ability to execute a very powerful sequence of events from one client request.
Datapools, context based data routing, and data security
Datapools in the Altio framework are the mechanism by which data is pushed to a connected client. A datapool provides an effective means by which data from a SQL database, WebService, Message Bus or other datasource can be queried once and pushed to multiple connected clients. This improves the scalability of systems by reducing the overhead of many connected clients to systems that own the data.
AltioLive Presentation Server provides two types of datapools, transient and non-transient. Transient datapools do not maintain any state and pass any data updates directly to connected client applications. Non-transient datapools maintain a copy of the data passed to connected client applications that can be used for context based routing of messages and their content.
Context based routing controls the data delivered to a client application by applying filters to data in a datapool before it is delivered to the client application. All or part of a XML data payload can be prevented from being sent to individual clients. This ensures that even at the network layer data delivery is restricted to specific IP addresses. Combined with streamed connections this provides the strong security mechanism of the client and server Altio framework.
The alternative to context based routing would be to use UDP based message broadcasts and filter the data at the client application. Broadcast publication of message does not prevent the creation of an application that can listen for the messages and intercept them when they are not intended for that recipient. UDP messages are not supported by the AltioLive client but a server side plugin could be created to receive the messages.
Clustering
APS can be deployed in several different clustered scenario’s or standalone. The choice of clustering will vary depending upon deployment technology and operational requirements of the solution.
Technology choice will be about which web container to use, the simplest will be Apache Tomcat rising to a larger commercial solution such as IBM Websphere or BEA Weblogic. Each of these platforms enables clustering and so does APS. The main reason for using clustered deployments will be fault tolerance and scalability through load balancing.
Fault tolerance can be achieved by simply having cold or warm start backup servers. Because APS does not require its own data repository then there is no risk of data loss within APS.
When clustered load balancing is required and datapools are used for context based routing or push data updates then it will be necessary to consider synchronising APS instances on each deployment. This ensures datapools maintain synchronisation with each other.
Summary
The AltioLive Application Presentation Server(APS) provides an organisation with the ability to introduce a low cost, scalable and simple mechanism to integrate disparate data sources into a single platform that is not tightly coupled to a specific technology. All messages sent from an APS are XML based but importantly they can be encrypted, compressed and routed to client applications to ensure a secure data delivery mechanism.
Reference
http://en.wikipedia.org/wiki/User_Datagram_Protocol
http://www.altio.com/download/documentation/Online_Help/composite_service.htm
http://www.altio.com/download/documentation/Online_Help/example_architectures.htm
http://www.altio.com/download/documentation/Online_Help/clustering.htm
http://www.altio.com/download/documentation/Online_Help/master_slave_configuration.htm
http://www.altio.com/download/documentation/Online_Help/data_routing2.htm
http://www.altio.com/download/documentation/Online_Help/set_up_datapools.htm


The statement ‘XML based messages can be encrypted and compressed’ has raised my greatest interest; because one of the reasons why there’s a strong JSON movement these days is: The disadvantageous overhead of sending XML over the wire compared to JSON; now XML encryption and compression could exactly be the mechanism to provide security and efficient bandwith usage
… Does AltioLive use its own engines for those tasks ? Or how is e.g. XML compression at the server and XML decompression at the client be accomplished ? And is sending compressed XML over the wire comparable to sending (compressed) JSON over the wire ?
Comment by verlsnake — Friday 2 January 2009 @ 14:21
The focus of the Altio compression has always been on the reducing the number of repeated elements and attributes, GZIP compression handles content. Altio uses its own engine to compress the XML. The level of compression achieved depends upon the structure of the XML e.g. repeated element and attribute names. Once the Altio compression is complete there is little difference between the data size of a JSON message and Altio. The Altio message size will always be larger because Altio provides the ability to display the original XML data structure and so maintains a list of element tags. Thanks for the interest, there will be a more posts on Altio data structures efficient data updates.
Comment by garyt — Monday 5 January 2009 @ 13:38