Anteo Group introduces the first edition of Anteo Java News, Anteo Group's Newsletter for the Java Professional. We welcome your feedback and article submissions as we are tailoring the newsletter for you. Please send any comments and/or submissions for future articles to Anteo Group Marketing. To receive Anteo Java News by email, contact us.

Thanks and enjoy!

The State of Java's Future
By: Gil Estes

Write it once + run it anywhere = Java. No other platform can make that claim. Having developed several successful Java applications that run on Windows, Linux and Mac OS X platforms, I attest to this portability. Using Java, I provide cross-platform solutions, saving clients money and time in development, producing stronger, more versatile products that run in a variety of environments.

Today, the Java platform has expanded well beyond the traditional stand-alone application implementation. Java allows for rapid development of web applications that are capable of tasks from simple web site data gathering to remote document editing and database manipulation. The Swing toolkit offers a rich user interface with all the bells and whistles. Java implements wireless implementations on a wide variety of devices, from cell phones to pagers to PDAs. EJBs and JDBC provide robust database support. It seems that everywhere you look there are Java enabled devices with Java applications running smoothly.

The FUD Factor

Fear, Uncertainty and Doubt. Microsoft is touting .NET as the way of the future, insinuating that Java is dead. Keep in mind that the automobile was once considered by many to be just a passing fad. Steve Jobs was told that small, home-based computers had no future.

The truth is Java has matured well beyond what early critics and even proponents thought possible. Its flexibility and adaptability keep it lean and agile. The open source community has embraced Java and is taking it further by providing an array of third party components for data presentation, manipulation and reporting.

Perhaps the most telling indicator of the future of Java occurred this year at SunOne. Automobile manufacturer BMW introduced a car equipped with a Java-powered in-dash computer to control navigation, air conditioning, entertainment and other functions. With aircrafts already having the "glass" cockpit concept, is it any surprise that automobiles are now benefiting from this technology?

Java is not dead but is very much alive. Java continues doing what it has always done: embrace change and adapt to new challenges. I am confident enough in the future of Java that I have placed the future of my consulting firm on the line with Java being the backbone.

Using Java Reflection in a SOA Environment
By: Harish Sathyanarayan

Java Reflection APIs have always been used sparingly in most J2EE shops. Reasons are attributed to factors like application performance and run-time anomalies. However there can be situations where it can be an effective solution. Let us consider a real-world example. A company XYZ sells widgets and accepts orders from external clients through a web service interface. The web service calls back- end objects /databases depending on who the client is and what kind of transaction is being performed. The company has a few customers currently but anticipates the customer base to grow each year.

The way it works currently is the client sends a client Id that indicates who he is. The web service identifies the client based on the client Id and calls relevant backend objects. This is done by having reference to other server-side objects in the Java code and using a good old if-else condition to identify who the client is and dispatching the request accordingly. But as the customer base grows large to several hundreds or thousands, this solution may not be practical anymore. The IT team also anticipates way too many development-test-deployment cycles. It may get trickier if the clients need a personalized access into the web service. All this increases the time, cost and effort from everyone involved.

Now let us consider using Java Reflection APIs to solve this business problem. A properties file is used that gets updated periodically as new clients are enrolled. The web service gets the information from the properties file to figure out which back-end objects it needs to call for each client transaction. Then it uses the reflection APIs to create these objects during run-time and call the relevant methods.

Couple of advantages to this approach:

• Reduces the development time and cost by defining the objects in a properties file
• By creating a loose-coupling, the web service is immune to any changes on the server-side. It is possible that a client delegate to a legacy app may change, EJB objects are added or changed.

Below is a simple snippet of code that creates a single object during run-time using reflection APIs. This can be extended to generating several back end objects. Design patterns like the Factory or Abstract Factory can be applicable here.

MyObject myObject = null;
Public static MyObject getObject() {
String objNameStr = getObjectFromPropertiesFile(clientId);
Class concreteClass = Class.forName(objNameStr);
myObject = (myObject) concreteClass.newInstance();
return myObject;
}

Applying JAVA Using Best Practices: Part I
By: Vishy Dasari

JAVA is much more than a programming language. JAVA is a technology platform that offers building blocks to build open-ended enterprise grade software solutions via standardized API. Unfortunately, the openness of JAVA can lead to many project failures if this technology is not implemented correctly. Best practices from experienced JAVA user community are available in the form of design patterns and frameworks. We must identify the right architecture and open software components for successful implementation and deployment of JAVA based applications.

Design Simplicity Rule

It is extremely important to keep our application architecture and designs very clean and simple. Any complexity in the designs must be well documented and must be justified during the early stages of a J2EE project. Complexity must only be added when justified in an iterative manner. For example, it must be well understood why we made a decision to use an EJB model. Are the entity beans justified? Sometimes, the complexity will offer some amount of friction before it starts off to pay you its returns. If the complexity is becoming a blockage to any future enhancements it is definitely time to go back to the white board.

Design patterns

A design pattern offers you a readily available generic solution to specific problem areas within your software system. Many dozens of patterns have already been identified and documented by the software development community. During the design phase of our SDLC it is highly recommended to identify the patterns that would best suite to our business model. The design patterns should not be introduced in to our design model in a pedantic or perfunctory manner. The goal of these patterns is to reduce our implementation times and to effectively re-factor our source code while providing snag-free design solution.

Frameworks

A framework is a JAVA component (e.g. a jar file) that has implemented one or more of design patterns. Struts is a framework that is the most popular when implementing a web-based application. Struts framework implements the command dispatcher pattern.

Dasari will tackle the Best Practices for Enterprise JAVA, Deployment, Application Management, and Open-source Software Components in the next issue of Anteo Java News.

Current Openings

For our most current openings, click here.

back to newsletters >

For more information about the Anteo Group, contact us.