Friday January 26, 2007
Differences between GlassFish v1 and GlassFish v2
I frequently see this search term "Differences between GlassFish v1 and GlassFish v2" appear in Google searches showing up on my Statcounter account referrer link. So I guess its a good topic to blog about.
GlassFish v1 was the first release of the Java EE 5 application server from the GlassFish Project at Java.net. This release had featured a application server environment where one could create a domain with one appserver instance in it that was Java EE 5 compatible and included a good looking administration console in addition to performance enablers such as the nio-based Grizzly http connector framework. This was released around JavaOne in 2006. At the time, the community asked for more given the positive responses we received on v1. The community asked about our roadmap and insisted that clustering capabilities were a dire need among other things. We listened to the community and came up with the plan for GlassFish v2. In the meantime, we have also released update releases to GlassFish v1 i.e ur1 and ur1 p01
GlassFish v2 development is in progress and has reached Milestone 4 ( the one we use for the beta release). Primarily, the v2 release offers ability to create a domain with many standalone instances and clusters of instances. In essence you could have one or more domains, each with its own appserver instances some or all of which may be part of one or more clusters (well, an instance can only be part of one cluster, but you can have multiple clusters each with its own instances). In addition, there is the HA component which provides in-memory session state persistence between instances in a cluster. Numerous improvements to the base v1 code have been made to make it more performant. We have dynamic clustering coming in from Shoal that enables components in a clustered instance, and the administrator to get clustered instance status. V2 also contains dynamic IIOP endpoints failover loadbalancer.
The other notable difference from v1 is that you can run GlassFish v2 in various profiles, namely, Developer Profile, Cluster Profile, or Enterprise profile. A domain can be created with a specific profile name. With Developer profile you get the single instance domain that is well suited for development mode. The difference between cluster profile and enterprise profile is sort of subtle. The enterprise profile carries almost all of what cluster profile offers except that it is aimed at large scale deployments in enterprises. The cluster profile basically allows you to create within your domain, not only non-clustered standalone instances but also clusters with instances attached to it with homogeneous configuration. In other words, one can have multiple clusters and have sets of instances within each cluster with homogeneous configuration. The instances can be spread over many machines and the lifecycle of these instances is managed by an entity called a Node Agent which sits on each machine and responds to the domain administrative server's instructions to stop or start an instance on a particular machine. One can deploy in a single action, applications to a target cluster and all instances in that cluster will have the application deployed along with corresponding resources.
The differences between these profiles are covered well in this One Pager document section 4.1.2
There is more as per this blog in the Aquarium :
• Update Center
• WS Interoperability (WSIT) Functionality
• JBI Support
• In-memory replication.
• Dynamic clustering from Shoal.
• Optimized ORB
• Startup Architecture improvements.
• Improved Web Tier: Comet,
virtual hosting, in memory JSP compilation.
• JSF used in the Admin GUI.
Well, you get the idea on how much progress has been achieved from v1 last year to v2 this year.
Send in comments if you would like to hear more details and I will go dig around to get you the necessary information.
Also send in your successful deployment stories on GlassFish to the Stories blog
Posted at 03:42PM Jan 26, 2007 by Shreedhar Ganapathy in GlassFish | Comments[2]
Thursday January 25, 2007
GlassFish v2 Milestone 4 includes Shoal
GlassFish v2 has reached its Milestone 4 which is the Hard Code Freeze for the Beta. During this time, we addressed many bugs and features in Shoal and delivered a stable version to GlassFish.
Shoal gets autoenabled when a cluster is created (Of course, one can disable it by setting the cluster's heartbeat-enabled attribute to false). When a cluster is created, the Domain Admin Server creates an instance of this cluster as a group and joins it as a Spectator member. So for each cluster, the Domain Admin Server participates as a Spectator member.
After instances are added to cluster and as these are started, each instance in the cluster participates in this Shoal cluster and can then communicate with each other and monitor each other's state. When an instance or cluster is shutdown administratively, Shoal notifies all instances about this impending shutdown allowing Shoal GMS client components within each instance to do appropriate pre-shutdown operations. Similarly, when an instance fails, Shoal notifies client components in all surviving instances about this failure and if needed to notify the need to perform any recovery operations. Details of these features are available at the Shoal site.
Shoal is used in GlassFish for group membership monitoring and for value add features like automated transaction recovery performed by a delegate instance, self management wherein administrator can define remedial actions based on occurence of events including group events that Shoal notifies. The IIOP Load Balancer uses Shoal for dynamically generating failover IIOP end points as cluster shape changes and provides this to IIOP clients out-of-band so that these have updated failover targets. The In-Memory Replication component uses Shoal to confirm failures and to determine when a member has joined or gracefully left the group.
By GlassFish FCS, we will make Shoal stable enough to be released on its own as a standalone infrastructural component that other projects/products can use.
Shoal presents some interesting product use cases.
An in-memory cache on the lines of memcached should be a little more work and is a good possibility. A Shoal-based compute grid is another possibility with relatively small incremental code to be written to make that happen. I can also think of a Derby cluster using Shoal as the underlying clustering and replication mechanism. Once you think of Derby, any other product could be applied here. For instance, a directory server cluster, a web server cluster, a message queue cluster, etc. Another possibility is that Web-only apps could directly use Shoal to cache states among instances of web containers. So you see, the possibilities are endless and is only limited by imagination. 
Posted at 10:28PM Jan 25, 2007 by Shreedhar Ganapathy in Shoal | Comments[5]
This is a personal weblog, I do not speak for my employer.
