Write Once Run Everywhere...

Wednesday, July 5. 2006

Delivering real-life web-based application for the Internet is never easy. I used to believe that there would be someone called "deployer" while I'm writing so called "J2EE-compliant" code, I used to believe my application would eventually become highly portable. Portable means that I don't have to worry much about what database server, application server and even operating system my application will be running on, it is just strictly conforming to J2EE Specification and the spec promises me that as long as I follow it, my application will literally run everywhere. But in the past two weeks, what I was busy for wasn't the codes that I've written, it was those problems on OS, App server, DB server, Web server and even network. And I started not to dream on there would be a deployer role, because you as the developer will be the deployer, and you no longer can focus on the functionalities. The network administrator can't be bothered to check their network configuration after you've verified and proved there's nothing wrong at every aspects. In conclusion, although J2EE software runs everywhere, they aren't necessarily accessible everywhere.

Here is what specified in section 2.10.4 of J2EE 1.4 Platform Specification:

Deployer
The Deployer is responsible for deploying application clients, web applications, and Enterprise JavaBeans components into a specific operational environment. The Deployer uses tools supplied by the J2EE Product Provider to carry out deployment tasks. Deployment is typically a three-stage process:
1. During Installation the Deployer moves application media to the server, generates the additional container-specific classes and interfaces that enable the container to manage the application components at runtime, and installs application components, and additional classes and interfaces, into the appropriate J2EE containers.
2. During Configuration, external dependencies declared by the Application Component Provider are resolved and application assembly instructions defined by the Application Assembler are followed. For example, the Deployer is responsible for mapping security roles defined by the Application Assembler onto user groups and accounts that exist in the target operational environment.
3. Finally, the Deployer starts up Execution of the newly installed and configured application.

Posted by Steven Yong in computer at 11:02 | Comment (1) | Trackbacks (0)

...

Trackbacks

Trackback specific URI for this entry

No Trackbacks

Comments

Display comments as (Linear | Threaded)

Hmmm... Remember the "Segregation of Duties" business? The main purpose of implementing such a thing is to minimize security issues but it also made sure that no one person would have to play dual/triple roles in a team to develop the code, do db/server work and ultimately deploy the code out.

So, the deployment/production roll-out team was born. The team to help roll-out any patches of code that the development team came up with.

This means that this team would be experts in deployment, assuming that the code was packaged and settings specified correctly. This meant the development team didn't have to get their hands dirty with the code deployment.

Well, having such a team is an excellent idea but if the team is getting a lot of roll-out requests, that means that your deployment would still run into such problems.

So, besides having such a team, one would need a roll-out schedule which may be tied closely to SLAs so that deployment would run smoothly.

This is just my dua sen. Kekeke...

#1 Angie Tan (Homepage) on 2006-07-05 21:49 (Reply)

Add Comment