Anteo Group

Anteo Java News: Fall 2006

We appreciate and welcome all of your comments and 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!

Don't Be Scared By SOA (an educational editorial)
By: Garner Andrews

One of the biggest buzzwords in use in our industry right now is Service Oriented Architecture, or SOA. It is true that SOA has enormous value to businesses that are required to participate in the software development industry, so it's something that we should all be aware of. However, one of my disappointments is the way in which so many of the major software vendors and other "experts" in the SOA space seem to mask over or cloud communication of what SOA really is.

I hesitate to actually call it a methodology (even though many vendors do have methodologies based on SOA), as it conceptually lacks specific frameworks, processes, or procedures. It is definitely an approach to development. It is also something that has actually been around for decades. I'm oversimplifying it, but only a little, when I define it as simply a means to optimize the development process from business requirements to implementation. Conceptually, the work of "processing" is done in services provided by any number of systems (hopefully pre-existing systems that one wouldn't have to lift a finger to change). The core architecture doesn't care what technology is used. All that matters is that the core system can communicate with the outlying services based on some agreed interface. Twenty years ago I might have done this with a database schema, but today I do it with a WSDL file.

The reason I'm so aggravated with the majority of "experts" in the SOA field is because it really is a much clearer definition of this (technology-) age-old approach, and yet they try to hide what it really means so they can make a buck explaining it to your, or because it increases the "ahhhhh" value behind them being the experts. To be clear, it seems to be the vendors that provide SOA services that do this. The individuals who have written books on SOA seem to do a good job explaining and educating, so please don't associate my criticism with them. The caveat to this is that those same vendors' services are invaluable if they have the right resources. An experienced SOA architect can save a company huge amounts of time and money. Good SOA architects are analogous to good racecar drivers: everyone knows the basics about getting in a car and driving fast, but it takes serious talent and skill to be really good at it.

That said, my advice is this:

If you need to know more about what SOA is, start with the definition in Wikipedia and pick up one or two of the dozen or so available books on the subject.
The concepts behind SOA have been around a long time, so don't be daunted by the new term. Take advantage of the fact that it is a clearer definition of what we've been trying to do all along. Basically, feel comforted that we are able to explain it in much better terms, thus optimizing the development process even more.
When you find you need outside help, obviously make sure you qualify your vendor(s), but don't be daunted. You understand what these resources are supposed to provide, and you can easily tell if you're getting good results from them.

About the author:
Mr. Andrews is an Enterprise Architect from the Atlanta area with over 15 years of industry experience. He has specialized in SOA, portals, content management systems, security architecture, and operations architecture. He is the President and Chief Architect of ClearResults Group, Inc., a principal owner of CompuNet Consulting Group, Inc. and on the Board of Directors of Sagepath, Inc.

Agile
By: Anne Greenhaw

It has been said that Agile project management is simple but changes everything. If you're still interested, here's an introduction to the principles of Agile, including when, why and how it could improve your future project efforts (and 10 steps to finding out).

"If you want to teach people a new way of thinking, don't bother to teach them. Instead, give them a tool, the use of which will lead to a new way of thinking." - Buckminster Fuller, American inventor, author and visionary

Agile is an organizational change tool that can lead to positive changes in your projects and programs. It is a very simple and different strategy for project management than critical path and waterfall. This introduction to Agile is written for traditionally trained project managers who understand and practice critical-path planning and stage-gate program management. As an introduction, it explores the topic using the familiar structure of Who, What, Where, Why and How.

What Is Agile?

The "iron triangles" below depict the constraints that any project must wrestle with. Waterfall is measured by conformance to the plan. The essential disciplines of waterfall require you to get the plan right and make the phase hand-offs of documents effective. If you get it right, waterfall can be very efficient and successful, but never early.

Agile is driven and measured by its ability to deliver results to the vision and value. And like waterfall, Agile requires certain disciplines to be successful. With Agile, the essential disciplines require crisp and effective cross-functional collaboration and a commitment to delivering working code in the face of small fixed resources and fixed time boxes, known as iterations. As a result, Agile projects can deliver early - as soon as the vision and value are realized.

