What is an Application Server ?

This is probably one of my most accurate metaphor.

I’ve always found it very tough to explain what is an application server and what is a component even to people that are familiar with software development.
Here is the trick ... In modern software applications, when you want to write a reusable piece of code, it is often called a module or a component. It is also called a “Business component” when it represents a concept of the business domain (e.g. a CardHolder or an Account for a banking system, a Patient or a MedicalAct for health systems, etc.). When you write such a piece of code, you cannot spend 100% of your time just writing “Business code”. You also have to write “Technical code” for many technical aspects :

• Communication (Synchronous or asynchronous) with other pieces of code
• Registration or searching in a directory so that the other components can find you or for you to find the other components you want to communicate with.
• Security management (Who’s who, Access Controls, Encryption, ...)
• Transaction management
• Data persistency (storing or retrieving data from a database).

Even if you rely upon reusable services offered by a framework, you still have to write at least all the lines of codes needed to call the services, check the results, pilot the workflow, etc. All these technical lines of code could represent more than 80% of your total code. Only 20% are just dealing with the real business aspects. Even more painful is that all the other developers that are writing business components also have to write 80% of THE SAME TYPE of technical lines of code. They may not be the exact same lines of code, but it is very likely that we can find some patterns and templates in them.

This is where the component approach and the idea of application server come into play.

An application server integrates a set of standard reusable services and provides the developers with some standard and pre-written code (we call that programming model) to drive these services leaving the developers with the task to write only the 20% of business code. The code that drives the services is called the Container. The only thing you have to do is to configure the container to pilot the services the way you want by choosing among predefined options.


Even for long time software developers this is not something easy to understand. Here is the metaphor I use :
Lets say you want to start your own business (e.g. You want to be a software architect consultant). Do you think you will be able to spend 100% of your time just doing the service you want to sell ? Of course not. You will have to do some marketing, sales activities, invoicing, accounting, cleaning, photocopies, etc. You will probably only be able to spend 20% of your time doing your real business, all the remaining 80% being used to execute administrative and technical tasks but as well as mandatory for your business to run properly.
What can you do to improve your working ratio ?

• Subcontracting is an option. But you’ll still have to spend time to send requests to your sub-contractors, check what they have done and coordinate all of them. Maybe you will now be able to spend 50% of your time doing your core business. Subcontracting is just like reusing non integrated technical services. It is better than rewriting everything but you still have to pilot them.
  
  
• Another option is to jump into a “Business Center” such as Regus for example. In these Business centers you will rent an office for you to work, but you will also find all the services you need in the building. The front desk will receive your visitors and drive them to your office and so they will for all the other visitors of all the other companies of the business center. At the first floor there is a Marketing service that you can use.At the second floor there is an accounting service available for all the companies hosted in the building.When you will integrate such a business center, you will be offered to choose among a set of predefined options for all the services. For example, regarding the Security service, you may choose between :No control: send all my visitors directly to my officeIdentity control : check my visitors IDs and record the informationHigh level Security : Check Ids, record everything, and have a guard accompany my visitors to and from my office.Even more important, you will be assigned a manager that has the responsibility to make all the services run smoothly according to your needs (options). Of course, if you want to start your business in such a Business center, you need :To have standard needs (otherwise the technical services will not be able to serve you)To respect some standards (e.g. you need to use standard forms to communicate your data to the accounting service).

This is it, an Application Server works exactly the same way than a Business center. A business component is just like your own business. The container pilot the technical services based on the options you chose just like the manager pilots the services for you in the Business center. Standard programming models exists in the application server (EJB Session, EJB Entity) just as standard workflows are supported in the business center.

CORBA Pizza Guy

With Corba (or any middleware working in an RPC like model) a client program is able to call a method (operation) on a remote object almost the same way this client would call the method on a local object. This magic is achieved through the use of an object (called a proxy) which is the local representation of the remote object. Another nice thing with Corba is that the client and server programs can be developped using different programming languages.

This technology is not completely obvious to someone new to distributed programming and I often use the following "Pizza guy" metaphor when I try to clearly explain the "Service Reuse" versus "Code Reuse" approach that Corba brings to you.

Say you wan to eat pizzas for lunch.

1. The "Code reuse" approach would be to hire a pizza guy (Luigi) and install him in your kitchen.


2. The Corba style "Service reuse" approcah would be to let Luigi work in his pizzeria and call him when you need pizzas.

