The development team have also worked long and hard to adapt the core Altio framework so that it can integrate with the BIRT report engine. The beta version of Report Writer is available by request. Further information can be found on the Altio 53 overview page.

Other items of interest in the coming weeks are
… a move towards using GetSatisfaction for support forums.
… release of the AltioLive datagrid. Like a list control but this enables formatting of cells, copy and paste multiple cells plus a number of other features

For historic reasons Swing and applets are often overlooked in favour of Adobe Flash, Swing doesn’t have to be restricted to the desktop domain, AltioLive has proved this. Java Swing and Applets can be used to produce great applications and there are a lot of people with Java Swing skills. We feel the lack of JavaFX integration into Swing does not help adoption of JavaFX, it hinders it.

Java Swing is a mature and capable language. The real problem is that developers want to learn something new, rather than master something that already exists. At Altio, we feel the important principle is focusing upon business benefits instead of technology advantage. If there is a need to build a rich media UI and given the choice would a developer learn JavaFX or Flex?

Interesting that Red Hat seems to think it owns the rights to XML data routing. Altio has a similar, if not the same, patent claim from 2003. At present Altio does not want to get into a legal battle over who’s patent is more valid, preferring the innovation approach to stay ahead of the game.

Software patents are a controversial subject with strong feelings amongst the developer community, I feel they are now a part of running a software development company. If you do not wish to take the patent path then it is important to ensure you make a public statement about an innovation. Without public knowledge an organisation is at risk of a megavendor claiming a patent and making life very difficult for small software houses.

Unless an organisation can innovate faster and better than everyone else and are not concerned who uses the innovation then I feel patents, as a defensive measure, are necessary. The problem with being innovative is that it costs money upfront, using somebody else’s idea is easy if you have lots of cash available. Sometimes the small vendors may just need to make a stand and use their patent for financial gain and maintaining market position.

Ideally software companies would get on with being innovative and writing good quality software. Instead all the big players look for are ways to make a quick buck at the expense of innovation. If you’re an innovator you just want to write good code, not fight legal battles.

It appears software patent litigation may become a normal part of being in the software industry.

Software should be a tool used for business success and so needs to make the creation of business solutions as simple as possible. This is the ultimate aim of AltioLive. The same thoughts must be going on at MIT, go take a look at Scratch.

I have structured the response to include the text from the original posting followed by a comment relating to AltioLive’s support for the functionality.

Includes all core application layers (MVC)

“A web framework should include data access, business logic, controller and presentation layers internally. As frameworks turn out to be an integration hub, it loses value. Every integration among the core layers introduces new complexity, new glue code, new dependency, and conflict of intersecting features. If data access layer (Model) uses another framework, presentation layer (View) uses another framework, integrating these frameworks adds a very big challenge even if frameworks support each other.
Replacing any framework causes many new problems later. For example, JPA is developed for data access independence but at this time you are limited only the features of JPA. IDE is a major development tool, but at this time we need an “Integrated Development Frameworks” environment within IDE. (Similar with ERPs that brought together enterprise applications under the same umbrella)”

The AltioLive integration layer was discussed in December last year in the article AltioLive Presentation Server features. The reasons for AltioLive having an IDE inside the web browser are described in the blog item “Why does AltioLive have its own IDE?“. Logic associated with user interface interaction is handled within the client side application, while business logic is expected to be handled on the server via web services, Java code etc.

Avoids heavy-componentization:

“In web architecture, desktop-like componentization is heavy and inflexible. Components in desktop applications were very successful. They utilized reusability and could be used in IDEs. In web applications, the component model doesn’t work at the same form. Efforts to convert HTML (+JavaScript) into component model will not be as successful. This is because HTML is dynamic (DHTML), works on client and is declarative (Declarative Programming).
With heavy-components, we lose declarative programming to some degree. We lose “Web Graphics Designer” ability to edit web pages because of moving from design-time to run-time and moving structure information from HTML to programs (while losing HTML Editor functionality). A web editor’s favorite structure format is CSS files so what about CSS componentization?
Another problem is architectural. A web GUI has 2 runtimes; server and client (Browser). In previous years, web frameworks supported only server-side functionality. Today we see client-side-only approach. I think best solution is balanced mixture of both client-side (JS) and server-side code with component templates (not hard components but light partial HTML+JSP+Servlet codes). I will discuss this further, there are already many discussions about “Component-based” versus “Action-based” frameworks on the web.”

