Doing some research on Content Management systems, I got a bit confused about the difference between Web content management systems and Enterprise Content Management systems.
This article is a good read to understand and appreciate the differences.
The lines between all content technology families are very blurry and hence the auhor suggests that we evaluate a product based on the scenario requirement.
For publishing company websites, intranet sites, a WCM may be a good solution. A ECM solution may be focussed towards a particular industry.
Thursday, December 27, 2007
Difference between a portal and a website
A lot of my friends ask me the difference between portals and web-sites. Typically an organization would have both - a company website and a portal. I found a good explanation here.
Portals typically have authentication and provides us information based on who we are. Personalisation and customization are the hallmarks of portals. So we require portals because:
Different roles require different information. Someone from grounds and buildings needs different info than the chair of computer science. (Customization) Different people with the same role work differently. (Personalization) Efficiency - people get directly to the info they need. (Work Flow) Customization insures they don't miss anything.
Portals typically have authentication and provides us information based on who we are. Personalisation and customization are the hallmarks of portals. So we require portals because:
Different roles require different information. Someone from grounds and buildings needs different info than the chair of computer science. (Customization) Different people with the same role work differently. (Personalization) Efficiency - people get directly to the info they need. (Work Flow) Customization insures they don't miss anything.
Labels:
Portals
Wednesday, December 12, 2007
ThreadPool in Java
Recently one of my friends was looking for a good Thread-pool implementation in Java and asked me for help. I had used Doug Lea's ThreadPool in the past and recommended it to him.
But browsing thru the web, I learned that JDK 1.5 has introduced a java.uti.concurrent.* package that contained a good ThreadPool implementation. Using it was also a breeze. Here are a few code snippets.
But browsing thru the web, I learned that JDK 1.5 has introduced a java.uti.concurrent.* package that contained a good ThreadPool implementation. Using it was also a breeze. Here are a few code snippets.
ExecutorService pool;The Task object is a Thread that implements the Runnable interface and has the run() method. The concurrent package also contains a lot of helper classes that can be used - for e.g. using a thread-safe collection, atomic varibles etc.
pool = Executors. newFixedThreadPool(3);
pool.execute(new Task( Task(“three”,3));
pool.execute(new Task( Task(“two” two”,2)); ,2));
pool.execute(new Task( Task(“five five”,5)); ,5));
pool.execute(new Task( Task(“six”,6);
pool.execute(new Task( Task(“one”,1);
pool.shutdown();
Labels:
ThreadPool
Friday, December 07, 2007
Websphere SOA Stack
A lot of people get confused between the different product offering by IBM in the Websphere space.The major products in the Websphere family are Websphere Application Server, Websphere ESB, Websphere Process Server and Websphere Message Broker.
Process Server is based on ESB and ESB is based on Application Server. Message Broker is termed as "Advanced ESB" by IBM and should be used when we have extensive heterogeneous infrastructures, including both standard and non-standards-based applications, protocols, and data formats.
So when to use what? Use Websphere ESB whenever most of the services you want to integrate are based on SOAP, XML standards. The Websphere ESB product can also be used as Websphere Application Server as it is built on the same core. Though Websphere Application Server can host simple services, Websphere ESB gives out of the box support for sophisticated mediation flows found in ESBs. We would need Websphere Process Server whenever we need to orchestrate simple services to create business services and host them.
Another technical difference is that Websphere ESB uses the JMS provider in WAS for messaging, whereas Message Broker uses Websphere MQ as the messaging engine. This is due to legacy reasons, I believe.
More information can be found here.The FAQ available at IBMs site also contains some good info.
Process Server is based on ESB and ESB is based on Application Server. Message Broker is termed as "Advanced ESB" by IBM and should be used when we have extensive heterogeneous infrastructures, including both standard and non-standards-based applications, protocols, and data formats.
So when to use what? Use Websphere ESB whenever most of the services you want to integrate are based on SOAP, XML standards. The Websphere ESB product can also be used as Websphere Application Server as it is built on the same core. Though Websphere Application Server can host simple services, Websphere ESB gives out of the box support for sophisticated mediation flows found in ESBs. We would need Websphere Process Server whenever we need to orchestrate simple services to create business services and host them.
Another technical difference is that Websphere ESB uses the JMS provider in WAS for messaging, whereas Message Broker uses Websphere MQ as the messaging engine. This is due to legacy reasons, I believe.
More information can be found here.The FAQ available at IBMs site also contains some good info.
Subscribe to:
Posts (Atom)