A quick round up of what seem to be the current major development libraries and/or environments for developing RIAs.
Flash is the well-known browser plug-in from Adobe as well as the development platform. Adobe have also announced in the mean time - but not released - Apollo as a cross platform run-time that handles Flash, Flex, PDF, plain HTML or Ajax based user interface. Effectively a type of universal client instead of the browser.
DoJo is an open source javascript library. As well as the usual UI components, one feature I find interesting are components to store data on the local drive. I first saw this feature used in TiddlyWiki.
script.aculo.us is also a javascript library. It is based on the Prototype javascript library.
Google Web Toolkit (GWT). The GWT lets developers write code in Java which is then converted to JavaScript apparently apparently freeing the developer for learning JavaScript (Java developers are assumed here, not a bad assumption for most enterprise development work). This has been nicely written up in a IBM developer world article.
Are there any more?
About the architecture that sits somewhere between the business processes and the code.
Saturday, February 17, 2007
Wednesday, February 14, 2007
Loosely coupled interfaces
I posted a short while back an entry about designing generic service interfaces. By chance I happened to come across this (rather old) blog entry by Carlos E. Perez in which he proposes extending speech acts to define loosely couple interfaces. He bases it on a paper by researchers at Stockholm University in which they try to provide a universal framework for human communication in an economic domain, i.e. the business world (the paper is still marked as work-in-progress, so I guess it hasn't been peer reviewed). To do this they use a a triple:
So, to create a new customer record the triple could be:
the service could then return with:
(reject, create, aCustomer)
You can have a lot of fun thinking up new combinations. One thing to notice is that services themselves don't seem to have names. Instead, one could envision a dispatcher which takes each received triple and then finds the correct service implementation.
If this would work out in practice, I do not know. But it seems to aid support to my argument that the REST vs SOAP debate is about which technology should be used, and not about designing interfaces to achieve loosely coupled services. How to achieve this should be the real debate.
(intention, action, object).
The values each element can take on are:Intention | Action | ||
propose | create | ||
accept | change | ||
reject | cancel | ||
declare | none | ||
query | |||
reply | |||
assert |
So, to create a new customer record the triple could be:
(propose, create, aCustomer)
the service could then return with:
(accept, create, aCustomer)
or, in the case of an error could return:(reject, create, aCustomer)
You can have a lot of fun thinking up new combinations. One thing to notice is that services themselves don't seem to have names. Instead, one could envision a dispatcher which takes each received triple and then finds the correct service implementation.
If this would work out in practice, I do not know. But it seems to aid support to my argument that the REST vs SOAP debate is about which technology should be used, and not about designing interfaces to achieve loosely coupled services. How to achieve this should be the real debate.
Tuesday, February 13, 2007
Friday, February 09, 2007
The next n-tier architecture
It seems that the now traditional three tier architecture may well be slowly coming to an end. For specialised high performance applications, the bottlenecks between the tiers have already been pushing developers in this area to turn to specialised data caching platforms such as Tangosol, or to unified application platforms such as Intersystems Ensemble. In the data caching area the architecture seems to be consolidating to a cached data pool which is accessible from many machines in a cluster. This trend is now being followed by vendors of "traditional" application servers such as BEA and IBM. For SOAs this has the advantage that each service accesses the same data in the data pool, rather than having to aggregate data from different data sources (see diagram). The application platform deals with all the hard problems of data caching such as data consistency, cache actualization etc.
Not so long ago I saw a presentation from GigaSpaces who also provided a cached data pool. What is interesting about the product architecture is that they have revived the old, and hardly adopted, JavaSpaces concept. The data pool (or space) is a set of Java objects which are effectively in a shared memory accessable from each machine in a cluster. Each object can be accessed by providing a "template" which matches the contents of the objects and returns one of more of the matching objects. Templates can also be set as triggers, so that creation of new objects with particular data characteristics can notify another Java object. If you're still interested, a good tutorial on Java Spaces can be found here.
Thursday, February 08, 2007
Building Virtual SOAs
Doug Kaye has written about how he used Amazon web services to build the infrastructure for his application, i.e.
Using these tools, what stops you defining a "virtual" SOA, in which the Coghead defined UI triggers the orchestration which calls up web services implemented using the Amazon virtual infrastructure?
- elastic compute cloud to run the apps
- simple storage services to store the content
- simple queue services to connect the apps.
Using these tools, what stops you defining a "virtual" SOA, in which the Coghead defined UI triggers the orchestration which calls up web services implemented using the Amazon virtual infrastructure?
Subscribe to:
Posts (Atom)