AltioLive 5.2 has introduced a mechanism by which business components can be created from low level widgets to create composite applications this is discussed in Altio support for composite applications. I believe the ability to create components by aggregating widgets is a must for business solutions where re-use is important. While each technology may use its own approach to achieving a component I do not think it is something all frameworks should support.

No new tag markup or page template:

Some web frameworks require learning a new markup with no added-value. Your form inputs turn out to be strange tags. Finally, developers don’t understand HTML, JavaScript, CSS because there is no time left for this learning. Who will fix GUI errors? Frameworks should bring a minimum or no new tags. Instead we may prefer attributes. HTML tags with simple JSP expressions are enough (KISS). Isolating developers from HTML and JavaScript is not possible.”

AltioLive stands apart here, it is very much a declarative environment. In fact the user interface is designed using an IDE you insert logic using actions and where necessary call out to JavaScript. The hardest issue here is if AltioLive should be called a development tool or a power user tool, at the moment it sits in between. In the future AltioLive will focus on appealing to both developers and users by providing scripting languages for developers and wizards for power users.

No XML usage:

“Heavy XML usage for configurations makes programs hard to develop, hard to understand, hard to test. One example is “Page Flow” information in XML files. Another example is bean configuration. Yes, pulling this information makes it flexible but who needs it? How many times does your page flow really change? How many times did we utilize flexible bean configuration? What about source code readability? I don’t like “Dependency” or  “Dependency Injection”. I think dependency is not free as you have to manage its subtleties. Here is my anti-pattern “Dependency Rejection”. XML can be used in other useful places like AJAX messages or data import-export.”

If you agree this statement then AltioLive will not be for you. AltioLive is all about using XML to declare the way the user interface looks and behaves, although the designer provided with AltioLive means that you do not have to be exposed to the XML source files. I am also a strong believer in “Dependency Injection”, “Inversion of Control”. Many AltioLive solutions have a server side layer that incorporates SpringFramework for handling business logic.

Has its own web GUI page elements:

“Rich web elements (say light components) are generally found only in JS or AJAX libraries. Web frameworks should provide rich elements like; Calendar, Dialog, Menu, Popup, Progress Bar, List, Grid, Tab (With sub-levels), Master-Detail Windows, Child Windows, Record Navigator etc. Developers can easily extend these elements. We are still turning around simple features like table sorting, filtering etc. We should step ahead. There is still no desktop-like web grid components to use (I see this only in JS libraries) that I mentioned in my previous blog post.”

As far as I can tell AltioLive supports all of the functionality discussed. What I would like to see is more third party developers writing new controls for the AltioLive framework, especially open source controls.

Code generation:

“Code Generation makes “Rapid Development” possible. Every piece of software should be generated (Generative Programming); CRUD data access classes, business code, controller code, and view pages. Code generation takes development one step ahead of “Drag and Drop” WYSIWYG editors. If a web framework facilitates code generation, developers could jump to customization details of application instead of building everything from scratch (MDA).”

AltioLive takes the user interface declarations and executes them at runtime, there is no code generation before execution of the application. All logic is handled through declarative action statements.

strong>Has its own GUI JavaScript library:

“Another bleeding integration point is JavaScript libraries. JavaScript libraries are not fully-integratable with web frameworks. They try to solve the problem on the client side. What we need is close cooperation with client-side and server-side. Unfortunately, most of the web frameworks have little or no JavaScript in their presentation layer.”

Very little JavaScript is used in AltioLive, if you use Java6u12 on the server then most scripting languages can be executed through the AltoLive presentation server.

AJAX support (Asynchronous Communication):

“AJAX eliminates page-refreshes. Web frameworks should properly blend AJAX functionality into their code architecture. AJAX requires server-side coding. As we make client runtime powerful with AJAX, GUI state management code is duplicated. For example, if we update and fill a combo-box with AJAX call then server-side bean that is bound to this element is not aware of this state change. We have to change server-side state as well. AJAX functionality should be implemented without code duplication (Another interesting trend is AJAX MVC).”

AltioLive supports push data and asynchronous processing of data as described in AltioLive - Pushing data to the client. The concept of binding client and server data together is a good idea, but I have typically found that users want control on when the data change takes place. The AltioLive alternative to a user action committing data is to add an AltioLive action whenever the data changes.

Portable among application or database servers:

