I ran across this page at the sun developer site. It has a very nice run down of various AJAX design strategies. (Ref: http://java.sun.com/developer/technicalArticles/J2EE/AJAX/DesignStrategies/?feed=JSC). This is a good read not just for Java developers but anyone. The principles in it apply toward the development of any architecture in any language implementing AJAX.
In reviewing this document I came across a project again that interested me and spent some time playing with it on our app server (glassfish this time). This is the Phobos project (Ref: https://phobos.dev.java.net/). It basically allows for the use of javascript (and later other scripting languages like hopefully Groovy) to be used on the server side. JSP and JSF use tags to embed Java code into pages that are rendered server side. Phobos extends this to javascript with the concept of "ejs" files which embed javascript into the page for server side rendering. The benefits to an AJAX implementation of javascript on both side are obvious. I do not know yet how well the server side javascript has access to the Java classes. Future integration with JMaki might also make future use of JMaki widgets in Phobos apps easy. How might one instance this into a remote domain though?
I am still curious if one could simply make a GET call to an app server that would render custom javascript in JSONP manner and return it to a script call of a page. In truth couldn't this be a servlet. A servlet responds to a GET call and can return just about anything. So one would seem to be able to make a servlet that returns JSONP. If the Phobos server could return JSON or JSONP as well as EJS rendered HTML that might open some interesting possibilities for remote access to widgets. This may be worth some investigation and comparison to some of our early GWT application experiments.
Tuesday, October 24, 2006
Sunday, October 15, 2006
Why Portals Must Die
A few days back I read a couple articles on some efforts by Google. These were an article on Googles Gadet effort and Google /BEA mash up talks.
While interesting in their own right and likely the kind of thing being done by Yahoo, Microsoft and others it got me to thinking about a mantra I have had going for some time:
Portals must DIE.
This is not to say portals themselves in concept are bad things. Only that they are often used or implemented poorly. I oversee a JSR-168 based portal myself and direct development of applications under that. The intent of portals is obvious. It provides a development group a unified display and authentication API set, among others, to work with. This helps to focus development skill and look and feel issues. A great thing compared to developing against a myriad of API's. Of course portal API's themselves don't talk to each other so little was gained for efforts outside the local enterprise (or enterprise group). In the Java camp the JSR-168 helps to focus efforts around a common portlet spec and that is great. Web services for remote portlets (WSRP) might have been a wonderful thing had I ever seen one example of it in the wild.
It is just that portals don't allow for dynamic mixing of content from various sites into my own space. I can't easily (yet) pull maps from Google, stock tickers from Yahoo, search interfaces from 3rd party databases sites and simply drop them into my page and have them work with authentication and styles (CSS) resident there. I want to be able to do this, so portals must die.
I believe that the common HTML DOM or a CDF derived instance is the common glue (as I spoke about in my OpenDoc posting). Combine this with remote AJAX applications that have some capacity for awareness of secure federated identity and we begin to see the a portlet concept in this environment. Secure "inter-AJAX portlet" communication could be done via a messaging middle-ware though I want to explore what Javascript allows in terms of intercommunication between various functions in a web page to see if that is possible. Look and feel issues could be addressed through systematic CSS utilization. In a manner similar to GWT.
To me the future portal is a simple DOM with portable code that can be pulled across the net to create its UI through local DOM object manipulation. Combine this with federated identity and CSS based styling for logging in and look and feel issues respectively. Let the whole thing talk to a services oriented architecture for logic execution. Hopefully the efforts of the W3C Rich Web Clients efforts will go well.
While interesting in their own right and likely the kind of thing being done by Yahoo, Microsoft and others it got me to thinking about a mantra I have had going for some time:
Portals must DIE.
This is not to say portals themselves in concept are bad things. Only that they are often used or implemented poorly. I oversee a JSR-168 based portal myself and direct development of applications under that. The intent of portals is obvious. It provides a development group a unified display and authentication API set, among others, to work with. This helps to focus development skill and look and feel issues. A great thing compared to developing against a myriad of API's. Of course portal API's themselves don't talk to each other so little was gained for efforts outside the local enterprise (or enterprise group). In the Java camp the JSR-168 helps to focus efforts around a common portlet spec and that is great. Web services for remote portlets (WSRP) might have been a wonderful thing had I ever seen one example of it in the wild.
It is just that portals don't allow for dynamic mixing of content from various sites into my own space. I can't easily (yet) pull maps from Google, stock tickers from Yahoo, search interfaces from 3rd party databases sites and simply drop them into my page and have them work with authentication and styles (CSS) resident there. I want to be able to do this, so portals must die.
I believe that the common HTML DOM or a CDF derived instance is the common glue (as I spoke about in my OpenDoc posting). Combine this with remote AJAX applications that have some capacity for awareness of secure federated identity and we begin to see the a portlet concept in this environment. Secure "inter-AJAX portlet" communication could be done via a messaging middle-ware though I want to explore what Javascript allows in terms of intercommunication between various functions in a web page to see if that is possible. Look and feel issues could be addressed through systematic CSS utilization. In a manner similar to GWT.
To me the future portal is a simple DOM with portable code that can be pulled across the net to create its UI through local DOM object manipulation. Combine this with federated identity and CSS based styling for logging in and look and feel issues respectively. Let the whole thing talk to a services oriented architecture for logic execution. Hopefully the efforts of the W3C Rich Web Clients efforts will go well.
.NET 3.0 an attack on standards?
So I read my first article on .Net 3.0 this morning over at informit.com. I then headed out to the Netfx3 site and did a little reading on the Communication, Presentation, Workflow and Cardspace foundation that are part of .Net 3.0.
Microsoft has obviously turned their back on standards like Web services, SVG, efforts like SAML, WS-Federation and the Liberty Alliance. I am sure they have done in this in the name of "user experience". However, this will be user experience only on Microsoft Windows.
Do I trust that things like WPF/E (the "Everywhere" cross platform version of WPF) will be coded to, made easy to code to, be used at all by many developers? Of course not, Microsoft has no interest in doing that. As a company they have fostered a culture based around ignoring standards and ignoring where the network is going. Even as powerful as they are, I have no doubt they will fail, but they have the potential to cause huge amounts of damage to peoples data along the way.
The core interconnecting standards of the net are under attack. Microsoft will use its influence, FUD and any other tactics to encourage this. Then they will wrap themselves in the flag of "competition is the cornerstone of capitalism" implying that they are the moral high ground holders.
It is obvious that Vista and .NET 3.0 will bring the most concerted effort yet by Microsoft to undermine Internet standards and cross platform environments.
Microsoft has obviously turned their back on standards like Web services, SVG, efforts like SAML, WS-Federation and the Liberty Alliance. I am sure they have done in this in the name of "user experience". However, this will be user experience only on Microsoft Windows.
Do I trust that things like WPF/E (the "Everywhere" cross platform version of WPF) will be coded to, made easy to code to, be used at all by many developers? Of course not, Microsoft has no interest in doing that. As a company they have fostered a culture based around ignoring standards and ignoring where the network is going. Even as powerful as they are, I have no doubt they will fail, but they have the potential to cause huge amounts of damage to peoples data along the way.
The core interconnecting standards of the net are under attack. Microsoft will use its influence, FUD and any other tactics to encourage this. Then they will wrap themselves in the flag of "competition is the cornerstone of capitalism" implying that they are the moral high ground holders.
It is obvious that Vista and .NET 3.0 will bring the most concerted effort yet by Microsoft to undermine Internet standards and cross platform environments.
Friday, October 06, 2006
CDF + Google gadgets = OpenDoc ?
So recently Google was noted for putting out "gadgets" that could be syndicated across the network (ref: Cnet ). The direct link to this being at: http://www.google.com/ig/directory?synd=open/.
This is basically javascript that you can instance in your own web page. There is nothing spectacular about this. However, Google has done a nice job of making it easy (easier) to do this. I am a big supporter of this syndication concept even though there are likely several issues still with this idea especially around security. (One Ref at Greg Murrays Blog)
Now combine this with something like the W3C CDF efforts. CDF allows a developer to place multiple XML formats into a common document.
The collision of all this reminds me of something from Apple from way back. Those that know me know I still haven't gotten over OpenDoc. systems could begin to However, CDF + remote web apps like AJAX Esqdevelop the kind of application that currently is still restricted to the true rich client applications. I don't know where web based applications will stop in terms of being reasonable approaches. Email, RSS aggregation, content management and many other types of communication based efforts have done very well on the browser platform. Lately word processing, spreadsheets and other attempts have started to crop up. I doubt we will see an AJAX based GIMP (or ever want one). For the most part, if I am working on data or creating data local like in a GIMP image there is no need to send that over a network. However, Writely has shown that even word processing can benefit from network aware ability, in its case in the form of real time collaborative editing of documents. (Apple Knowledge Navigator)
Imagine though a document with a SVG canvas being written to by an embedded ajax application communicating over XmlHttpProxy and then locally updating the SVG canvas through inter DOM communication. How about an OpenGL canvas? (Java 3d and applets is perhaps a bit of a digression for this posting, but not much).
I am encouraged and interested by where an open format, open standards based approach will go that mixes interactive applications with the DOM and graphics languages like SVG and perhaps even OpenGL.
This is basically javascript that you can instance in your own web page. There is nothing spectacular about this. However, Google has done a nice job of making it easy (easier) to do this. I am a big supporter of this syndication concept even though there are likely several issues still with this idea especially around security. (One Ref at Greg Murrays Blog)
Now combine this with something like the W3C CDF efforts. CDF allows a developer to place multiple XML formats into a common document.
The collision of all this reminds me of something from Apple from way back. Those that know me know I still haven't gotten over OpenDoc. systems could begin to However, CDF + remote web apps like AJAX Esqdevelop the kind of application that currently is still restricted to the true rich client applications. I don't know where web based applications will stop in terms of being reasonable approaches. Email, RSS aggregation, content management and many other types of communication based efforts have done very well on the browser platform. Lately word processing, spreadsheets and other attempts have started to crop up. I doubt we will see an AJAX based GIMP (or ever want one). For the most part, if I am working on data or creating data local like in a GIMP image there is no need to send that over a network. However, Writely has shown that even word processing can benefit from network aware ability, in its case in the form of real time collaborative editing of documents. (Apple Knowledge Navigator)
Imagine though a document with a SVG canvas being written to by an embedded ajax application communicating over XmlHttpProxy and then locally updating the SVG canvas through inter DOM communication. How about an OpenGL canvas? (Java 3d and applets is perhaps a bit of a digression for this posting, but not much).
I am encouraged and interested by where an open format, open standards based approach will go that mixes interactive applications with the DOM and graphics languages like SVG and perhaps even OpenGL.
Subscribe to:
Posts (Atom)