Frameworks frameworks...too many

Check this out ...one more new framework...Nevertheless nice comparison of different new and old frameworks. Below is the presentation

How to choose a web framework and be surprised

View more presentations from Jose María Arranz.

Will do a poc soon and share my findings of http://itsnat.sourceforge.net/

Are we going back? (Client Server == AJAX )

One of the fundamental rule in designing software systems is always to divorce presentation logic, business logic and data access logic,

• so that each tier can vary withstand modifications of other tiers
• so that different teams can focus on separate layer and specialize in that
• so that building complex systems can be easier etc etc

Many books have been written emphasizing the advantages of this pattern.
Coupling any of these layers would take us back to ancient Single tier or Client Server architectures.

Why am I telling all this?

One of the projects which I'm currently working on is a Web 2.0 application. This app helps users to do financial analysis by pulling large amounts of data  from the database and plotting charts. And there are no page refreshes and every request is a XHR request (nice :) ).
jQuery is the Ajax framework & jQPlot is the charting framework.

One of the interesting side effects that I'm observing building this Ajax Web 2.0 app is more and more "business logic" is getting into the front end javascript files(and btw the other side effect is - Ajax apps are not search engine friendly - not "crawl-able").

What could this mean:

• sooner or later javascripts files grow larger and soon will end up in an un-manageable mess
• anything running on the browser is kind of "open source" available to entire world - as these files get downloaded on the browser cache. Anybody with little effort can look at the business logic
• bad user experience because of browser freeze - This is basically a counter effect. The primary reason why somebody would take ajax approach is to give a better user experience i.e. if the code runs in the browser then it it faster. But these days, an average user will have min 6 to 7 browser windows open (plus mail client (lotus or outlook), some office documents, pdf readers , IDEs etc) and if the browser starts taking your laptops cpu cycles looping some java-script code and rendering and re-drawing html --then a browser freeze is guaranteed (HTML5 promises to solve this)
  

Its kind of going backwards in time where all the presentation logic, business logic is getting mixed.
The browser for Ajax apps are kind of acting as a thick client, downloading data from the server (usually as JSON content) and manipulating most of it on the client side. The app server is just acting as a content provider.


Why this could be happening?

One word. Performance. Users are impatient and response > 3 secs is not acceptable.
The primary reason the business logic ends up on the client side is to limit the number of requests to the web server.
Network calls are very expensive (one to the web server and another from web server to the database server to get the actual content). So naturally developers would take easy way out, bypass these network calls, get chunks of data on the browser and manipulate it.

How to avoid this ?

• Avoid putting business logic putting on the client side
• Use java script wisely to manipulate the DOM
• Use good server side caching solution
• Tune your SQL queries
• Design a good UI
• Anticipate user clicks, fire the request at background and have the data cached on the server side
• Keep clearing the server side cache

just my thoughts...

Back to Square one - HTML5

Wow! That's what I uttered when I watched one of the videos on HTML5 on Google I/O 2010.

I started my career coding HTML 4.0 way back in 2000. The web was hot at that time (btw it has become hotter now :)). HTML seemed easy. You write tags and see the changes, no wait time,no fun ;) .
Java was the hot buzz word. Every other person was crazy about learning Java. Applets were kind of geek thing. It was kind of prestige issue to learn Java. Your fellow buddies silently respected you when you showed your new Applet or Servlet.

During my early months of job, I started feeling HTML is only for greenhorns, there wasn't much fun in doing any HTML or say for that matter Javascript. One reason was that the tools used for (D)HTML were spitting too much of code. You don't understand any thing in that. There was not one correct way of doing things. Cross browser or say for that making code compatible for matter different versions of IE was a nightmare.

I slowly forgot HTML.

But now, With new HTML 5.0 killer features, nobody can ignore it. It has the capacity to completely replace these Rich Internet Apps be it Flash, Silverlight etc.

It would soon become a standard and entirely change how we write web applications.
Javascript would be new language of the Internet.

Some of the features are just amazing:
1. Offline storage database
2. Drag and Drop
3. Canvas
4. Rich Media tags
& the list goes on..

Check this out:
Demo of HTML5 is in HTML5 How cool is that !!.

And this video on youtube:

Java EE6 CDI