“Application and database portability is not easy. In Application Server side, class loader policies change, session management changes, deployment model changes etc. In DBMS side, join clauses change, paging, and sequence generating changes. Web frameworks should provide portable packages for different platforms. On the other hand, some web frameworks have their own IDE and Application Server (believe me even DBMS). I think we must leave this job to the famous products (IDEs and Application Servers in the market).”

AltioLive can be used on all major Application servers and makes use of JDBC for database connections. Yes, AltioLive has a very simple database for prototyping which will probably be replaced in the future with an alternative such as MySql. AltioLive also has a client side in memory database to provide efficient access when large volumes of data are being used in the client. The AltioLive IDE was around before AJAX had a name and Eclipse wasn’t rich enough to allow the creation of UI widgets, also some clients favour a Web based IDE for security reasons.

Input validation:

“Data input validation is a very important feature. If validation doesn’t occur in application, database error occurs. Database errors are not user-friendly. Some validation errors may not be related to database. Programmers need automatic validation according to database object metadata. Custom validations should be added if needed. “

AltioLive Formatting rules I feel covers this. AltioLive allows fields to be declared as required and the data type to be defined, as well as specifying validation rules.

Bug-free

“Because of bugs in frameworks, all average developers become framework experts spending valuable time to figure out the problem. “Focusing on business problems” is lost. I have read many open source framework hacks and workarounds in many blogs, which is not the task of a developer.”

Well I’d really like to say all software is bug free. The wider discussion should be around proprietary verses open source.

Handles exceptions in a user-friendly way:

“If error or exception occurs, user-friendly messages should be returned. Application programmers have some responsibility for this but web frameworks may ease this task.”

I agree, and all products including AltioLive can improve in this area, the question I always ask myself is how much information do you log and how much do you give to the end user.

Eliminates double-click, double-submission problems:

“Double-click may cause double-submission. Double-submission may cause unexpected errors in application (2 threads trying to do same thing). Web frameworks can eliminate this problem even in client-side without going to server.”

In AltioLive this can be overcome in many ways- displaying a processing dialogue that disappears when the transaction is complete, or by clicking the button and closing the open window or screen, or disabling the button while the process is executing are amongst some of the options.

Authentication and authorization support:

“User login (authentication) is still developed by programmers without knowledge of SQL-Injection attacks. Web application authorization is still missing. Who will be granted CRUD access on which application etc.?(User roles, permissions) I am sure that in every enterprise web application, application authentication and authorization is re-invented.”

Couldn’t agree more, but would one size fit all and how complex, how simple would such a framework need to be. At the moment AltioLive doesn’t support this because it is normally engineered into the solution. Each organisation has its own preferred way of doing things.

Security controls for web attacks:

“Web frameworks should prevent web security attacks like; Cross-Site Scripting (XSS), SQL Injection, URL Manipulation, HTTP Injection, Session Hijacking etc. Web client data is un-trusted and open to tampering so this is why we can’t quit totally server-side validation for the sake of client-side validation. “

AltioLive is an Applet, so all data has to come from the server that hosted the applet. AltioLive separates SQL into a server side configuration preventing modification to SQL statements. There are no URL form submissions in AltioLive and client server communication is encrypted. Data stored on the client is held in an in memory database so is not easily accessed unless through the AltioLive API. Also, there is no client side script that can be used to investigate how the system works. So while all of this cannot guarantee  100% security, I am not convinced any system can.

Reporting integration and barcode support:

“Reporting integration is important. We need reporting products/frameworks integration. Would you use your data access objects in your reports? Would your reporting engine use the same JVM runtime? Barcode is not a general requirement but in ERP applications it is very useful (AI/DC Automatic Identification/Data Capture). Barcode printing, barcode reading and matching may be provided by your web framework.(What about RFID?) Would your reporting product support your application barcode? “

I do know of one organisation using AltioLive that has created their own Barcode controls for use within AltioLive, but I have never comes across any further demand. Reporting is more interesting there is a  lot of interest in report functionality from existing and new AltioLive clients. To address this  AltioLive 5.3 will introduce report scheduling and creation.

Messaging and workflow integration:

“Web frameworks may support easy integration with messaging (JMS) and workflow products. Workflow is one of major element of BPM (Business Process Management). In some middleware stacks, this is included (i.e. JBoss Seam jBPM). Web application frameworks may support business events and workflow activities. These events can also be used to feed messaging backbone (ESB). “

