Today's Portals "Inadequate" for Web Services?
Web Services analysts Zapthink (I must confess that I was not aware about any such research agency before finding this article on Internet) predicts that today's web based portals will prove "wholly inadequate" to meet the needs of emerging standards based, loosely coupled, distributed applications. The solution, Zapthink's research says, will come from "rich clients" that will allow portal users to customize their UIs and even their workflow and application access.
I have not seen the actual research. I have seen an article that can be found at "Integration Developers News." On first glance it sounds impressive to me. In fact, in the past even I thought on the same lines and found that existing browsers are too thin to be the pal of portals. But my conclusion was different from Zapthink's. In my opinion with the time and after emergence of portals, the browser will grow a little richer and will be able to understand portals. Even the DOM will be able to work in conjunction server side technologies. So my conclusion was that the browsers will grow more to catch portals.
But the Zapthink has drawn some different conclusions. They are talking about rich clients other than browsers. It is the same old Microsoft vs. all debate. Microsoft want to push web technologies on client-side to take advantage of it's OS strength i.e. Windows whereas other vendors (read portals vendors) want to push it to the server side where they are strong. Zapthink's research seems nothing but an extension of Microsoft's good-old philosophy. Another point to note is the title i.e. "Today's Portals Inadequate for Web Services." Where are web services in this picture? and what web services has to do with the rich clients? To me the research looks more pushing up Microsoft's philosophy by adding the word web services to it …. new packaging of some old ideas.
They have mentioned following reasons why portals developers need rich clients. I am giving my opinion -
1. Loosely couple presentation from application logic
I agree
2. Provide advanced capabilities for user interaction
Again, I agree. The future applications will be more aware of the features available with the browser 'rich client'.
3. Integrate local and remote sources of data and business logic
Here I disagree. The data and business logic will remain on the server side. I don't see any possibility of integration of data and business logic with rich client using SOA. Rather I see more integration happening at server side using technologies like WSRP. (Probably it is the reason why Microsoft is reluctant to implement WSRP in its products though a part of committee.)
4. Provide greater intelligence and efficiency in distributed computing
Though request/ response it not the best way to communicate, but with advent of little richer browsers, it will become the better communication method. The available of cost effective and high bandwidth will help in retaining the request/ response method of communication.
5. Enable online and offline modes of usage
Forget about offline. Nearly all future applications will be written keeping connectivity in mind. I don't see many offline applications happening in future.
I have not seen the actual research. I have seen an article that can be found at "Integration Developers News." On first glance it sounds impressive to me. In fact, in the past even I thought on the same lines and found that existing browsers are too thin to be the pal of portals. But my conclusion was different from Zapthink's. In my opinion with the time and after emergence of portals, the browser will grow a little richer and will be able to understand portals. Even the DOM will be able to work in conjunction server side technologies. So my conclusion was that the browsers will grow more to catch portals.
But the Zapthink has drawn some different conclusions. They are talking about rich clients other than browsers. It is the same old Microsoft vs. all debate. Microsoft want to push web technologies on client-side to take advantage of it's OS strength i.e. Windows whereas other vendors (read portals vendors) want to push it to the server side where they are strong. Zapthink's research seems nothing but an extension of Microsoft's good-old philosophy. Another point to note is the title i.e. "Today's Portals Inadequate for Web Services." Where are web services in this picture? and what web services has to do with the rich clients? To me the research looks more pushing up Microsoft's philosophy by adding the word web services to it …. new packaging of some old ideas.
They have mentioned following reasons why portals developers need rich clients. I am giving my opinion -
1. Loosely couple presentation from application logic
I agree
2. Provide advanced capabilities for user interaction
Again, I agree. The future applications will be more aware of the features available with the browser 'rich client'.
3. Integrate local and remote sources of data and business logic
Here I disagree. The data and business logic will remain on the server side. I don't see any possibility of integration of data and business logic with rich client using SOA. Rather I see more integration happening at server side using technologies like WSRP. (Probably it is the reason why Microsoft is reluctant to implement WSRP in its products though a part of committee.)
4. Provide greater intelligence and efficiency in distributed computing
Though request/ response it not the best way to communicate, but with advent of little richer browsers, it will become the better communication method. The available of cost effective and high bandwidth will help in retaining the request/ response method of communication.
5. Enable online and offline modes of usage
Forget about offline. Nearly all future applications will be written keeping connectivity in mind. I don't see many offline applications happening in future.
Hi Punit,
ReplyDeleteIt is difficult to discuss these ideas without referring to a specific time span. To get insight into new technologies and their time span take a look at:
Hype Cycle for the Portal Ecosystem, 2004