Interestingly SWI-Prolog has many libraries making it pretty much ready for use in a distributed environment, and it wouldn’t seem to hard to implement a form of web-service using the Prolog engine to make logical deductions. In fact I’m working on a specification for a system which would make knowledge/intelligence based software more accessible to end-users, potential business adopters and software developers alike.

It will be interesting to see how things pan out with this development, I hope to be able to have a demonstrable system which can show the potential of intelligence based software architecture.

The programming language we’ve been studying for this module is Prolog which takes some getting used to. We were given further lectures on propositional and predicate logic before we started the Prolog work and this has probably helped to understand the reasoning behind a Prolog declaration and procedure.

A brief point I’d like to make is that many introductory tutorials  will name their variables and predicates (functions if you like) with such helpful convention as X, Y, Z / A, B, C and P, Q, R. Needless to say this doesn’t help to convey much understanding about the operation of such functions. Prolog programming does indeed require a massive shift in perspective from programming in many other languages, and many built-in predicates are defined in this way so it is important to be able to see X, Y, Z for what they are in relation to the application of the predicate. However it might do well to describe your own identifiers more clearly. For example I found it much easier to write a function that finds the maximum number in a list using: CurrentMax and Max than X and Y!

The message is simple, but it might assist those who are struggling to understand more complicated aspects of the programming such as when lists and elements from those lists are utilised. e.g. [X | Y] can become [Element | List].

After spending some time now using the ThinWire RIA platform I can honestly say it is definitely a mature and powerful tool for building web applications that require complex user interface features. While my test application still does not extensively test every feature one may require, it shows ThinWire is a highly viable candidate for developing business applications.

Additionally this has been a useful learning experience from my personal point of view, as a good example of deploying an EAR (Enterprise Archive) carrying a distributed system using sophisticated persistence architecture.

The platform makes producing an application from scratch relatively effortless. There is some initial set-up involved – including removing the Mac files and folders from the ThinWire installation if you’re using Windows (there must have been a better way than the route I took which was to manually delete every one). But I found creating a buildable and deployable application, with an associated Eclipse project, was a very rapid process. The sample applications are fairly sensibly structured in order to give you a very good idea as to an appropriate development pattern to follow.

I now have an application in a healthy enough state to start testing things like persistence of entities to and from a database. It will be interesting to see if there are any behavior quirks due to the design pattern of the platform or if, as claimed, it really can cope with any Java feature you would wish to integrate into your user interface.

Some nice things that you get include a ready to start apache tomcat application server, but also more usefully an apache ant build script for both example applications.

The build script is an excellent addition for any developer looking to rapidly develop deployable and fully functional applications. As far as I can see from examining this script and building my own test app out of it the build and deployment procedure is one of the most straightforward I have come across for an AJAX / RIA platform.

I strongly recommend developer who has never used an apache ant build script to develop and deploy their applications to look into it for future applications they may develop. IDE based deployment tools can only go so far to helping you develop and implement a web application.

So in relatively simple terms an RIA is essentially just a web site transformed into a more complex web application through use of many common application user interface features such as trees, lists, calendar date pickers etc. But AJAX is a term used to describe the technology behind many of the original platforms that provide these rich user interfaces – Asynchronous JavaScript And XML. My problem here is with the XML part of the acronym as many of the newer platforms, to my knowledge ThinWire included, don’t actually directly manipulate XML in the user interface. Or at least its not part of the core functionality of the RIAs mechanism of operating. Sure you might be able to do stuff with XML data within the confines of the platform, but then you can also do stuff with many other data formats too and it would be nonsensical to list all these in an acronym describing the nature of how the RIA actually works.

Of course dropping the AX leaves ‘AJ’ which is not as audibly pleasing a word. AJ also could be prey to a similar fate as the XML in an (unlikely but possible) shift away from JavaScript as a browser language, and additionally a term describing that browser language says little about what it is used for anyway. I am coming round to the idea of calling such things RIA platforms instead to describe any kind of technology which might lie beneath a Rich Internet Application. As there are so many RIA platforms out there with many different modes of operation this seems like the logical solution.

What ThinWire does is push everything out to the server side code, which is written entirely in Java. There is no conversion of Java into JavaScript, the view the user gets is simply handled entirely by some server side code. This seems to me not a terrible model as your user interface can still be contained in a separate .jar than the main application logic to stop the wrong code bleeding into both. Additionally one can presumably use all features of the Java language as the UI components are simply Java classes all the way through. There seems to be a reasonably extensive library of visual components. Like GWT-Ext the UIs created with the ThinWire AJAX platform are event-based. The only downside seems to be that the project hasn’t been updated with new features for sometime, though bug fixes appear to still be being released.

Still if the whole package is essentially all Java, there shouldn’t be anything stopping a user extending the thing themselves for their own purposes. The key ’selling’ point of it is the pushing of the code responsible for the client side view out to the server.

My take – brilliant; put yet another spanner in the works delaying Oracle’s acquisition of Sun and therefore jeopardise all of Sun’s products including Java which put simply seems to me much more important than MySQL.

At the end of the day business decisions are all about compromise, sometimes you have to sacrifice certain things in order to save others. In an uncertain economical climate the more the buy-out of Sun by Oracle is delayed the more damage could potentially occur. To take it to an extreme Oracle may never actually complete the purchase of Sun and then the future is bleak for all Sun technologies which would be a very bad thing indeed.

Interestingly this enjoyable rich experience has since become one we take for granted. We wouldn’t ever dream of going back to a command-line interface for every application (although for some things, a command-line does indeed still make sense). Similarly people focused on the glitz of the world wide web early on in its development, and this again brought more diverse people to become users of computing technology.

However since the initial appeal of these media has faded, we have focused on the functionality of these things in getting our business done. As a result we have become much more impatient with the interfaces we use and less interested in the inner workings of the software itself. Instead of seeing abstract components of an interface we tend to see things literally as what they are supposed to represent.

René Magritte's 'this is not a pipe'

This goal-oriented usage of computers has lead to a mostly two-tiered level of understanding amongst users. There are those that see the visual things they are manipulating as exactly what they represent. For them the interaction begins with their direct input put into the system and ends with the output which is generally received instantaneously. Then there are those that are aware of the underlying structures and models that are being manipulated by the software itself in order to carry out their instructions.

This variation in user perspective of computing technology is an interesting area of social differences relating to issues such as software ‘usability’. What is also interesting is the functional manner of usage users will eventually adopt with new technology. It does unfortunately breed a ‘why can’t the computer do a simple task I ask it’ mentality when a user encounters problems with an operation they are trying to perform: even if the operation is in fact actually incredibly complex in terms of the work that is carried out by the ‘computer’ and indeed any networked resources it may utilise.