• Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

Comments (7)

1 Vladimir_Ivshin commented Permalink

Thanks! Very good post.

2 chendil commented Permalink

Excellent post! This has been a topic of interest recently when discussing application architecture and this post has provided some very valuable information. If you can provide some additional information from a SOA perspective it would be very helpful.

It appears like for applications for which there are well written and readily consumable services available, we can design a good SOA model using services and widgets?
From a capability perspective , I thought widgets would miss out on some of portal's built in functions like personalization but I saw that there is a widget portlet in the catalog that takes care of that. (Would WSRP work in this case?)
Are there any other capabilities that we ought to consider when looking at the portal framework as a whole (server side preferences store, SSO etc) that may not be available with widgets?
I am guessing once the widget spec gets approved, a more light weight applications will be designed using services and widget, so that java developers can just work on the server side (they were never great with the UI stuff anyways) and web designers/programmers can create widgets to their heart's content !

3 boezeman commented Permalink

Hey CK, Yes you can do a good SOA model with widgets and services, since you really don't want to do the separation between model and views with this model.

Most features are available, for example, iwidgets can add state into the url state, so you get bookmarking, back, forward button, and so forth, shared settings, concrete settings/preferences, etc... Some things you can't do is per user personalization, isn't supported yet, admin portlet for managing the installed widgets, policies, etc..
Not really on your framework question, preferences for a widget are stored server sided, SSO works the same, access control works the same, other than individual widgets aren't a managed resource in our access control, since they are accessed via url, so to protect widget access, someone should use a normal authorization proxy, just like you do for normal web content.
One other thing that Rob mentioned was the chattiness of ajax and web 2 technologies like widgets. As a result of this, you can get really effective usages in an http cache, like IBM's Edge. Since each request can be cached, and the services can be cached. So over a low latency line you can get exceptional performance, but over a latency line, like between US and China as an example, that chattiness can dramatically lower response time. That is why in Portal Server 6.1.5 and Mashup Center 2.0 we added multi-part support. Basically the framework will load up the multiple requests into a single request. The server will then merge all those responses into a single response that is returned over the wire. Then the client side code ripes it apart into the individual resources. This will give you the best performance for these latency cases.

4 pramid commented Permalink

Good article.. Nailed the point..

5 melbeltagy commented Permalink

great post. i've been looking around for quite sometime for such explanation.

6 rshiggaon commented Permalink

Great Article.

7 surendravegesna commented Permalink

Excellent post! Thanks!!

Add a Comment Add a Comment