RIA + SOA – The AltioLive Solution

I finally managed to get around to reading magazines I picked up at JavaOne and one article stands out for me. SOA World Magazine, June 2008 (http://soa.sys-con.com/read/513263_2.htm) contains an article called "RIA + SOA : The Next Episode, Building next-generation web platform" which describes how RIA and SOA are shifting web applications architecture back to Client Server from Model View Controller (MVC). So I've decided to pick up on this article and analyse it in the context of AltioLive which uses a far simpler implementation methodology – basically all the hard work is done for you.

Complimenting Technologies

I believe Rich Internet Application (RIA) frameworks provide a complimentary technology solution to enabling the user interface for Service Oriented Architecture (SOA). To quote the SOA World Magazine Article

in the standards-based world of HTML, CSS, and JavaScript, RIA developers have to assemble multiple third-party libraries

to build rich user interfaces. AltioLive provides a single framework to enable the rapid development of rich user interfaces and provides a loosely coupled server side framework to make use of SOA and legacy data sources. This enables an Agile development approach to be used to deliver a user front end that can be adapted quickly to meet user requirements.

Poaching the headers from SOA World Magazine

This section takes the headers from the article and replaces the list of possible HTML, CSS and JavaScript options with the simple AltioLive framework implementation. In my opinion having a choice of different frameworks and custom javascript is a maintenance nightmare and is something AltioLive architecture tries to avoid.

1. Design the "look" of the application.
   For a complex solution requiring branding then a graphic designer can create and define an AltioLive skin. Skins provide the look and feel of borders, scroll bars etc. no need to understand HTML, CSS. For business developers who just want to get on and provide end users with a working system this saves a lot of effort without the need to think about colour codes and styles etc. The design of the user interface is a simple case of dragging and dropping widgets, setting properties and binding them to data.
   
2. Integrate Widgets.
   If a component is not defined as a standard control or business widget (AltioLive Composite Control) then a Java developer can create a new Swing or JavaFX widget by extending the base AltioLive custom control or extending existing controls.
   
3. Add dynamic behaviour to the user interface
   see next section
   
4. Consume Services
   No need to do anything in AltioLive, dynamic user interface interaction with the server comes for free. Plus with AltioLive you get context based routing, ability to poll database tables or HTML service to simulate real time updates to the client. If the infrastructure is available then simply subscribe to a message queue using JMS service requests.
   Not to forget the ultimate aim of connecting to a SOA web service – then just use the Web Service Wizard to create a SOAP service request. No complicated API's to understand and no code to implement, all the business logic is either in the web service or the SQL statement. Validation and data manipulation can all be done in the AltioLive user interface if necessary.
   
5. Create Services
   If the server side business logic does not exist then some hard work will be required. Web Services or alternative business services will need to be written, if a short term solution is needed then it may be possible to use AltioLive JDBC Service Requests to retrieve and insert data while putting logic into the user interface.
   

The article goes on to discuss the need to "Provide an Open Widget Framework", I feel that this is possibly the most important point. The industry needs to have standards that enable Java Applets, Microsoft Silverlight, Macromedia Flash and AJAX widgets to communicate effectively so that a widget that meets the user's needs can be selected regardless of the underlying technology. The key to enabling this standard will probably be JavaScript as it is not tightly coupled to any single vendor solution.

Provide an Integrated RIA Programming Model. This integrated model exists if you use AltioLive. The primary focus for AltioLive is on creating a user interface as simply, quickly and cheaply as possible – through drag and drop and setting properties. The source of the user interface is stored in a plain text file as XML and so can be manually edited if there is a real desire to do so. The drawback of this is that developers can't get their hands as dirty as they may like to. If, as a developer, you really want to get into the depths of the code then a developer can write their own widgets, or focus upon the business logic at the server side. I believe Todd Fast is right when he made the statement "Applications for the masses by the masses: why engineers are an endangered species" (http://www.regdeveloper.co.uk/2008/05/09/developers_endangered_species/ ), the user interface should be about making it easy for the user. Although, I believe there will remain the need for software engineers but their focus should be on providing frameworks and the enablers for the masses to easily create applications.

Provide an Integrated Services Platform. Again AltioLive meets the need to have the following attributes:

• Support for creating services in any programming language
  
• Seamless interoperability between the RIA and SOA tiers
  
• Ability to consume local mock services
  

The AltioLive Presentation Server provides the mechanism to interact with server side components and allows for JMS, JDBC, SOAP, HTTP connections. This means it is possible to make use of direct SQL connections or to write a web service using .Net and call it through the SOAP or HTTP request. While AltioLive is primarily a Java technology it's loosely coupled framework doesn't make Java based services mandatory.

As mentioned through this document AltioLive provides a simple approach to create a service request using one technology and allows migration to another with little or no impact upon the overall application architecture, thus providing seamless interoperability between the RIA and SOA tiers.

Mock services have been a part of AltioLive since its inception. The AltioLive IDE allows a service request to be created with example response data built in, more complex solutions can be created using Composite Service Requests so that different responses can be provided based upon input values. When testing the user interface it may be preferable to replace heavy weight services with a XML file that contains the expected response and then use a HTTP service request to retrieve the data from the XML file. The HTTP service request can simply be replaced with the request to the fully implemented business logic later in the implementation.

Conclusion

The business challenge of moving to SOA

I have yet to work with an organisation that has implemented a SOA architecture from scratch as a green field project, in my experience there has always been legacy integration required to deliver the final solution.

AltioLive overcomes this by allowing the implementation team to expose AltioLive Service Requests. An AltioLive Service Request exposes the same interface regardless of the underlying technology that the data is being retrieved from or written to. This means that an implementation team can initially create a JDBC connection direct to a database and then when a full SOA architecture exposing web-services is in place then the service request can be changed to a Web Service request without any changes to the user interface. This approach enables the rapid development of the user interface required to meet business needs and then a more formal approach can be used to deliver a well defined and structured SOA.

And what about the Enterprise Service Bus (ESB)?

Well using AltioLive the move to a ESB is achieved by modifying the AltioLive server side request to use message queues. If the solution implemented using AltioLive has been well designed then there will be no changes to the XML structure passed to or from the user interface, and now a system will be able to push updates from the message queue to the user interface without any major system changes to the presentation layer.

Where are all the applets?

A recent posting on Jim's blog "Eat your own dog food" mentions www.upnext.com a cool Applet that provides a 3D view of Manhatten (usefull for SIFMA if you're going in June), I posted a comment on Jim's blog but I also wanted to make my own posting.