Choices ..choices. Now Java Development without Spring.
Its making harder for Java EE Developers & Architects. Now they have to un-learn and learn new stuff.
Jokes apart -- Java EE 6 with CDI indeed seems to simplify things for the programmer. Less code more work backed by Oracle (i.e. Sun) & Tomcat support coming soon. Finally Spring taught a lesson to Java & Java has learnt it well.

Let me head to the book shop to pick up the book - "Java Development without Spring" By Johan :)

I don't know what my next client would want. Spring or No Spring. Do I have a choice?

Java EE6 CDI

View more presentations from johaneltes.

Bob Martin on Software Craftmanship

After listening to this marvelous session, if any body related to Software development, who writes production code, does not write a unit test (i.e. automated test) for that production code, then he is not a software "professional" --> period.

Everything falls in place, like good design, good architecture when we have a set of test suite. It adds immense confidence to keep improving the software without any "fear" of breaking it. Good test suite == good software.

Craftsmanship is nothing but professional commitment of an individual to deliver "best" software to their client or the employer.

No finger-pointing, no blame-game, no wasting time how this mess got created - just get your hands dirty and start fixing.

Thanks Bob for the lesson.

Advice to myself - Choosing Work

There are three things to look out in any new endeavor that I undertake.

These are not in any particular order:

1. Does it give me money
2. Does it give me fame
3. Does it give joy

Of course the last one is the most important one. Often many try to buy the last one by the first one, which is mostly superficial.

If all three come on your way then nothing like it...

Reading Code...Software Archeology - 2

In the almost a decade of IT experience I can safely conclude that I have read more code than have written.
This is true for many of us. In college we spend most of the time writing code and the moment we are out in the industry , we join a project team and put  in a situation where the majority of the time we spend in reading (others) code.
This is always true at-least in Indian market where the engineers work on the outsource project.

Few other reasons:
1. Most of the companies have a big agenda of "Re-use".  They always emphasize and encourage teams to create a librabry re-usable components/assets. Often they track this by metrics on how much your team has shared and how you have reduced cost by using the already available components.
2. There are umpteen number of opensource libraries. Most of them lack documentation. The only to make it work is to open the source and digest it.
3. 80% of the projects that get outsourced are maintenance and enhancement which lack up to-date documentation.
4. Legacy projects
etc

Look at this way,we almost spend about 60-80% of our time in the industry reading code and 15-35% writing code and remaining on other activities but almost all the tools, processes, standards, best practices that are available on the web are for writing and creating new systems but very minimal to read & understand existing code.

What is Software Archeology?

I will leave the veterans and experts of the industry to shed more light on this:
Digging code: Software archaeology - Good overview
Grady Booch on Software Archeology
Listen to Dave Thomas on SE Radio
Article on Java Dev Journal

In my next post, I will share my experiences of diagnosing and understanding a complex Java EE app using some of the tools that I stumbled upon on the web.

Reading Code...Software Archeology - 1

Finally things have come to an end..and there is some relief of completing this particular project.
This project had some history (of-course not a good one) of being slow, complex, no-documentation, open bugs etc. My luck, I landed in this one. But there is always some scope to learn..be a new project or old project.

Background:
This project was a IBM WAS portal application (one big portlet) built using legacy struts1.1 framework and accessing a set of remotely deployed ejb services. The ejb services project (was configured with 6 datasources) acted as a service provider and the portal project as the consumer of services.

Size wise, the portal app is having 6 very big struts 1.1 action classes (where all the UI logic resides), 11 packages & about 20 KLOC. When I say very big, I mean very big about 5KLOC in each action class.

The goals of this project was to de-portalize i.e. move away from the portal run time - i.e. to save some money on portal licenses & merge the complex ejb services project with this one. This is primarily to strip of ejb layer so that performance is improved and all its services are local. Everything is at one place and so it is more maintainable.
btw, earlier I wanted to use the word - re-architecting but found out that there is no existing architecture in the current project to do that. So instead used another jargon - de-portalizing.. :)

But what this has all got to do with the Topic of this blog..Reading Code...Software Archeology.

You might have guessed based on the above background where I'm heading to..

Back…

Downloaded Windows Live Writer..Publishing a sample blog…Hope, this will motivate me to blogging consistently.

