It is important to understand how the design of the XML will have an effect upon the delivery of live updates to the screen. In this blog entry the in memory database indexing as well as XML structure is summarised.

AltioLive achieves zero network latency data manipulation by maintaining a copy of data accessed by the client through a in memory database. This means that filters can be applied to the client data preventing the need to perform round trip server requests every time the user wishes to change the data viewed. Updates to the client database can be achieved through the use of data pools that push updates to the client.

AltioLive Client Side Database

AltioLive Client maintains a database of the XML data structures, which is indexed using AL_ID’s. This database is used to ensure efficient screen updates and to reduce the overall size of XML payloads sent and received by the AltioLive client.

AL_ID’s are defined using data keys. A data key must provide a mechanism to uniquely identify an XML element. When an update from the server datapool is received, the AL_ID of the XML element is looked up and the data contained within that element replaced.  Any controls connected to the modified data are refreshed to reflect the changes.

Each XML element is treated independently of parent and child elements. This means that data updates do not need to supply the whole XML block to refresh data. As long as the elements and attributes used for data keys are supplied for each parent element then the XML structure will be maintained.

Structuring XML for live update to the client

Achieving a balance between maintainability of the application and efficient screen updates requires the designer to consider the use of attribute and element based XML.

Traditional XML design recommends the use of element based XML structures. Historical weaknesses in DTD are probably the primary reason for this. While there is no reason why an AltioLive application cannot make use of XML that primarily uses elements, there are a number of reasons why attribute based structures are better for AltioLive applications;

• The number of required data keys is reduced
• Designer property settings are easier to read, you define the data source and the data field is a named attribute rather the the element <code>text()</code> reference.
• Reduced XML complexity
• Reduced size of the XML structures

The drawback of having shallow XML data structures that primarily use attributes is that changes to one attribute in the element cause all controls referencing the element to be refreshed, even if the attribute referenced by each control is different.

A general rule for structuring the XML is to identify data that will be refreshed regularly and put this into an element.

Example XML structure;

<static_element portfolio=”my portfolio” desc=”I won’t change often” owner=”anyone” attr1=”sfsfs” attr2=”jkjllklll”>

<dynamic_element stock_id=”alt” stock_value=”120.01″ desc=”I change frequently” />

</static_element>

Example data keys for the above example  

• static_element - concat(@portfolio,”-”, @owner)
• dynamic_element - concat(parent::*/@AL_ID, “-” , @stock_id)

Designing a service request that retrieves only the required data means that efficient dynamic screen updates can be achieved through an XML structure such as

<static_element portfolio=”my portfolio”  owner=”anyone” >

<dynamic_element stock_id=”alt” stock_value=”125.01″ />

</static_element>

In the above XML block the dynamic_element can be identified and controls referencing this elements data will be refreshed to reflect any changes.

The effect of time stamps

Time stamps play an important role of ensuring only the latest updates are reflected within the user interface. In the earlier examples no time stamps were used in the XML elements, this means that every time the XML is received from the server it will be processed and controls that have the element as a data source will be refreshed.

By adding a time stamp attribute and defining the time stamp in the service request it is possible to ensure only the data that changed is refreshed on the screen.

<static_element portfolio=”my portfolio”  owner=”anyone” timestamp=”1″>

<dynamic_element stock_id=”alt” stock_value=”125.01″ timestamp=”3″/>

</static_element>

In the above XML block incrementing the time stamp attribute of the dynamic_element block each time a change occurs ensures that only controls that have the dynamic_element as the data source are refreshed. No action will be taken on the static_element data unless the time stamp value increases.

A time stamp attribute can be a date time value, or a number. The important factor is that the value must increment to ensure screen refreshes take place. This also ensures that data received out of sequence is processed correctly by ensuring only the latest update in the time stamp sequence is reflected in the screen.

 

References:

http://www.w3.org/TR/REC-xml/

http://www.w3.org/TR/xmlschema-0/

http://www.ibm.com/developerworks/xml/library/x-tipsub.html

http://msdn.microsoft.com/en-us/library/ms345115.aspx

http://www.altio.com/download/documentation/Online_Help/data_routing2.htm

http://www.altio.com/download/documentation/Online_Help/what_are_datapools_.htm

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