For projects where the risks are high and the project definition is evolving, Agile's simple empirical method delivers consistently better results, faster and with less total cost. For projects where the technical, execution and funding risks are low and the definition is well known, the waterfall process can be more time- and resource-efficient - provided you plan, you hand-off documents well, and the definition does not change during the project.

Agile is a feedback-driven paradigm for managing the design and delivery of creative, innovative, risky and complex projects. Its principles are contained in the Agile Manifesto. Its best practices include:

Run 1-4 week iterations that deliver working, tested increment of functionality
Make releases to customers smaller and more frequent
Maintain the system in state that always runs and passes automated tests
Organize around cross-functional component teams (define, test, code & build)
Work projects serially from a regularly evaluated and prioritized backlog
Inspect and adapt the process and product every cycle

The Agile process is well depicted by the Scrum model of working on the highest priority items in concentric time-boxes including daily, iteration, release, roadmap, and vision. The following illustration depicts those multiple levels of time-boxes, planning and tracking.

Organizing for Agile requires working in cross-functional teams of resources required to produce a complete releasable solution. This typically means people who can define, develop, test and package a component of the system. Leadership of Agile teams requires servant leadership skills. Technology to support Agile facilitates collaboration, prioritization, visibility and lightweight signaling.

What Agile Is Not

Just like any strategy, Agile can be misunderstood and abused. When the disciplines are not met, it can degrade into chaos just like plan-driven approaches. When it degrades, you typically hear Agile is:

Cowboy coding. Agile is not a license to avoid planning, estimating or design. Agile mandates planning and retrospective at the boundary of every time-box.
Not a commitment. Agile forces scope commitment at multiple levels including every day, and it is open to adjustment on the boundaries of time boxes.
Two-week waterfalls. Agile turns the waterfall on its side by having small, cross-functional teams work the highest priority item to completion before moving to the next item, not the next waterfall phase.
No documentation. Agile does not say no documentation (user, tech, capitalization, regulatory). Agile minimizes the documentation of hand-offs by increasing cross-functional communication and encourages generating required documents after the working code is complete, not before.

Many of these misconceptions about Agile are the roadblocks that folks doing waterfall or heavy stage process will put up in front of an organization trying to pilot, adopt or scale Agile. These are the failure modes of any organization without discipline, also known as chaos or heroism. Agile is a very disciplined methodology and should not be confused with these.

Who Is Behind Agile?

The founding fathers of Agile are methodologists who got together in 2001 to create the Agile Manifesto. Many of the concepts of Agile originated from Lean principles, which Toyota and other manufacturers made famous for its low-waste, high-productivity results. Since the signing of the Manifesto, a number of methods have converged under the term Agile, driven by the nonprofit Agile Alliance's leadership and a number of commercial vendors.

Where Does Agile Work?

Agile can work on any project setting in any industry. In software, all types of teams use Agile. It works with large and small projects, co-located and distributed teams, startups and the government. If you aren't meeting customer or stakeholder expectations, are falling behind the competition or are tapping out every resource, Agile can provide an excellent framework to solve those issues.

Why Do Teams Use Agile?

Teams use Agile to deliver major improvement in project success. Under Agile, teams can expect to deliver sooner, with fewer defects and less waste than ad-hoc or waterfall teams. Agile also creates a higher quality of life for the team by:

Removing time-slicing of individuals across multiple tasks and projects;
Reducing the burden of managing large piles of unnecessary requirements and debilitating bugs; and
Increasing quality by pulling testing forward and reducing technical debt to keep the system always releasable.

As a team makes these changes, the benefits of Agile are gained by the team and fuel further enthusiasm to continue to evolve, remove roadblocks and gain more benefit.

How Do Teams Adopt or Trial Agile?