Finally some relief and a sense of satisfaction. Txn Engine App got saw the day of the light, it got deployed on production on Amazon EC2 yesterday.

Three months of intense code churning activity has come to an end. No more stand-up meetings :)

Txn Engine is a batch processing application built on Spring Batch. It is deployed on Amazon Ec2 large instance.

Folks of Spring Batch have done a very good job (still doing a it).The documentation on their site is good, sample apps cover most of the needed business and enterprise batch use-cases plus the forum is active and you get quick clarifications and support. Waiting for the release of the web-framework to monitor the batch metadata tables.

LinkedIn - A Professional Network built with Java Technologies and Agile Practices

View more Microsoft Word documents from linkedin.

Tracking Requirements using Annotations for Java Projects

Tracking requirement has been always a major challenge in big projects. Requirement Traceability Matrix (RTM) document is never up-to-date. The team looses interest and lacks the rigor to maintain RTM for various reasons.

In this article we will see how to achieve a developer friendly way of tracking requirements directly in the Java source code with the “Annotations”; a new feature introduced in JDK 5.0.

Introduction

Annotations (or Metadata) were formally introduced as part of JSR-175, approved in Sept 2004 into Java 5.0 (JDK 1.5 version).

Annotations were always present since earlier version of JDK but in ad-hoc forms like @deprecated javadoc tag, transient modifier (indicating that a field should be ignored by the serialization subsystem) etc. JSR-175 standardized it and JDK 5.0 gave the developers the power and flexibility to define custom annotations.

Also Annotations gained importance because of its ability to generate boilerplate code for many frameworks. They hugely became popular because of the technical requirements imposed by some heavy weight runtime environments like EJB 2.1, JAX-RPC etc. Many of the artifacts like interface, deployment descriptors, implementation classes and other related files are easily generated by the annotation processor tool by inspecting the “decorated” source code elements

What are annotations?

In simple language, annotations are “metadata” added directly to the source code.

This metadata can be retained in the class files generated by the java compiler and are reflective in nature. Classes, methods, fields, packages can be annotated.

Annotations have a special syntax and rules of its own. Look into the resources section for some links related to tutorials, articles on the web

What are annotations?

In simple language, annotations are “metadata” added directly to the source code.

This metadata can be retained in the class files generated by the java compiler and are reflective in nature. Classes, methods, fields, packages can be annotated.

Annotations have a special syntax and rules of its own. Look into the resources section for some links related to tutorials, articles on the web.

Hypothetical Example:

Let’s assume that your company is maintaining a large enterprise application for a client. The application has been delivered a year back and the application is currently in the maintenance phase. The usual maintenance activities are bug fixing, back up activities.

The original developers have been rotated and the majority of maintenance team is relatively new, having a rudimentary knowledge on the application.

Now after a year or so, the client plans to come up with a next version of the application with a set of new features based on the market feedback, users inputs etc. The client comes up with about 80 – 90 new requirements and requests for a proposal to accommodate these new features in the version 2 of the application.

The version 1 requirements were in a separate word document - outdated. The bug fixes and minor enhancements requirements which had come later were scattered in the team’s mail box, bug tracking tool. The requirements traceability matrix was in a very poor state, pretty outdated. The team lacked the rigor to update this on need basis, always postponing it. The end result: RTM document became so outdated that any wanting developer lacked the motivation to do it.

The Project Leader (who is again new, for whatever reasons) has to respond back to the client with the proposal for these new set of requirements. He and his team are stuck and have no clue where to start, how to find which requirement impacts which part of the code.

The above is a little dramatized example, but I have seen such cases.

Although the team consists of sharp developers, they do not show the same rigor in updating the RTM document as they show the passion for coding.

How do the annotations help?

It is the developer friendly approach of maintaining the requirements as “metadata” as part of the source code. The code review process can ensure this.

Tracking requirements using annotations directly in the code helps:

1. Requirements are always in the current state

2. No need of RTM

3. Reports on the requirements can be generated on the current source code

4. Impact analysis / estimation of new features and tasks would be easier

5. No need to invest, manage, train in an additional commercial tool

6. One place maintenance

Moving on

Firstly, let us define an annotation, which will be used by end users i.e. developers.