AltioLive has very basic workflow but relies integration with other products to provide full workflow solutions. AltioLive integration with JMS is mentioned in SOA + RIA - The AltioLive Solution and AltioLive Presentation Server features.

Application to application integration (i.e. Web Services):

“In Java, there is external system (EIS, legacy) integration API, which is JCA, but inter-application communication within same JVM is not standardized. Let’s say we have two applications and one should use some call to the other’s application code. There is no standard for this. Basic solution is just adding other application’s path into its class-path and then using other application objects. We developed an Adapter API for standardization of this. In one-application environment, this is not a problem but if many applications are required to communicate, it gets more important. You can even convert your APIs into web services when necessary (integration with remote or non-Java systems). Web frameworks may provide tools for web services code generation, deployment and monitoring.”

AltioLive does not directly solve this problem. That said maybe the AltioLive composite service requests mentioned in Altio support for composite applications goes some way to solving this problem.

Admin application for run-time process and user session monitoring:

“This is very important in the case of user and system management view. What are my users executing at the moment? Which applications take longer to finish? Which users are on-site? Which pages are they surfing? In each session, which objects are they created? What are the URLs that a user requested? Which SQL statement did a user execute?”

Not convinced this should be part of a framework, some nice ideas that should probably be seen in the AltioLive application administration screens. I do think many of the features belong deeper in the logic of the application. I wonder how many people would then be concerned with performance issues associated with large amounts of logging.

System resource management:

“If your application runs big queries that require a lot of system resources (CPU, RAM, DISK I/O), we are faced the reality that resources are limited. If applications don’t restrict user processes, then system will consume its all resources and will not respond to even small processes. For the sake of system availability some user may be rejected by system. The web framework may have such limitation API’s.”

I’m not convinced a web framework should be responsible for this, I would like to think clustering and load balancing solves the problem.  To some extent I can see the argument for the web framework preventing the problem. But, this leads to users and designers blaming the web front end when user tasks become sluggish or are prevented because of the inability of the back-end system to cope with user demand.

Cluster support:

“When server load is high and performance is a major concern, load-balancing is required. Application server clustering will not suffice, web frameworks must support a cluster architecture. One simple example is framework’s id generators. They will collide in clustered Application Server environment.”

AltioLive has many possible configurations for clustering that ensures load balancing and fault tolerance as mentioned in AltioLive Presentation Server features.

Multi-database, multi-company, multi-window, multi-session support:

“The application user may need to work on multiple database instances. One user may have to work with multiple companies. The user may want to use multiple GUI windows. Web framework should handle or prevent state corruption among windows. The user may need to work on the system with many sessions.”

I’m not sure what the issue being raised here is. AltioLive supports multiple databases, a created application can make use of any number of database sources, web services sources etc. “Multiple GUI” windows - if this means a Multi Document Application then AltioLive supports this.

Internationalization:

“If there are global users, then i18n support is important. One key aspect here is that the Application Server and DBMS should also support your localization.”

This is supported by AltoLive, the browser provides the locale and as long as the language files for the application are implemented on the server then captions for controls use the correct locale.

SSL support:

“If the web application is required to be secure in insecure networks, SSL-support is important. SSL deployment in an HTTP Server would not be enough. Even if SSL is not used, frameworks must encrypt sensitive data between client and server, like user passwords.”

AltioLive provides encryption of passwords, but will rely upon the SSL of the HTTP Server for secure connections.

Document attachment:

“In every enterprise application, document attachment is important. Users may want images or Excel documents attached to their application records. Every programmer first search for an upload utility then tries to understand server document folders. Instead, built-in functionality saves valuable time.”

This sounds like a nice to have requirement, there are many solutions to this problem and I am not convinced a generic solution provided by a framework is going to meet all requirements.

Mobile device support (i.e. Internet Explorer Mobile):

If we want to plan mobile access to our applications, how can we do this with web technologies? Many mobile devices have built-in web browsers and we may run our applications in these browsers. Web framework mobile support would be very beneficial at such cases. Otherwise, you should explore mobile web browser limitations by yourself. “

There is no quick win to this. In my opinion there is no simple re-use of screens in a web browser that will work in a mobile device, especially when the application needs to provide a rich user interface. The user interaction for a mobile device is different to a desktop computer and applications need to be adapted as necessary.

Portal features:

“Partial web components should be supported to use in Portals or external sites. In portal terminology, its name is portlet. There are many synonyms; Widget, Mashup etc. “

