Win a copy of Microservices Testing (Live Project) this week in the Spring forum!

Rob Doughty

Greenhorn
+ Follow
since Jun 16, 2006
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rob Doughty

lol at Tyler..
How about YagerBombs

As previously mentioned know your design and part three falls into line.

Cheers
Hi Chris,
In response to your original question I posted this on the ranch last year when asked the difference between portlets and traditional servlets.

I think of a portal as the aggregater of a number of disparate applications
in a highly personalised manner. The critical component here is personalisation i.e. the ability to present only the relevant portlets based on a particular role, this is the key differentiater that portals possess that websites do not.

Many large organisations have at least two portals one being for internal staff (Intranet) and one for external facing customers.
How personalisation is performed depends on the scope of the portal and the nature of an organisations business e.g. Staff portal may have business, management, technical and sales roles where an external facing customer portal may be have roles based on what product customers have bought etc..
Applications or portlets are then displayed to the user based on their role(s). Portals also allow the user to customise their applications which although being a nice feature most probably will not provide the level of business benefit that personalisation does.

So what is better web apps(Servlets) or portlets ina portal? That depends on whether you already have a portal in place and whether you want to target your app to certain roles. It also depends on other things such as whether you are introducing process centric type applications (that co-operative portlets can assist with) and the granularity of the app you are building.

A lot of good new stuff is emerging with portals such as inbuilt eForms and process management. Add that to the other stuff such as SSO, WSRP, and a wealth of JSR-168 pre-written components, I would definitely move to a portal if your business has capacity for one.

Gartner sees portals as the flagstone of any organisations IT systems in the coming 5 years and IBM and Microsoft (via Sharepoint) are using them as their default presentation tier solution.

Rob
15 years ago

Does anyone have any experience in Sun Java Portal Server in production environment? How does it fare, comparing to BEA or IBM Portal Server?


Cant' talk for BEA but I have experience in both IBM and SUNs portal offerings. Personally I prefer IBM as I find it has more maturity in this market generally even though Sun have just announced their new portal server which has included stuff regarding blogging and wiki's.
Today for large enterprise scale portals I use IBM Websphere and find that the performance is good. We must bear in mind that most performance issues encountered in portals are generally to do with poor portlet application design and implememntation and not the vendors portal container itself.


Does the number of portlets that a portal server has, affect its performance greatly? Say if I have 10 portlets, will logging into the portal be significantly longer than if I have 5 portlets?



Depends how many portlets you have on a particular page and what they do..
If after you authenticate, your first page contains 10 portlets which are all accessing different datasources then you could be up for a performance hit especially when you try to scale the application up for 000's of users. Good portal site management and User Interface Design is key to addressing the needs of the business and ensuring that portals don't become stuffed full of unrelated applications to which no personalisation has been applied and no UCD. In answer to your specific question, yes 10 portlets will take longer than 5 generally but this also depends on caching and pooling strategies plus the exact nature of the function the portlet is performing e.g. if you had 10 portlets which just displayed HTML compared to 5 portlets that read datasources via EJB's or web services then the latter most probably would take longer.

Hope this helps

Rob

Delivering systems from the glass to the arse!
16 years ago
Hi,
The book market is pretty immature still for portal/portlet development.
If you cant find what you want from Amazon then you should still be able to find all the info your after on the web especially in places such as the Websphere Portal Zone (other resources link on main portal forum page). This info is still relevant even if your not a Websphere shop (lots of 168 and general stuff around development).

Ive got some other good resources which are on my machine at work. I'll post them when I go in Monday.

Cheers
Rob

"Delivering systems from the glass to the arse!"
[ June 17, 2006: Message edited by: Rob Doughty ]
16 years ago
Hi Vic,
I think of a portal as the aggregater of a number of disparate applications
in a highly personalised manner. The critical component here is personalisation i.e. the ability to present only the relevant portlets based on a particular role, this is the key differentiater that portals possess that websites do not.

Many large organisations have at least two portals one being for internal staff (Intranet) and one for external facing customers.
How personalisation is performed depends on the scope of the portal and the nature of an organisations business e.g. Staff portal may have business, management, technical and sales roles where an external facing customer portal may be have roles based on what product customers have bought etc..
Applications or portlets are then displayed to the user based on their role(s). Portals also allow the user to customise their applications which although being a nice feature most probably will not provide the level of business benefit that personalisation does.

Back to your question, should you develop as a web app or a portlet? That depends on whether you already have a portal in place and whether you want to target your app to certain roles. It also depends on other things such as whether you are introducing process centric type applications (that co-operative portlets can assist with) and the granularity of the app you are building.

A lot of good new stuff is emerging with portals such as inbuilt eForms and process management. Add that to the other stuff that Gobiraj mentioned plus SSO, WSRP, and a wealth of JSR-168 pre-written components, I would definately move to a portal if your business has capacity for one.

Gartner sees portals as the flagstone of any organisations IT systems in the coming 5 years.

Rob

Delivering systems from "the glass to the arse"!
[ June 17, 2006: Message edited by: Rob Doughty ]
16 years ago
Also if you notice in the applet code below the properties have to be stored in the MQEnvironment object. In fact the code below should provide you with all you need to connect to the server. Good luck




16 years ago
Wait up... ignore last post (just read your post properly)..
Have you set the following MQEnvironment properties correctly before trying the
MQQueueManager call....

MQEnvironment.hostname = "my.mqsvr.com"; // host to connect to
MQEnvironment.port = 1414; // port to connect to.
// If I don't set this,
// it defaults to 1414
// (the default WebSphere MQ port)
MQEnvironment.channel = "channel.name"; // the CASE-SENSITIVE
// name of the
// SVR CONN channel on
// the queue manager
MQQueueManager qMgr = new MQQueueManager("MYQMGR");

Rob
16 years ago
Hi,
Happy to help but have to ask the obvious questions first..
2059 normally means that the queue manager is not available.. can I assume that you have a) Created the queue manager using the crtmqm command (or whatever the command is these days) and b) started the queue manager (strmqm).

There also needs to be an mq listener running which I think was the runmqlsr -m <Qmgr> -p <port number> -t tcp (Im assuming your using TCP)
command.

Check these things and if your still having probs write back.

Rob
16 years ago
Evening,
Having done both 425 and 500 I would recommend 500 if you are already pretty au fait with j2ee and architecture in general. 500 delves into the core j2ee patterns and attempts to provides real world examples of their application. 425 I think could be covered by searching the Internet for a more generalist view of j2ee architecture and the primary concerns regarding solution architecture.

If your company has the loot go for both )

Rob