Annotations are very similar to Java interface definitions. Notice the @ symbol before the interface keyword. In the above code snippet, we have defined an annotation by name Requirement (or it could be named as Feature, in agile lingo). Most of the properties defined above are self explanatory. Basically the properties defined above are to track which use case, project, module does this requirement belong, whether it is a high priority or a functional kind of requirement etc.

Also if you observe the above code, our Requirement annotation definition has also been annotated with annotations - @Target which is available by default in java.lang package. @Target tells us that Requirement annotation can be used only for classes, methods, constructors, packages and instance fields

Example in use

Let us define a simple Java interface & apply the Requirement annotation.

The above code snippet is pretty much self explanatory; shows how the code would look when Requirement annotation is applied to a Java interface WorkDaysCalendarCalc with two service methods: isWorkDay() & getWorkDayNumberInCurrentYear(). Also notice that some of the properties like projectName, type of Requirement annotation etc have default values. These need not be declared.

Annotation Processing

The next step would be to process these annotations. Running the annotations is not done with the usual java command, but with a tool called apt (annotation processing tool) introduced in Java SE 5.0.

Java SE 6 has this capability built it in the compiler, thanks to JSR-269.

Let’s see some Java 6.0 code of our Requirement annotation processor

Annotation processors in Java 6.0 have to extend AbstractProcessor of javax.annotation.processing package and override the process method.

The above RequirementAnnotProcessor processes only those Java files which use Requirement annotation. This restriction has been put by @SupportedAnnotationTypes("com.req.annot.Requirement").

javac compiler calls the process method of our RequirementAnnotProcessor whenever it encounters any Java file which uses or imports com.req.annot.Requirement annotation.

The first step would be to compile out RequirementAnnotProcessor.java.

The below figure should give an idea on the package structure.

Open a command prompt, and navigate to the package com.req.annot and compile RequirementAnnotProcessor.java. Please see the below image for more details.

Output

The next step after compiling the Annotation processor would be to process the Java file, WorkDaysCalendarCalc.java, which uses our Requirement annotation.

Navigate to the src folder and issue the following command:

D:\Basav\eclipseWorkspace\TestReq\src>javac -processor com.req.annot.RequirementAnnotProcessor com\test\service\WorkDaysC

alendarCalc.java

Here -processor switch tells javac to use annotation processor before compiling the code

You should see the following output:

-------------------

Received Annotations :[com.req.annot.Requirement]

Processing annotation :com.req.annot.Requirement

Elements for that :[com.test.service.WorkDaysCalendarCalc, isWorkDay(java.lang.String,java.util.Date), getWorkDayNumberIn

CurrentYear(java.lang.String,java.util.Date)]

-------------------

Received Annotations :[]

The process method of RequirementAnnotProcessor is called for each Java file containing Requirement annotation, in out case WorkDaysCalendarCalc and prints the elements (classes, methods etc) which use the Requirement annotation.

The process method is the worker bee of any annotation processor. In the above rudimentary example, the process is just printing all the elements which declare out Requirement annotation. This method would be actually enhanced to generate an xml file for e.g. something like the below structure. This is just an indication; the output report can be customized based on the project needs.

Conclusion

To sum up, this is an attempt to explore the possibility of tracking requirements and keeping the requirements as up-to-date as possible using annotations. From past couple of years agile fever is catching up. Lots of Java projects are heading the agile way, with shorter iterations, less up front design and diving directly into the code with small set of initial requirements, taking baby steps. This would definitely add a step to the developers but the returns would be huge.

Thanks for reading.

References

http://java.sun.com/docs/books/tutorial/java/javaOO/annotations.html

http://java.sun.com/j2se/1.5.0/docs/guide/language/annotations.html

http://www.jcp.org/en/jsr/detail?id=175

http://www.jcp.org/en/jsr/detail?id=269

Approach to developing Resource Adapters using J2CA

One of my friend, Karthik had asked me to write something about J2EE Connector Architecture (JCA). I have a year or so experience in JCA, was part of team developing RDBMS Adapter for Weblogic Platform.
The below section is part of my write-up given to my boss on JCA. The first part is on Overview of JCA, which I did not think was that important/cruicial to post it here. You can find lot of primers on J2CA. The seeker seeks it.
The second part of the write-up is bascially the title of this blog, which is based on my limited experience and knowledge.
Here it goes...

