My company uses a large number of software applications to support all aspects of its business.
These software applications are either "bought" or "built".
The portions of the company that cannot be supported by purchased software are
supported by custom developed, in-house, applications.
A variety of technologies are used to create and build these custom applications.
The Java framework has been successfully used to create applications for many years.
The .Net framework has also been successfully used to create applications for many years.
.Net is a software framework developed by Microsoft Corp. that runs primarily on MS Windows.
It includes a programming language called C# (C Sharp) and an IDE called Visual Studio.
Both frameworks enjoy strong support among the technical IT community at my company.
From time to time, the question is asked; "Do we really need both Java and .Net frameworks?"
Each time this question comes up, our initial reaction is; "Oh no! Here we go again, Java vs .Net!"
Somebody will be asked to do a "study" of the various technical strengths and weaknesses of both frameworks.
Somebody will be asked to do a "study" of the various support costs of both frameworks.
Somebody will be asked to do a "study" of the various ways both frameworks are being used to develop apps.
Somebody will be asked to do a "study" of how apps built in one framework can be built using the other framework.
In the end, the result is always the same.
It is decided to keep both Java and .Net frameworks and to continue to develop the apps
that are currently using them.
Just as there is plenty of diversity within the Java framework to produce quality apps.
There is plenty of diversity in other development frameworks (.Net) to produce quality apps as well.
I am sure my company will continue to be successful using the variety of development frameworks it now uses.
There is plenty of room, in my company, for Java and .Net frameworks.
Until the next episode of "Java vs .Net".
A while ago, I was asked to evaluate another Java application that was being used at my company.
It was a point-of-sale app, developed entirely "in-house" by one of our overseas affiliates.
I wondered what their MVC model would look like.
How different would their Java app be from the ones I have worked on?
I started my evaluation by learning all I could about the architecture and design of this application.
We were given a copy of the application's Java source code.
I spent a great deal of time examining every line of code within the app.
By the time I had finished my examination, I felt I had pretty good feel for
the application's project structure, deployment strategy, and development practices.
So how different was this application from the ones I have worked on?
Very, very different.
It made heavy use of dependency injection from the spring framework (using both xml and annotation based approaches).
There was very little use of ejb's and sql. Instead there was extensive use of JPA from the hibernate framework.
Instead of using a servlet/jsp approach for the user interface portion of their application,
Java server faces (jsf) and a widget-based approach was used.
The application required very few custom configurations on the application server.
The database data source configurations were performed entirely within the application.
Throughout the app, I saw constant use of traditional object-oriented features : polymorphism and inheritance.
The application itself was deployed as a single install.
The individual packages with the app were divided by technical function instead of business function.
The application was developed in such a consistent manner, it was either developed by a single individual or
a highly disciplined team.
The application is enjoying great success at our company.
Particularly in the overseas affiliate where it was developed.
In Java software development, there is no single "right way" to do things.
This application is certainly demonstrating that.
The key lesson for me, from this experience, is "Diversity".
We can be different about how we do things and we can be all successful at the same time.
Score another victory for Java.
Very soon, it will be time for the annual Java One conference in San Francisco, California.
Thousands of Java-fanatics will make the journey to my favorite city "by the bay" (and my home town).
Thousands more Java-fanatics will not attend (including me) and wish they could.
I hope all attendees will have a great and productive time at Java One 2013.
My general advice to attendees is, "Make the most of your time there."
If I attended, my strategy at Java One would be the same one I use at other professional conferences\events I attend.
1) Learn everything you can - Attend as many technical sessions as you can. Ask questions of the presenters.
Pick up as much technical literature as you can. Attend as many vendor demonstrations as you can.
2) Find out what others are doing - During breakfast and lunch, sit with other attendees and talk to them about what they are doing.
During receptions or after-hours events, chat with others about what is happening in their company.
3) Tell others what you are doing - Shake lots of hands and give others a 30-second re-cap of what you and your company are doing.
Meet with vendors at the vendor expo and let them know what you and your company are doing.
Learn, Find, tell.
I am usually exhausted by the end of such a week. But I say to myself, "The greatest week ever!"
Learn, Find, Tell.
Safe travels and good luck, Java-fanatics!
As a developer, when you are building and/or designing a Java application;
the first (or one of the first) question you might ask is...
"What are the objects?"
This seems to be a very simple question. But it is not.
There probably is no single "right" answer to this question.
Nevertheless, careful consideration given to this question will contribute to
a good start to one's Java development efforts.
In our case, we attended "formal" Java training classes (lectures, labs, etc).
In those classes, we often saw examples of Java objects named
"animal", "cat", and "dog". Useful in class. Not very useful in real-life!
We learned to use nouns or pronouns for the names of objects.
We learned how to make a verb into a noun to name our objects.
For example, "controller", "processor", "runner", etc.
We also learned about analysis objects and candidate objects during UML training.
We realized that when you define a name for an object, you imply functionality and scope.
So we had some basic know-how about defining and naming objects.
But applying all this wisdom to a "real life" example was not easy.
When we considered how to build our Java application; we talked about
business requirements, the user experience, and application functionality.
We discussed business practices, application logic, and application processes.
We also talked about data. We had lots and lots of data conversations
(transactional data, persistent data, customer data, etc.)
But after all the talking, we still asked ... "What are the objects?"
One business process we had to build as part of our Java application did the following.
"Take a file containing transactions to customer data and use it to update the customer database.
Create an audit trail of the updates performed to the customer data."
This was our customer file reconciliation or balancing process.
So what are the objects? Customer...perhaps. Updater...maybe. Transaction...close.
We finally settled on the following object names for this process.
BalancerController, BalancerCustTranCompare, BalancerTransactionOnly, BalancerTransactionMissing,
BalancerCustomer, BalancerTransaction, BalancerAudit
Once the main objects were defined, we had a good start to developing
this part of our Java application.
Names are important. Naming is a skill and an art. Names in Java are very important.
When we started building our first Java application, at my company Amway Corp, many years ago;
we learned our first lesson.
In spite of all the formal training we received, in spite of all the literature at our disposal;
we still needed help with our Java development on a regular basis.
Where would this assistance come from?
At the time, we had no in-house Java subject-matter experts.
What we wanted was to have access to Java "wisdom" from other java developers.
We wanted to be able to see how others would do things in Java.
Fortunately, we had a tool which would provide a means in which to achieve this...
Searching the internet, via web browser search engine became a valuable tool
for answering our most detailed questions about Java development.
We quickly discovered the vast amount of information available through the internet
about Java development. We found resources about Java concepts, design, and sample solutions.
We felt as if we had made a great discovery.
Foremost on these internet-based resources was the Java forum web-site operated by
Sun Microsystems, a previous caretaker of Java.
Code fragments posted by other developers, on this site, gave us answers to our questions.
The forums included a text search capability so we could search by word or by phrase.
We could use a Java-specific word such as "java.io" or a phrase such as "storing images".
Time and time again, we would go to the internet and specifically Sun's Java forum web-site
to get specific answers to our questions.
Time and time again we would get our answers in the form of actual code fragments
that we could immediately put to use.
This information was free to use, freely given to whomever wanted it,
and provided a means give feedback to the contributor of the Java information.
There seemed to be no Java question that we could not find an answer to.
We were simply amazed with how easy it was to "connect" with other Java developers.
Sometimes we felt like standing up from our desks and shouting, "Thank you, Internet!!!"
As our Java expertise grew, we relied less and less and the internet for answers.
When we look back and salute all the contributors to our Java successes over the years,
we have to include the internet and the many givers of Java wisdom who have freely
given so that others may receive.
Learning Java (or any programming language) can be a great challenge.
Any group of developers, learning Java, will bring with them a variety of backgrounds and experiences.
In our case, our first Java project began with developers that had COBOL language experience.
Our second Java project, began with developers that had RPG language experience.
Even though COBOL and RPG don't "look" like Java, those developers still had
a number of skills that helped them make the transition to Java ...
logical thinking, analysis, problem solving, etc.
In my case, I had many years of experience as a C programmer before I learned Java.
My transition to Java was easy and fast.
I immediately noticed the similarities between Java's and C's language syntax.
Time and time again, during our Java training classes, I kept thinking to myself, "This is just like C!"
Like Java, there are many products and add-ons available to the C developer.
Like Java, C has a vast number of resources available to share code and to educate.
C, like Java, has a rich history filled with colorful personalities and is constantly receiving
contributions from a vast array of developers.
From large applications to small applications, the C developer can create any kind of app.
Just like the Java developer.
The biggest difference, I noticed, between learning C and Java is that C was not considered an object language.
Thus thinking in terms of objects is not required in C.
So my transition to Java was easy. Maybe easier than most.
I feel very fortunate to have worked with a great language, C, and then work with another great language, Java.
Who says lightning does not strike more than once in the same place?
One of the biggest challenges facing us during the creation of our first Java application
was learning to develop with the Java programming language.
We were concerned about how well our team of developers would learn and adapt to Java.
Since Java was an object-oriented programming language, we had object-oriented concepts to learn as well.
Our first Java training class was titled, "Developing object oriented applications with Java"
The class was organized into two parts.
1) Principles and concepts of objects
2) The Java programming language
At first, we learned all about "encapsulation", "inheritance" and "polymorphism".
Core features of object-oriented programming.
As we started developing our first Java application, we came to a surprising realization.
We were not doing object-oriented programming with Java.
We started to ask ourselves; "Are are doing procedural-based programming using Java?",
"Are we using Java wrong?", "Do we start over"?"
Then we asked the most important question of all, "What have we done with Java?".
With our Java application; we were creating objects that were performing various operations.
Our application was executing business logic, accessing the database, interacting with end-users,
and interfacing with other applications.
We were doing object-based programming using Java.
We liked what we saw. So we decided to continue our object-based Java development.
Java provides an incredibly useful and diverse set of tools. These tools can be used in many ways.
There is no right way or wrong way to use Java.
Whether it be object-based or object-oriented; we are confident that, with Java, we can be successful.
Assembling a team of Java developers can be a challenging task.
Getting the right people together requires a combination of luck, skill, and plenty of patience.
When someone new joins your team, they could also be new to your company.
Over the years, we have conducted many job interviews of Java developer candidates wishing to join our team and company.
Our Java job interview format is simple and direct.
First, we do basic introductions of ourselves and the candidate.
We get our first chance to hear the candidate speak and we begin to get a feel for their communication skills.
Next, we tell the candidate about the company and then about the project the candidate will be working on.
This is an opportunity for the candidate to ask questions and show interest in joining us.
Next, we provide technical information to the candidate.
What versions of Java do we support. What Java technologies are being used. What Java developer tools do we have.
Next, we ask the candidate to tell us about themselves and about their Java experiences.
This is a chance for the candidate to demonstrate how well they can communicate Java technical details.
Then, we ask the candidate a series of technical questions about Java development.
We ask the candidate to respond to hypothetical situations. A few of the questions are simply, "How would you code this?".
This a key part of the interview. We can usually tell the difference between a candidate that is reciting an
answer from a third-party source and a candidate that is speaking from personal experience.
The technical questions cover a wide range of Java development subjects.
The questions are designed to show us how the candidate literally "thinks" in Java.
After our questions, we then ask the candidate if they have any more questions.
We say our "thank you's" and tell the candidate we will get back to him/her or their recruiter with our decision.
We usually are able to decide immediately after the interview if the candidate is a fit for our team.
That is it. A very simple formula for Java interviews. It has worked for us for many years.
We have been very pleased with the Java developers that have joined our group. All have made significant contributions.
You can say we are a very Java-friendly group!
Our team of Java developers consists of people with various backgrounds and skill levels.
Everyone has a role and is assigned tasks based on that role.
Team members are expected to know basic programming concepts, core Java and core J2EE.
In addition; database access, web-browser, client/server concepts are required as well.
It didn't take long for our team to realize there was a lot more to know about developing with Java/J2EE.
Java technology is so diverse, in its offerings, that one person cannot be interested or know everything about it.
So we wondered, "Who is going to deal with this Java knowledge gap?"
The answer, Subject Matter Experts.
Our Subject Matter Experts are those individuals who have taken on those "knowledge gaps".
This kind of a Subject Matter Expert isn't always the most experienced Java/J2EE developer.
For example, we have Subject Matter Experts in the following areas:
1) HTML and web-browser control
2) unit testing tools
3) source code control
4) deployment and configuration scripting
5) IDE installation and upgrades
6) Java specifications and vendor announcements
7) open source options
8) web services setup
9) messaging services
10) performance measuring tools
11) server environment layout
In each case, one or more individuals has gained theoretical knowledge and practical expertise in a particular area.
This is the person the rest of us go to for answers about and guidance in a particular subject area.
The diversity of Java has always been one of its many strengths.
Our Subject Matter Experts allow us to leverage a broad spectrum of what Java has to offer.
Every software development team should have these kind of Subject Matter Experts.
What started out as someone performing "extra duties", became a permanent role for the team.
Our Java Subject Matter Experts have been key contributors to the creation of our Java/J2EE applications.
Having them around, enables our team to be very self-sufficient. A key ingredient to our success.
And the real good news is --- there is always room for another Java Subject Matter Expert.
Bring it on Java!
I am back with more stories about our adventures in the world of Java.
From the distant past to recent events. I hope to entertain, enlighten, and encourage.
So hold on to your hats.
For software developers in IT, there are times when you find yourself present at the birth of a major application.
Normally these are dream assignments. But consider the following additional factors.
1) You are about to utilize technology that your company has never used before.
2) You have no in-house expertise with this technology.
3) You have no clear ideas on which "best practices" to adopt.
4) The application you create will be very visible inside your company.
This now looks like a very risky project.
Who in their right mind would undertake a project of this nature?
I could be describing a scenario taking place at this very moment.
Software developers are constantly hearing about new technologies and changing technologies.
In our case, this is what we encountered over a decade ago.
Our team was about to create our company's very first Java/J2EE application!
But we had several factors in our favor.
1) Passion to succeed. We were very committed to learn all we could about Java.
2) The functionality for our application was clearly defined.
3) We had outstanding support from the peer groups we would be working with.
4) We realized that we would make mistakes and have to learn from them.
So we decided to go ahead with the project and take a risk with Java technologies.
With a lot of hard work, a little bit of luck, and a lot of passion; our risky venture was a big success!
Our first Java/J2EE application "came to life" and is still in use today.
Would we do it again? Absolutely.
Would we recommend anyone else take such a risk? Of course.
We can't eliminate all risk from the projects we work on.
But if Java is involved; I say take the risk, believe in yourself, and you will succeed.
10 years ago, we began our journey into the world of Java and "J2EE".
It was a big risk for my company, Amway Corp, to do this.
We had no in-house expertise and we had critical applications to migrate to the new technology.
From the beginning, we were determined to succeed.
Today, 10 years after; I can say our Java adventure has been very successful.
We have created two complex applications and have over 1 million lines of Java code in Production.
To be involved in a project that requires the introduction of "paradigm shifting" technologies doesn't
happen often. So it has been very gratifying for me to be part of this work.
For the most part, we were able to do things our way, free from "outside" interference.
We have made some mistakes along the way. But we have learned much from them and moved on.
Our applications have added value to the company and we have many happy users around the world.
Our development team has become very self-sufficient and very confident.
Work continues on our latest Java application. There is still much to be done with it.
I have told the story of our Java adventure from my perspective.
I like to think our success with Java is good for the entire Java community.
Our success with Java contributes to an already healthy Java industry.
For now, I am done telling stories.
Thanks to our esteemed Editor at Java.net, Kevin Farnham, for providing me a forum to tell our story.
Wish us luck in our future endeavors at Amway Corp.
Long live Java!
A few years ago, we met with our business analysts to discuss security for our application.
Our goal was to implement our own authentication mechanism for the web-based or user-interface
portion of the application.
We defined authentication security as "access rights to resources of the application".
After some initial discussion, one of our business analysts suggested we look for an
industry standard to guide us in implementing authentication in our app.
After some research, we came across something called RBAC, Role Based Access Control.
RBAC is an approach to restricting application access to authorized users.
It was first suggested in a paper titled, "Role-Based Access Control" by D.F. Ferraiolo and D.R. Kuhn, D.R. (October 1992).
Today the NIST, National Institute of Standards and Technology, an Agency of the U.S. Department of Commerce;
is an organization that maintains current information about the state of the RBAC standard.
There have been many published papers explaining RBAC theory and practice.
Many variations of the RBAC standard are possible.
We decided to implement a simple version of RBAC.
The RBAC components we used are Roles, Operations, Objects, and Permissions.
Users are grouped together into Roles according to their job function.
Web-pages or screens are identified by their URL.
Screens are grouped together to form various Screen Object Groups.
Screen Object Groups are linked with Operations to create Permissions
Permissions are linked to User Roles.
Individual user information is stored in a LDAP file. All other RBAC data is stored in database tables.
We created a Helper class, UserAuthentication, that contained the authentication-related methods:
- build authentication data object
- retrieve authentication info from data object
- check for user in LDAP group
- get list of permissions for user
- check if user can access URL
Each time a user attempts to access a web-page\screen, the application calls a method in
UserAuthentication to determine if the user will be allowed access to the screen.
Maintaining the RBAC data, in the database, is accomplished thru a series of data entry screens.
Reports can be generated by the app to list all of the authentication info stored in the database.
When a new screen for the app is created, its URL is placed into a Screen Object Group.
New users of the app are placed into a User Group or Role.
New Roles are defined when needed.
New Screen Object Groups are created when a new Permission is required.
That's it. An all-Java implementation of a security industry standard, RBAC.
Done without the aid of third-party API's or products. All is safe and secure!