A vast majority of teams get started with Agile by adopting it on one team first. Agile is not typically mandated or even supported from higher in the organizational structure until there is proven success on at least one pilot team. To start a pilot team, follow these steps on an in-flight project or new project:

Get the team together and get agreement to try Agile
Declare an iteration time box, for example two weeks from this coming Monday and schedule a demo with stakeholders for the end of the iteration.
Prepare your top five highest priority items to get done in the two-week period. This list of items includes for each a description of item using a story template ("For system role, provide the capability to deliver benefit") as well as the one to three user acceptances tests necessary to declare these items done.
Have an iteration planning meeting for about four hours wherein you task estimate these five items and discuss, with the whole team, the designs necessary to get these items done-done in the two week window. (done-done is coded, tested, user accepted and integrated into the systems)
In the planning meeting, estimate your capacity in the two-week window in hours of productive time. (Typically no more than 50 percent of the wall time available to a new Agile team).
Use your capacity to reprioritize and shape the 5 items to fit into the capacity-constrained iteration. Do not ask the team to do more than the available capacity.
End the planning meeting by have the team come to consensus and commit to delivering some portion of the five items in working, demonstrable code at the end of two weeks.
Run the iteration and steer it using a daily 15-minute stand-up meeting.
After the iteration ends, hold the demo to get stakeholder and customer feedback on the delivered software.
Hold a review meeting with the team to figure out what went well and what you want to change. Ask the team if they want to keep doing Agile or go back.

What Are the Next Steps?

There is big footnote on Agile: "It's simple, but it changes everything." Because the time-boxes are short, it is easy to measure progress and expose issues. Agile exposes "issues" quickly and effectively. You need to be ready to work in very open and visible environment. In addition, you need to be prepared for feedback and reflection. If your team collaborates well and has the discipline to work the highest priority items in small chunks, you will not have any problems. If your team does not fit that description, here are some suggested next steps:

For teams whose members are not collaborating well:

Send your team's facilitator to a Certified ScrumMaster public course. The facilitator runs your daily stand-up, iteration planning and review and release planning meetings.
Pick-up a copy of Jean Tabaka's book Collaboration Explained, filled with the meeting agendas and tips to encourage group collaboration.
Hire a coach to help your team get over the hump of the first three iterations. The first three are hard; traditionally everyone tries to accomplish way more than they can accomplish in two weeks.

For teams having a difficulty working on the highest priority items to done:

Have your "product owner" attend a public Scrum product owner course
Take an iteration to have your engineering team reduce its debt of defects, architectural refactorings, or build and automated test infrastructure.
Have your QA team work with your product owner to compile the acceptance test criteria for all the items of an iteration prior to its planning meeting.

Finally, if you need to think about how Agile can cooperate with your current waterfall world, review Michele Sliger's Agile 2006 presentation, "The Agile/Waterfall Cooperative."

Ryan Martens, founder and CTO of Rally Software, has worked in the software industry his entire career, including in project management and director roles at large systems Integrators; as project manager and director at large telecom IT shops; and in product management and marketing roles at large and small independent software vendors. Ryan was trained in traditional project management, but has been using forms of Agile methods since 1995. Ryan is also a board member for the Agile Alliance.

Java Annotations in a Nutshell
By: Gregory Mullins

The Java EE platform introduced a simplified programming model. For one thing, XML deployment descriptors are now optional. Newly introduced where annotations. A developer can simply enter the information as an annotation directly into the Java source code and the server will configure the component at deployment and run-time. Nothing could be simpler! There are two steps in creating Java annotations. The first is the definition itself. The second is the actual implementation which brings it to life.

For example, to define your annotation:

public @interface ThisAnnotation { String doSomething(); }

Then the implementation:

ThisAnnotation (doSomething="Hello world!") public void mymethod() { //TODO }

Annotation types

There are three annotation types:

Marker
Single-element
Full or Multi-value

The Marker type has no elements except the annotation name itself.

Example:

public @interface ThisAnnotation { }

Usage:

@ThisAnnotation public void MyMethod() { ... }

The second type, "Single-element", provides a single piece of data.

Example:

public @interface ThisAnnotation { String DoSomething(); }

Usage:

@ThisAnnotation ("TODO") public void MyMethod() { ... }

The third type, "Full-value or multi-value", provides multiple data members. Therefore, you must use a full data=value parameter syntax for each member.

Example:

public @interface ThisAnnotation { String DoSomething(); int count; String date(); }

Usage:

@MyAnnotation (DoSomething="TODO", count=1, date="11-11-2006") public void MyMethod() { ... }

Annotations allow tools to generate code under many circumstances. This leads to more of a "declarative" style of programming where the developer says what can be done and in turn the tools generate the code to do it. They also eliminate the need for maintaining external files (i.e., like deployment descriptors) that must be kept up to date with any changes the source file(s) encounter. Instead, all of this sort of information can be maintained within the source file(s) themselves. This is not only convenient, but will go a long way in eliminating the possibility of errors in maintaining two source files to update.

Annotations do not directly affect program semantics, but they do affect the way programs are treated by tools and libraries, which can in turn affect the semantics of the running program. Annotations can be read from source files, class files, or reflectively at run time.

Annotations complement javadoc tags. As a general rule to follow, if the markup is intended to affect or produce documentation, it should probably be a javadoc tag; otherwise, it should be an annotation.

Java comes with a limited amount of free annotations. We'll look at three of them in the following sections.

Override annotation

Java EE has built-in annotations. One of them is "Override". Override should only be used on methods (not classes, package declarations or other constructs). It indicates that the annotated method is overriding a method in a superclass.

Example:

public class OverrideExample { public OverrideExample() { } @Override public String toString() { return super.toString() + " [Override example]"; } @Override public int hashCode() { return toString().hashCode(); } }

The @Override annotation annotates two methods -- toString() and hashCode() to indicate that they override versions of the methods from the OverrideExample class's superclass (java.lang.Object). This is pretty straight forward right? However, if you forget to override those two methods you cannot compile this class without a compiler error. The annotation also ensures that when you mess with toString(), you also have at least some indication that you should make sure that hashCode() still matches up.

Deprecated annotation

How many of us has switched to the newer Java compilers and seen the "deprecated" warnings that they spit out? This is courtesy of the "deprecated annotation". This annotation is very useful for not only letting developers know that some method or methods in our code have been deprecated, but also alerts us to code that potentially needs changed or reminds us not to use that method again for future coding.

SuppressWarnings annotation

The last annotation type I'll discuss is SuppressWarnings. As the name suggests, this annotation type will suppress warnings that the compiler generates. Why is this one important? If you are writing code for compatibility with previous versions of Java, you'll be bombarded by warnings that you do not need to be concerned about. In order to suppress those warnings, this annotation type comes to our rescue. Please note that this annotation requires a variable (single annotation style).

Example (non type-safe):

@SuppressWarnings( value={"unchecked"} ) public void nonGenericsMethod() { List wordList = new ArrayList(); wordList.add("foo"); // causes error on list addition }

Just locate the type of warning ("unchecked"), and pass it in to SuppressWarnings. How simple is that?

Conclusion

Annotations are pretty easy to understand and simple to use. I've only touched the surface here with the basics. What's really cool is you can create your own annotation types that are perfect for your own applications. Metadata is becoming increasingly useful, so using annotations with metadata is a very good match. The possibilities are endless.

About the Author
Gregory Mullins is a private consultant working in and around the Atlanta area. His career spans 15+ years and includes programming in C++ and Java. His Java EE accomplishments have been on projects at Harvard University and the Library of Congress. He currently has multiple projects going on including writing a book on the Parousia which should be out in the spring of 2007. He can be reached at: greg@mullinsfamily.org.

Current Openings

For our most current openings, click here.

back to newsletters >

For more information about the Anteo Group, contact us.