Approach to developing Resource Adapters using J2CA

JCA is an interface definition. There are no specific guidelines or approaches/reference implementations provided by SUN in creating resource adapters.

The approaches broadly fall under two categories:

• Non-Framework based approach
• Framework based approach

Before we decide on one of the above approaches, it is recommended to have a technology proof of concept (POC) implementing a basic adapter to connect to each type of EIS to mitigate any technical risks as early as possible.This is important as we are integrating J2EE systems with disparate Legacy /EIS systems. This technology POC single out & eliminate main elements of risk. The goal can be to implement a single requirement be it a connection related or transaction related using the technology that we would like to prove

The below outline of development approach for building resource adapters apply

• Research EIS requirements

Identify the required EIS and appropriate services that need to be exposed
Identify the expensive Connection object
Implement a POC
Identity security needs
Identity type of transaction (XA-Txn, Local Txn or No Txn)

• Development environment configuration

Set up file/directory structureSet up build proces

• Implement Service provider interface

Implement the interfaces that comprise the SPI, at least the following three interfaces:
ManagedConnectionFactory, which supports connection pooling by providing methods for matching and creating a ManagedConnection instance.
ManagedConnection, which represents a physical connection to the underlying EIS
ManagedConnectionMetaData, which provides information about the underlying EIS instance associated with a ManagedConnection instance

• Implement Client Connection Interface (optional)

Implement the interfaces that comprise the CCI including the Connection interface and the Interaction interface

• Package the Adapter

Package the adapter into rar file.
Deploy the Adapter on the target application server platform

• Test Adapter

Test the adapter for functionality & performance on desired platforms/EIS versions

• Release the adapter

Non-Framework based approach

This approach is primarily useful if we are implementing only one of type of Resource adapter. Here everything needs to implemented from scratch i.e. all the outlined steps above are executed. If an adapter factory is envisaged, the framework based approach is recommended.

Framework based approach

When there is a need to create resource adapters for more than one EIS, development effort can be greatly reduced by defining a generic adapter framework. This is because the common features applicable for all adapters can be built into the framework.
The framework can also implement some default behavior which can be extended as needed by the developer. For example, the JCA specification requires that the InteractionSpec implementation class provide getter and setter methods that follow the JavaBeans design pattern. To support the JavaBeans design pattern, support for PropertyChangeListeners and VetoableChangeListeners in required in the implementation class. The framework can take care of this and other low level details allowing the adapter developer to focus on implementing the EIS-specific details of the adapter.

The common features for the resource adapters that can be implemented by the framework include but are not limited to

• Basic support for internationalization and localization of exception and log messages for an adapter
• Logging tool kit support
  -that allows you to log localized messages to multiple output destinations.
• Getter and setter methods for standard connection properties (username, password, server, connectionURL, and port) as the connection properties are common to all the EIS
• License checking facility (applicable for EIS vendors who market the adapters)
• Default Connection event listeners for logging connection-related events
• Simplifying the clean-up and destruction of Connections
  -destroying Connection instances when a connection-related error occurs
• Exception handling for
  -providing a generic exception handling
• Base implementation of the primary Interfaces for abstract implementation of the interfaces

Instead of investing lot of effort and time in planning/designing a custom framework from scratch, there are many frameworks available from popular application server vendors which can be used right away. For e.g. BEA has Adapter Development Toolkit, IBM has its own Connector framework; SUN has Sun ONE Connector Builder etc. These are best used for their respective application servers as they are designed for those and there can be difficulty in porting to other application servers. But definitely a lot can be benefited by studying these frameworks’ documentation which can aid in building your own custom framework.

In conclusion, the approach depends on factors such as business drivers, time to market, complexity, and available developer skill set etc. Having a framework in place adds structure and consistency to the process and product, reducing recurring development/enhancements and maintenance costs.

Classic Mistakes of Testing

One of my friend Anil Agrawal is a Quality Leader in C-SAM Solutions. He had sent me an excellent email on classic testing mistakes. Thought I would share with you all. Thanks Anil.

Here it goes...

