The job market for computing professionals is undergoing some dramatic and unexpected changes. Below are several recent computing professional job trends.
Dramatic Increase in Demand for Professional Staff
Despite the widely held and mistaken perception that most computing professional jobs are being outsourced offshore, there has been a pronounced increase in computing professional job openings both in our home state of Michigan and nationwide in the past year. According to the Labor Department, total employment among computing professionals in the U.S. reached nearly 3.5 million by the end of last year, surpassing the previous high in 2000, when the technology investment boom peaked.
Sharp Decline in Supply of Computing Professionals
Although the need for computing professional expertise is growing, the number of students choosing computer science as a major is 39 percent lower than in the fall of 2000, the last of the dot-com bubble years, according to the Computing Research Association. This decline in computer science enrollments is a worrying development for employers who see young graduates as supplying the energy, creativity and cutting-edge computing skills essential to the survival of their organizations. The decline in computer science enrollments is compounded by the impending mass retirements of aging baby boomer computing professionals, which will create large gaps in valuable computing professional talent and experience.
Bill Gates has remarked on this trend and is doing a college campus tour promoting careers in computing fields to American students.
New Corporate Computing Professional Initiatives Required
Companies will need to prepare for this exodus by developing younger staff and tapping into the older workers’ knowledge through collaboration, mentoring and internship programs.
All of this news suggests a certain level of continued job security to current computing professionals. And with salaries and contract rates as much as 20% lower in the U.S. over the past three years, it also suggests some bargaining power when negotiating for higher compensation.
John W. Stout is the founder and president of Stout Systems. He has twenty-five years experience in the software industry. He is also sought after as a technology speaker, presenting sessions at developer conferences and user groups. E-mail
.
-back to top-
Externalizing Enterprise Configuration with the Spring Framework
by Dan Rudman
Enterprise applications typically require access to configuration data for a number of reasons:
· Display elements – warnings/errors, format templates, descriptions, etc.
· Application configuration – constants that drive the application’s plumbing
· Business parameters – business-specific constants that drive use cases
Best practices dictate that, where possible, all configuration data should be externalized to reduce the impact of change on development, testing, and deployment.
Introducing the Spring Framework
Introduced in February, 2003, the Spring Framework is an open source application framework designed to make J2EE development easier. It provides extremely simple architectural solutions to problems typically addressed with complex designs and scattered code. Applications written on top of the Spring Framework are typically:
· Simpler and easier to read
· More maintainable
· More reusable
· More likely to involve pluggable services
Spring provides a number of extremely interesting and useful tools for developers. To cover them all would take more room than this article allows. Thus, the remainder of this article focuses simply on externalizing configuration. Greater exploration of Spring’s offerings will be left for future articles.
Focus on Spring's Externalization Value
To see why Spring externalizes configuration so well, we need to understand a core concept called dependency injection. Dependency injection is a software pattern where the responsibility for creating objects and linking them together is removed from the objects themselves and moved into a factory. A factory is a software pattern where one object is designated as the creator for a class of other objects.
One of the Spring Framework’s core advantages is the externalization of data and relationships between data via dependency injection based on simple XML files. The primary component of Spring’s implementation for this is the "bean factory".
Simply stated, a "bean" is any Java object that adheres to the following guideline:
· Any modifiable property, X, has a setX(…) method
· Any requestable property, X, has a getX() method
A bean factory, then, is a component that creates beans. The most commonly used bean factory that Spring provides is the application context. This context, which contains the bean definitions, is initialized by the application and stored so that it can be retrieved when needed. Thus, when an XML file specifies a bean with properties, Spring uses dependency injection to map those properties to the creation and management of objects and their relationships.
Let’s examine snippets of a bean definition file and how it deals with each type of configuration data.
Externalizing Display Elements
Most interesting applications display something. Consider an internationally accessible web page where we need to be able to display some description and several potential validation errors.
Following the Java standard for internationalization, we create properties files for each language. For maintainability, we split this into two different properties files as follows: descriptions.properties, errors.properties. We can access these via Spring by specifying them in an external bean definition file:
<bean id="messageSource"
class="org.springframework.context.support.ResourceBundleMessageSource">
<property name="basenames">
<list>
<value>descriptions</value>
<value>errors</value>
</list>
</property>
</bean>
To request a display element, we simply write:
String message = appContext.getMessage(
"descriptions.mypage.myDescription", null, Locale.getLocale() );
You can see from this example that - via dependency injection - an object named messageSource will be created and its method, setBasenames(), will be called with a List argument containing two values, descriptions and errors. This is an extremely simple and yet powerful concept: we have just created and initialized an object via an externalized configuration file!
In the web display layer, where display elements are most likely needed, we can simplify by using Spring’s standard JSP tags:
<spring:message code="descriptions.mypage.myDescription"/>
Externalizing Application Configuration
Display element abstraction is great, but it is in application configuration that Spring truly shines. Configuring an application involves establishing its plumbing details at startup. Good general examples include logging, security, and data access. A more application-specific example might be an insurance rating strategy.
Spring’s beans promote thinking in terms of complete objects, which leads to easy configurability. Let’s look at how a Spring bean definition file specifies a Data Access Object:
Suppose you have a well-architected data access layer as follows:
Traditionally, you’d create a MyDataAccessObjectFactory and then dynamically create one of the implementations based on some configuration parameter passed into the factory. With Spring, the bean definition is the factory! We simply define the implementation we want to use:
<bean id="myDataSource"
class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName" value="com.mysql.jdbc.Driver" />
<property name="url" value="jdbc:mysql://data.xyzcorp.com:3306/mydb" />
<property name="username" value="someone" />
<property name="password" value="blah" />
</bean>
<bean id="myDataAccessObject"
class="OneDataAccessObject">
<property name="dataSource" ref="myDataSource" />
</bean>
In this example, we’ve created an Apache Commons DBCP DataSource implementation called myDataSource. You’ll also notice a reference to destroy-method, which allows Spring to automatically call the close() method in the DataSource when the object is destroyed by the Java Virtual Machine.
Next, a Data Access Object implementation is created, and its setDataSource() method is called with the DataSource that we just discussed passed in as an argument.
Note how in addition to hiding the Data Access Object implementation details from the application code, we’ve also hidden the DataSource implementation details! The developer will not need to create or obtain a DataSource; instead, that responsibility rests with Spring. This allows us to take advantage of different implementations of DataSource for different purposes (e.g., pooling vs. non-pooling) simply by changing an external file and restarting the application.
When we want access to the Data Access Object, a developer simply writes:
MyDataAccessObject exDao = (MyDataAccessObject)appContext.getBean( "myDataAccessObject" );
List stuff = exDao.retrieveStuff();
Again, notice how the developer does not know - or care - which implementation was selected! This illustrates a great advantage of Spring: it makes it easy to write to abstractions that focus on value-added work rather than plumbing details.
This is extremely useful in application-specific cases as well. For example, consider an insurance company with different rating engines that produce quotes for customers. Selection of the rating engine is simply a matter of selecting the appropriate bean. Connectivity of the engine - through a middleware product or a database, for example - can also be specified within the bean definition file. Developers might use mock objects in place of the actual rating engine in order to test related code without considering the engine in development tests.
Externalizing Business Parameters
Keeping business parameters out of application code is a worthy goal of any development project. The last thing you want is to have to rewrite a portion of your application just because you made some simple change to your business. Spring makes it very easy to move the parameters out of your code.
Suppose an insurance company has a set of default values they want used for a new policy:
<bean id="defaultPolicy"
class="xyzcompany.InsurancePolicy"
singleton="false">
<property name="previousInsurer" value="XYZCompany" />
<property name="coverageA" value="200.00" />
<property name="coverageB" value="135.00" />
</bean>
To create a new policy with default business parameters already set, a developer simply writes:
InsurancePolicy policy = (InsurancePolicy)appContext.getBean( "defaultPolicy");
To add a default to an existing attribute, a developer need only change the bean definition. For example, if the business later decides to also default coverage C:
<property name="coverageC" value="225.00" />
Conclusion
Spring helps developers externalize configuration and makes it easy to write abstractions that promote good architecture. This reduces code and increases reusability and maintainability - in management speak, "saves time and money". Spring is well worth looking into for any business considering architectural components for new projects. For additional information, visit The Spring Framework and An Introduction to the Spring Framework by Rod Johnson.
Dan Rudman is the President of Kade Consulting, LLC and a specialist in enterprise Java architecture with a decade of Java experience. He is a postgraduate of the University of Michigan in Ann Arbor and a perpetual student of everything.
-back to top-