I'm now wondering how many other Web 2.0 Applets there are out there - upnext is one I will try to mention in my talk at JavaOne 2008.

I have nothing against AJAX, Flash or Silverlight, but I do believe that Applets are being unfairly treated and I'm surprised Sun doesn't have a library of Applet based Web 2.0 sites, or a library of Applet based products (maybe they do and I've been too lazy to find it).

So my pet project for the next few months will be to find more great Applet products....

Go see Altio at JavaOne 2008.

Why use AJAX in the enterprise?

It appears that Forrester Research Inc may have upset a few AJAX people out there by claiming that power users are less than impressed with AJAX in the enterprise (see "AJAX-powered Web apps disappoint power users, Forrester says"). That's not really news at Altio., for a long time we have been aware that the Enterprise power user can be extremely demanding.

Creating a Enterprise application for the browser requires the following at a minimum

• Responsive user interface


• Ability to work with large volumes of data


• Provide all the features expected from a desktop application, which probably means interacting with other desktop applications.

The computerworld article quotes:

" most AJAX frameworks tend to keep all real business logic on the server as opposed to local systems, user interactions may require a roundtrip communication between the browser and server for each input field"

I'm not sure how true this is, I guess JavaScript would need to do this to ensure it maintains performance. Altio does not have this issue and allows for client side validation without any additional performance overhead associated with server roundtrips.

"Some large applications could easily have 50 fields on a single screen."

This statement seems to have caused quite a stir, resulting in a number of strongly worded comments. I would agree that 50 fields does seem like an extreme GUI and probably breaks a lot of usability and GUI design rules but I have seen a number of Call Centre application both in the UK and Far East which have a lot of complex screens with many input fields, including editable lists on one screen (maybe not 50). Sometimes the nature of the business domain requires this. So technical purists who maybe have little business knowledge probably needed to tame their comments a little. It is the business that drives IT demand, it is down to people working in technology to meet the business demands, not enforce technical constraints on business users.

"As a result, AJAX developers told Forrester that they had to reduce real-time input validation compared with traditional rich clients to meet performance requirements. Real time input validation is a top priority for power users, the report said."

Well why not consider Applet based technologies. Applets provide a rich user experience all within a browser, the best of both worlds. I was surprised that the report summary only discussed Adobe and Microsoft Technologies. This shows a lack of knowledge of what Sun are doing in Java 6 with the new Java plugin and Java FX.

Altio and AJAX are similar in that they both interpret the business logic - Altio has it's own XML meta language that defines the logic while AJAX uses Javascript. Altio does provide a flexible means to manipulate data and interact with screens, in addition to this it comes with its own integration layer enabling rapid application development.

It could be argued that Applets have restricted memory because of the Java sandbox, but this will no longer be the case with Java 6 where it will be possible to request more memory from the operating system.

Overall I feel a lot of Analysts and the developer community are ignoring Applets as a technology due to its poor history. I feel that Applets should be used in Rich Enterprise Web Applications, and Sun need to advertise the power of Applets with the new support of Java 6. There are enough Java developers and using a tool like Altio abstracts away the complexity of understanding Swing and AWT.

February Roundup

Better late than never..... one day I will have time to do the summary of the month when the month ends.

IDE's Microsoft Visual Studio 2005 vs Eclipse
So I'm now well into .Net web services, although I have to say I do think Eclipse wins the best IDE competition. My distant past when using Visual Studio was my staple diet for cutting code must of blurred into happy memories.... reality has hit home - the autocompletion doesn't quite cut it when compared to Eclipse.

Other things that have come on the IDE scene is a new AJAX designer if there are anymore AJAX tools out there I can't see how people will decide where to look, why not try AltioLive it's not AJAX, it's not silverlight it's a full on Enterprise RIA, the IDE is written in Altio "so we live by what we preach" :-)

Visual Studio 2005 and Webservices
While I may not be impressed with the VS 2005 IDE I have to say getting a new web service up and running was impressive. I'm pushing the idea of Web Service Contract First (WSCF) and came across WSCF by Thinktecture. It does just what it says on the box, point at a XSD create the code and the WSDL. Although I didn't use the WSDL generator and depended upon the code generated by VS.

Enterprise RIA
Talking of Enterprise RIA Curl have a good article on the power of Applet based technology over AJAX and Macromedia Flash, just replace Curl with Altio and you get the same thing plus a lot more (IMHO our IDE and user interfaces are better - that's my view and not my employers, just in case there's legal issues here)


Google social graph
http://code.google.com/apis/socialgraph/
http://code.google.com/apis/socialgraph/terms.html
I'd like to see what AltioLive can achieve with the new graph control to display social networks.

Into March
March is ramping up to be manic..... the developers on Altio 5.2 are pushing hard to have a Beta release in March, it's that 95% complete syndrome.... the odd horrible bug that just doesn't want to go away.

Oh and by the way if anyone does read my rants come visit me at JavaOne in San Franciso this year.... a few of us from Altio have decided to setup a stall and shout about how great Altio is.