A first major mistake people make is thinking that the testing team is responsible for assuring quality. This role, often assigned to the first testing team in an organization, makes it the last defense, the barrier between the development team (accused of producing bad quality) and the customer (who must be protected from them).
It's characterized by a testing team (often called the "Quality Assurance Group") that has formal authority to prevent shipment of the product. That in itself is a disheartening task: the testing team can't improve quality, only enforce a minimal level.
Worse, that authority is usually more apparent than real. Discovering that, together with the perverse incentives of telling developers that quality is someone else's job, leads to testing teams and testers who are disillusioned, cynical, and view themselves as victims.

We've learned from Deming and others that products are better and cheaper to produce when everyone, at every stage in development, is responsible for the quality of their work ([Deming86], [Ishikawa85]).

In practice, whatever the formal role, most organizations believe that the purpose of testing is to find bugs. This is a less pernicious definition than the previous one, but it's missing a key word. When I talk to programmers and development managers about testers, one key sentence keeps coming up: "Testers aren't finding the important bugs." Sometimes that's just griping, sometimes it's because the programmers have a skewed sense of what's important, but I regret to say that all too often it's valid criticism. Too many bug reports from testers are minor or irrelevant, and too many important bugs are missed.

Now for the complete article on classic mistakes, click here.

Hibernate Vs EJB 2.1(Entity Beans)

I need to add lot of meat to the skeleton which I have created in the previous post i.e. related to J2EE Architect worries. I have all the main sections created and I need to elaborate each one of them. It will take time and I need time to do that :).
I was planning to write on System Deisgn worries, but my boss urgently requested me to write something abt EJB and Hibernate , their differences based on my experience and doing some googling. This was urgently required for some proposal.
I finished this 2 pager and thought that I will share it with you all. It might be of some help.

Hibernate 3.0 & EJB 2.1 (CMP)

Hibernate is a powerful, ultra-high performance Object/Relational (OR) persistence and query service for Java.
Hibernate

• integrates elegantly with all popular J2EE Application servers and Web containers with out any restrictions.
• can also be used in stand alone Java applications.
• supports and implements the EJB 3.0 (JSR 220) persistence standardization.

This comparison between Hibernate and EJB 2.1 is strictly with CMP Entity beans and not with EJB Platform per-say. EJB Platform (Session Beans/ MDBs) offer many advantages such as componentization, remote access to applications, variety of clients support (java/CORBA etc) and asynchronous message model.

The EJB persistence mechanism (CMP Entity beans) has many issues/disadvantages

• they are heavy weight components
• high runtime overhead
• have a poor track record on the performance
• cumbersome to develop, lot of interface definitions limiting developer productivity
• Bean partitioning (Each bean a row in some table/Not every row of every table a Bean)
• Vendor dependent CMP optimizations can help performance, at cost of portability
• Inheritance not supported
• Cannot be used for persistence in non-application server environments.
• There is no dynamic query mechanism to lookup entity beans (finders are specified at compile time).
• It is not easy to write unit tests for beans as it is not possible to use them outside of the application server.
• No support for automatic primary key generation.Only relational databases are supported

The above list of disadvantages is the primary reason for the popularity of simple OR frameworks like Hibernate.

Hibernate Features/Advantages
Hibernate is open source product (similar to Struts and Log4j) and not vulnerable to any vendor lock-in and is supported by JBoss Inc.

• Hibernate works on POJO principles and it is light weight
• Hibernate is much more easier to use than handwritten SQL/JDBC (i.e. BMP Beans) and much, much easier to use and much powerful than Entity Beans 2.1
• Hibernate always executes SQL statements using a JDBC PreparedStatement, which allows the database to cache the query plan.
• Hibernate is able to implement certain optimizations (caching, outer join association fetching, JDBC batching, etc.) much more efficiently than typical handwritten JDBC.
• You may use Hibernate from servlets or Struts actions, or from behind an EJB session bean facade. In a CMT environment, Hibernate integrates with the JTA Datasource and TransactionManager, as well as JNDI.
• Hibernate has a very sophisticated second-level cache architecture and supports pluggable cache implementations.
• Hibernate supports composite keys
• Hibernate supports instance variables persistence i.e. Java Beans Style properties like getter/setters

Use-ful links:

www.hibernate.org/

www.google.com ;)

J2EE Architect Worries-Contd..

In the previous post I had chewed on Methodology. Lets move on to other worries. :-)

2. System Design:

1. Scoping Requirements
2. System Interfaces
3. Reviews of UML Artifacts
4. Functional Documents
5. Data Modeling

3. Architectural Artifacts:

1. Functional/Logical System Model
2. Physical System Model
3. Component/Packaging Model
4. Third Party Service Providers and Component libraries
5. Application Framework
6. Data Management Strategy
7. System Transactional requirements
8. Application Integration & External Systems
9. Security Requirements
10. Performance Requirements
11. Internalization requirements
12. System Transition Strategy

4. Environments:

1. Development Environment
2. Integration testing environment
3. User Acceptance testing environment
4. Production Environment

5. Development (my favourite one):

1. Application Framework

• Spring java/j2ee App Framework
• Apache Struts Web App Framework
• Wafer Web App Framework

2. Coding Standard
3. Use Case Realizations with UML artifacts and functional documents

4. Software Configuration Management
5. Development environment
6. Daily development activities
7. Unit Testing Framework
8. Trainings & Sessions

• Coding Standards
• Architecture
• Application Framework and Programming Model
• Third Party Component Usage and Specifications
• Performance Requirements
• Version Control System

more later..first I need to elaborate on each of the above one ....

What an J2EE Architect needs to worry about?

My aspiratation is to become an J2EE Architect and I'm steadily progressing in that direction. As part of my experiecnce with few large J2EE projects/ reading many books on J2EE/googling/reading articles I try to list down the responsiblities/worries of an J2EE Architect. This is WIP document. I will be updating based on the comments and suggestions.

-------------------------------------------------------------------------------------
The best architects are good technologists and command respect in the technical community, but also are good strategists, organizational politicians (in the best sense of the word), consultants and leaders.
(I have taken this from here. This is a good site on Software Architecture Discipline)

Here is the list:
1. Methodology
2. System Design
3. Architectural Artifacts
4. Environments
5. Development
6. Build and Deployment
7. Testing
8. Tools
9. Miscellaneous Deliverables

Lets take one by one.
1. Methodology
a. Rational Unified Process (RUP)
b. Agile Methodologies
b. Xtreme Programming (XP)
c. Crystal
d. Feature Driven Development
c. Hybrid of RUP and XP

a Rational Unified Process (RUP)
The Rational Unified Process collects many of the best practices of OO analysis and design to form a process framework with 38 different artifacts. RUP is not generally considered lightweight, although a lightweight configuration called dx (“xp” turned upside down) exists. Of course, not all 38 artifacts are required in either RUP or dx. In fact, the process framework is configurable to as few as two (use cases and code) artifacts. However, the general RUP-based process uses quite a few requirements, analysis, and design artifacts because its developers based this process on the activities of the OOA/D movement.

b. Agile Methodologies


c. Xtreme Programming (XP)
Extreme Programming has been the pioneer in the modern movement toward lightweight processes. XP emphasizes a single major artifact, the code itself. This process uses 3” x 5” cards to capture requirements in user stories and design via CRC (class, responsibilities, and collaboration) cards, the minor artifacts of the process. XP is much more than user stories, CRC cards, and coding, however. Testing frameworks and innovative practices such as pair programming (working in groups of two people) make XP an interesting addition to the field of software development processes

d. Crystal
Crystal is a lightweight process that contains 20 artifacts. This might sound like a heavier process than XP but most of the artifacts are informal and can take the form of “chalk talks” (working problems out on a chalk board), conversations, and e-mails. Of these 20 artifacts, only the final system, the test cases, and the documentation are formal. Crystal divides its artifacts into levels of precision (20,000-foot view, 5,000-foot view, 10-foot view) to allow developers to focus on their objectives.

e. Feature Driven Development
Feature-Driven Development is an incremental approach that uses as few as four artifacts (feature list, class diagram, sequence charts, and code). The FDD process focuses development using two-week iterations to show quick tangible results. Among the contributions this process provides is a semantic-based class diagram template—called the domain neutral component, which differentiates types of classes by color—to aid class designers in developing a domain model.

f. Hybrid of RUP and XP