Thursday October 26, 2006
SAP Netweaver - Welcome to Java EE 5 Community
A colleague pointed to the SAP Developer Newsletter which states that Netweaver Application Server has been released covering entire set of Java EE 5 standards.
It is indeed a very welcome sign that Netweaver is already a Java EE 5 implementation. It goes to show that SAP sees significant value to be achieved with Java EE 5's developer-ease-of-use oriented specs enabling rapid development of enterprise applications.
That said, I wonder about the claim of being the first in the industry, given that GlassFish/Sun Java System Application Server 9 has been around since May 2006. As the GlassFish codebase is fundamentally the innards of Java EE 5 SDK and Sun Java System Application Server 9, I would tend to believe that Netweaver is ONE of the first. Anyways that's another discussion.
Welcome to the Java EE 5 world Netweaver! Here's a toast to a larger Java EE 5 community!
Cheers! :)
Posted at 06:51AM Oct 26, 2006 by Shreedhar Ganapathy in GlassFish | Comments[0]
Thursday October 19, 2006
Java EE SDK: Did you know?
This post is more of a clarification and useful pointer for Java EE 5 SDK, although this may have a little dated pieces of info.
We receive many questions on how performant is GlassFish, its relation to Java EE 5 SDK, and the Sun Java System Application Server version 9.
While the responses we give vary a bit depending on how narrowly scoped the questions are, the one thing that I feel needs to be communicated well is that the SPECJ numbers that were submitted and published for Sun Java System Application Server 9.0 back in May, '06 are exactly applicable to the Java EE 5 SDK! And to GlassFish v1 (b48 FCS build) ! That's because the code bases are exactly the same, the difference being that GlassFish is the open source project where the Java EE 5 SDK was being developed.
The SpecJ results page also lists the tuning parameters used.
This actually ends up being a little connect-the-dots challenge for learners and adopters alike so it is very useful to clarify here. I do hope more people read this post and benefit.
When you download the Java EE SDK, you are actually not just seeing a Reference Implementation of the Java EE Spec, but also getting a highly price performant application server.
Did you know you could use this application server for single instance deployment in your production system?
Here are some useful links :
Java EE 5 SDK Download
Tom Daly's Blog on SpecJ results
And an insightful blog written around the SpecJ submission time by our performance guru Scott Oaks (interesting comments as well)
GlassFish V2 builds
Enjoy!
Posted at 08:29AM Oct 19, 2006 by Shreedhar Ganapathy in GlassFish | Comments[0]
Tuesday October 10, 2006
Introduction to the GlassFish Domain and Domain Model
Much of the contents in this blog apply to GlassFish V2(with clustering support).
The GlassFish Project's application server comes with a very nice browser-based Administration console and a rich command line interface. Behind these easy-to-use interfaces lies the JMX compliant administration infrastructure that instruments management of these configurational entities and makes it possible to configure, operate and perform lifecycle operations on the server. At the heart of it all is the domain configuration model that provides the basis for the domain.xml configuration repository wherein lies the values applied to a given domain's configuration.
The concept of a domain in GlassFish can be related to an administrative area. Under a domain, one can have standalone instances (and with GlassFish v2, cluster(s) of instances). The administrator, thus, configures and manages all the operational aspects of the instances/clusters under a given domain through the Domain Administration Server (DAS). A domain can span multiple machines. Instances belonging to a domain can be located on multiple machines. Each machine's instances are started/stopped by a lightweight java process called the node-agent. The node-agent performs operations requested by the DAS such as starting or stopping one or more instances it is managing on a specific machine. Additionally, the node agent synchronizes configuration state between the DAS and the instances it manages.
A domain can have standalone instances and/or cluster(s) of instances. Java EE (J2EE) applications can be deployed to the domain, a specific instance, or a specific cluster. An already deployed application can be referenced by an instance or cluster by creating references to the application deployed on the domain. When as application is deployed to a specific instance, the application is placed in the domain level and an application-ref is created under the specific instance. Similarly, resources such as jdbc resources and related connection pools can be deployed/created at the domain level, a specific instance or a specific cluster. A resource that already exists can be used by other instances by creating a resource reference to the resource on the domain. When a resource is deployed to a particular instance, then the resource is created at the domain level and a resource-ref is created in the instance referencing the resource in the domain.
All of the above functionality is based on the foundations provided by our domain model. The domain model is specified in the domain dtd. The dtd specifies configuration artifacts and their related attributes and sub-elements, through a pseudo hierarchical and largely referential structure. At the top level is the domain element under which all configurational elements lie.
Below, these subelements are explained for more information.
The domain can comprise of a set of 'applications', 'resources', 'configs', 'servers', 'clusters', 'loadbalancers', 'lb-configs' and 'node-agents'. These are subelements of the top level root element 'domain'. In addition, special token value elements called 'system-property' and name-value pair elements called 'property' can be defined in the domain and at all sub levels for customization and extension.
The element 'configs' comprises of a set of 'config' subelements each of which is a set of configurational elements such as 'http-service', 'iiop-service', 'jms-service', etc.
A 'config' can be shared by one or more 'servers' through references('config-ref'). In other words, a particular configuration can be referenced by one or more instances but customized for specifics like port, etc through 'system-property' definitions under that particular instance.
The element 'node-agents' comprises of one or more 'node-agent' entities which are lightweight java processes living on specific machines that are part of the administrative domain as explained in the earlier paragraphs. The 'node-agent' manages the lifecycle of the instances that are installed on the machine it manages. The node agent plays an important role in synchronizing the configuration state from the domain administration server with the instances it manages.
The element 'servers' comprises of one or more sub-elements of type 'server' referring to an individual instance.
Each 'server' instance references a 'config' through the attribute 'config-ref'. By default, creating an instance results in a '<instance-name>-config' being created with auto selected ports representing that particular instance's configuration. This config could be shared as explained above by referencing in another instance.
The subelement 'applications' comprises a set of application types that are deployed to the particular domain or instance or cluster.
An application can be any of several recognized types, namely, j2ee-application, web-module, ejb-module, connector-module, appclient-module, lifecycle-module and mbean.
When an application is deployed in GlassFish, it is placed in the domain and made available to instances through 'application-ref'. In other words, instances ('server' elements) reference an application through the subelement 'application-ref'.
The subelement 'resources' comprises a set of resource types that go to support the application deployed. Several recognized types of resources are defined in the domain dtd most common of which are 'jdbc-resource', 'connector-resource', jdbc-connection-pool', 'connector-connection-pool', 'persistence-manager-factory-resource', 'resource-adapter-config', etc.
Resources are referenced by the instances through resource-refs. In other words, a particular 'server' would reference resources applicable to it by the subelement 'resource-ref'.
In a later blog, I will explain the loadbalancers and lb-configs elements.
Posted at 03:19PM Oct 10, 2006 by Shreedhar Ganapathy in GlassFish | Comments[1]
Java EE/J2EE Web Hosting: Whats your view as an Application Deployer?
In an earlier blog, I sent out a questionnaire to Hosting Providers to get their view about Java web hosting.
Although the blog did not get any direct comment responses, our engagement with the industry players is beginning to get us some of the responses.
In this blog, the focus is on user experience of customers of web hosting firms.
Given that the basic Java Web Hosting environments currently are shared hosting offerings, it would interesting to hear experiences of what works(ease of use) and what doesn't (pain points) with Java EE/J2EE based application server hosting providers.
Some questions come to mind:
For the application deployer:
Posted at 10:01AM Oct 10, 2006 by Shreedhar Ganapathy in GlassFish | Comments[0]