Let's first have a look at the drawbacks of the "Code reuse" approach.

• Luigi would take some place in your kitchen even when you don't want to eat pizzas -- Code reuse increase the size of your application.


• Luigi may only speak Italian but not English. You may have some trouble communicating with him. -- It is not easy to integrate some piece of code written in different programming languages.


• Luigi would have to be trained to use your equipments and he may not know exactly where you store your ingredients. -- Reusable components could be hard to integrate with your environment.


• When Luigi is sick or when he starts to be too old, you will end in trouble should you want to fire him... -- Integrated code requires maintenance and evolution too.

How does it works with the second approach? Well, with Corba, yo will need to instanciate a local representation (in your kitchen) of the remote pizza guy (Luigi). It would be an hologram of the real Luigi. Here are the consequences :

• The hologram takes far less place than the real Luigi - A proxy is a small object.


• You can talk to the hologram in English even though the real Luigi only speaks Italian. Your request will be translated. -- You can call a C++ object from a Java program.


• The only thing you need to know is what king of request Luigi's hologram is able to understand. -- You only need to know the IDL of the remote object.


• The hologram and the real luigi can decide which communication technology they want to use (Telephone, Fax, eMail, Pigeon post, semaphor, etc). You don't care as long as it works. Corba may rely on various low level communication protocols.


• When Luigi is sick, the hologram may transparently redirect your request to another pizza guy -- Falt tolerance.


• When Luigi is overloaded, hologram may transparently redirect your request to another pizza factory -- Load balancing.


• When you don't eat pizzas, Luigi can work for someone else. -- You can optimize your IT resources by sharing the same service with multiple applications.


• When Luigi is getting old or becoming too expensive, he can transparently be replaced by a cheaper and more efficient pizza guy. You would not even notice the change. -- As long as the interface does not change, service maintenance can be easily performed.

There is a lot more to say with this metaphor. Just try it if you happen to teach Corba...

SCRUM's Product Backlog

This metaphor belongs to Greg Hutchings.
In order to illustrate what is a product backlog and, moreover, the type of collaboration that must happen between the product owner and the development team, Greg uses the image of a car owner taking his car to a garage.

You, as a car owner, have your own idea on what must be fixed on your car and you own the budget which constrain you to prioritize these tasks. You may decide that your first priority is to fix the front wings rather than the breaks ;^)

But it is the garage mechanic responsibility to tell you to move to the top of your backlog some tasks that you first thought as secondary tasks. Because he is an expert, it is up to the garage mechanic to provide information (assumptions, constraints, alternatives) to the car owner in order to help him or her prioritize the features.
But at the end, the car owner must make the call. He has the right to decide where it worth spending his money...

I first thought that this metaphor was more accurate for maintenance projects than for develoment projects but, I now see it as a great illustration of the collaboration that must take place between the product owner and the development team in a Scrum project.

Thanks Greg.

SCRUM or HUDLE

The Rugby SCRUM is generaly used to illustrate the SCRUM Agile software development methodology.

Although, it is nice to convey the idea of teamwork getting its strengh from all people working together in the same direction, I've found some limitations to the metaphor.

• It is only a question of weight, strength and technique. The power of the Scrum has little to do with strategy or tactics.
• Where is the Scrum Master ? It could possibly be the 1/2 de mélée. Is he facilitating something?

Well, a metaphor is always a non perfect representation of something different and we could argue a lot about the adequacy of the rugby Scrum...


Although I'm a big fan of Rugby, I would like to share with you some reasons why I strongly prefer the American Football Huddle to illustrate the SCRUM method.


Here are the points:

• The Huddle is a short meeting before the play where decisions are taken based on the current situation, just like the daily scrum meeting. At that time, the team can decide to go for a field goal, a run or a long pass.
• The quarterback is similar to the Scrum Master even though he is more a decider than a facilitator.
• The coach could be the Product Owner, deciding the next sprint objective.
• The 10 yards goal is the timeboxed sprint.
• The team has 4 downs to win 10 yards just like a software team may use 4 iterations to achieve the sprint.
  
• The strengh of the team comes from the mix of multiple roles and skills (QB, RB, HB, OLM, OG, OT, ...) all collectively responsible for the succes of the play.

As I said, it's just a metaphor. It's not perfect and you are welcome to give your two cents...