Web Services Language

Language

We noticed in web environments at minimum these languages:

• C#
• C++
• Java
• JavaScript (AJAX)
• Perl
• PHP
• Python
• Ruby
• VBScript

If you now think about which language you should choose then you should not only think about the features of the language. You should think about the complete coding environment and the operational aspects of the final system. What does this mean?

Coding environment

The decision about the coding environment is mainly driven by the requirments of the final system and the avaible experience of the the developers. The final system usually comprises of several layers and other more or less isolated components which must be tested and fulfil several specifications. Sometimes a framework is already part of the specification. If you take all this into account then there are usually not so many choices.

Another important thing to mention is the type of the developed or used code (if you use framworks). Always prefer configuration instead of code. Configurations are more easily to maintain then source code. If there is some fluctuation in the team then it is much easier to solve an issue if you can teach a developer about a framework and then let him work on a configuration.

Whom do you trust? If you found some tool chain candidates then there are some question. Who is the best one is definitley the wrong question. Better questions are:

• How does they meet the technical requirements?
• Whom do you trust? No, you should not think about encryption and such stuff. You should think about how you can rely on the tool chain provider? Commercial companies can stop product lifecycles. Open Source projects can die or have poor support. You must evaluate the tool chain provider at minimum at the same level like the tool chain itself.

If you now start looking for a perfect solution then you can immediately end your search. You will never find this solution. If you find a tool chain which supports all new technologies then it is usually some kind of buggy, always missing some interesting features and the interfaces are changing permamently. If you use a fully stable tool chain then the newest technology is not supported and perhaps the support ends some day. So you must define your criterias and then you and nobody else must make a decision.

Operational Aspects

Usually programmers start discussing about the tool chain and this is often the core of problems in production environments. Programmers think different as operators because operators and have different tasks and problems. Operators think in terms of maintenance, support and processes.

Maintenance - who can do it? Who want to do it?

Support - Levels (SLAs)? Which support is possible? How does the support works? If the programmer supports the software by himself then which levels of support are available? Which type of support is requested? Developer support? Complete ASP including end user support?

The most problematical question is, what do we expect in the future? Do the tools be still available? Does there be the same levels of support for the tools be available? The most important question is usually, can I expect that my partners are still be available?

Processes - even if you cannot believe, every production system knows processes. If you always boot your server if somebody reports a blocking tomcat then this is a process - not a nice one but a process. Process integration is highly important and cannot be answered with "I introduce a java design which uses SOA that can easily adopted by others". What happens if "the others" are a Perl based infrastructure which communicates over a file system based protocol which is published by NFS? The architecture can be service oriented but has nothing to do with Java, SOAP or any other of the todays buzzwords. So you must analyze the sytem environment and you must understand the surrounding processes.

If the data center implemented something like an ITIL based management approach then you have to check the interfaces of the different processes. Usually the processes already implement managenent interfaces. BTW ITIL defines what you have to implement but not how.

The last point which I want to bring to your notice is the re-use of technology. The most projects are not isolated and not every project start discovering technology from scratch. If you need infrastructure then look for projects or systems which can share infrastructure and reduce costs but rising availability because you have a harmonized support and knowledge base (e.g. must everybody setup its own tomcat or does it makes sense to have a central unit which does this). Beware of the NIH syndrom.

If you now think that you find more queries than answers then you are right. We do not want to write a book we only want to provide you with some ideas here where to start. Additionally here should be a short conclusion.

 So do not decide about a language only, decide about tools and frameworks at the same time too.