Something to be revisited again in future versions of Altio. Portal support was available in early versions of Altio but we have found that this has never been high on client priorities.

Scheduling: 

“Application task may be batched and scheduled. After task completion, users may see results. “

Task scheduling will be supported as part of the AltioLive Report Writer (AltioLive 5.3), other bespoke solutions using quartz or offline processing have been achieved using bespoke server side solutions integrated with AltioLive.

Keyboard hot-keys: 

“Users, especially old TUI (Text UI) users want keyboard hot-keys. Buttons, command icons should be bound to hot-keys. Web frameworks elements can support this instead of developing in every application. “

Keyboard hot-keys are fully supported by AltioLive and are defined at design time.

Alerts between users:

“Users may want to send messages to each other or system admin may want to send messages to users like notifying a shutdown or an application restart. This feature will be very handy. “

Easily achieved in AltioLive by making use of data pools on the AltioLive  Presentation Server. AltioLive provides Application Server administrators with the ability to post messages to all or individual users.

AltioLive Product Summary

AltioLive is not a typical Web Framework like Tapestry, Struts or Wicket, it provides a higher level framework that enables the rapid implementation of rich web front ends. The AltioLive architecture consists of a server side component that enables integration data sources and a Java Swing front end.

It is the aim of Altio to allow power users to be able to build their own applications as quickly and easily as possible by reusing components created by the software development teams.

The core product is not open source but can be downloaded for free and used for production deployment with a restricted license.

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

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

Streamed connections are typically used when there is a need to ensure constant and efficient updates from the server to the client, providing a low latency connection. The weakness with this type of connection is the scalability, each connection requires a new socket connection to be maintained.

Polled connections do not have the issue of requiring a socket connection to be constantly open, and so provide the ability to have far more users connected. The drawback with polled connections is that there can be a delay in data delivery, the delay being dependent upon the poll rate.

Through configuration settings AltioLive is easily switched between polling and streamed connection without the need to write a single line of code, allowing operational teams to decide the appropriate model without the need to re-design or re-engineer any components.

AltioLive Presentation Server is not an expensive server side component, and comes with a simple mechanism for connecting to multiple different data sources e.g. database, web service, http.

The AltioLive client is data aware which means that no additional client logic is required to handle the data updates, reducing the cost of implementing solutions that require live updates of data.

References:

http://en.wikipedia.org/wiki/Comet_(programming).

http://www.dzone.com/links/why_flash_must_adopt_comet.html.

Back in 1999 the original reason for having an Altio IDE was that there was no dominant IDE in the market place, and show casing your products capabilities in an IDE was a good way of demonstrating what can be achieved.

Being a Java based product it could now be argued that AltioLive applications should be editable using common IDE’s, such as Eclipse and NetBeans.  This still does not remove the fact that if a tool is so good then why isn’t the IDE written using its own base language. AltioLive is a tool for creating Rich Web Applications so its IDE should be a rich web application. 

The Altio team is now striving to deliver a framework that can be used by a broad spectrum of people with varying software skills. At present we lie somewhere between a development tool and a power user tool. AltioLive will appeal to:

• software developers with little experience of creating user interfaces and do not want to understand the complexities of the Java Swing API’s. But, the solution they may want to deliver requires a highly scaleable and rich user interface within the web browser.
• experienced Java developers that want to build their own user interface controls but do not want to build a whole integration framework to the server. They want 80% of the work done for them so that they can get on with the specific needs of the project.
• consultants who want the ability to deliver a rich web application that has security, server push data delivery, reusability and most of all the ability to deliver a user interface solution as quickly as possible.
• designers, and business analysts who want to be able to define a user interface and possibly implement early prototypes without the need to rely upon a development team early in the project.

The above points are not an extensive list, AltioLive is used as an OEM tool within larger products to allow the development of highly customisable, maintainable user interfaces. It is also used within financial institutes to deliver very rich and interactive user interfaces where data is pushed from the server to multiple users.

AltioLive applications can be edited within Eclipse or a simple text editor if you really want to, after all the underlying logic and screen definition are written to XML files in a declarative language. Many of our competitors take this approach now, the strength of Altio is WYSIWYG, you build the user interface interactively.

The bottom line is that I want to see Altio deliver a simple to use application development tool that can be used by someone with the most basic programming knowledge. This in turn should mean the performance of project teams in increased, thus increasing the chances of delivering IT projects at cost and on time.