This post originated from an RSS feed registered with Java Buzz
by Wilfred Springer.
Original Post: Portlets vs. Social Container
Feed Title: Distributed Reflections of the Third Kind
Feed URL: http://blog.flotsam.nl/feeds/posts/default/-/Java
Feed Description: Anything coming to my mind having to do with Java
Portals are... peculiar. I am a little conflicted about them though. First, what I like about them. I think portals in way are the SOA dream come true. Basically, it's all about composition of existing smaller services. Admittedly, the level of integration is not very intimate, but that's actually a good thing. Think of portlets as objects that have their own lifecycle and state. And instead of exposing all of their state to the rest of the world - which would be very MVC, but very not OO, because it breaks the encapsulation, they basically control themselves how humans interact with them. Very much like the visual proxy ideas laid out in this article 10 years ago.
So yes, I kind a like them. Ultimately, I don't believe in partitioning systems horizontally. I believe in partitioning systems vertically. Have systems that are capable of doing some particular in a very decent way, and offering several interfaces and type of endpoints to interact with it.
But at the same time, I don't really like portals. And that largely has to do with the fact that portals do the composition on the server, and you wonder why. Especially in today's world, where many things are essentially getting mashed up on the server. It just doesn't scale very nice. (Well, I can tell you why, but you have to promise not to tell anyone else... It's a conspiracy. Hardware vendors make you think you need it, and then it turns out it requires a lot of processing power.)
Now, on the plus side, I think portals probably paved the way for client side social container technology. And it seems to me that if you happen to have an investment in portal technology, it should eventually not be all that hard to turn that into a social container type of solution, in which the composition is done where it needs to be done: on the client. (And then we can also forget about edge side includes and all of that. You ain't gonna need it.) Once it's on the client, it will scale just fine.
I had a hunch that there would be something out there that would leverage the portlet programming model to move the composition to the client. And it turns out, there is something out there. It's called Light Portal, and it's doing exactly what you might expect. Have AJAX portlet type of components call into JSR 168 portlets. Sweet. I am not sure if it would be as robust as you would like, but you got to at least appreciate the attempt.
Previous Topic
