Month: September 2004

Maintainable Software by Inheritance of Responsibility

What is software quality all about?

In general quality means:
– That it works according to the specifications.
– It’s maintainable.

Who is responsible to meet these goals? It’s the developer and tester.
If you have a sound specification it’s easy to measure whether a software behaves according to the specifications.

The second goal is more difficult to achieve.
How can one determine whether a software is maintainable?

In general a developer should feel responsible for his/her code. This can be supported by not interchanging developer resources on a particular code or component. It is encouraged for instance by the Microsoft Solutions Framework (MSF) Team Model. Responsibility is important for a projects success.

But no developer stays in a company forever. And when he/she leaves the company it’s really getting visible whether a software is maintainable. The successor decides whether it is or not.
You might have experienced that: Usually code written by an other person is suspicious to a developer.
To avoid this responsibility is the key. In order to give software a future, responsibility has to be inherited from one person to another.

But how to achieve that?
Feeling responsible is nothing that can be decreed from outside. Responsibility grows inside a person.
In order to make a person feel responsible he/she has to feel confident with the code.

It helps if the code is well documented and more important clearly structured.
The person really has to understand the intention of the developer who created the code.
It might be a good idea to refactor existing code together with the successor and simplify it’s structure so that he/she really understands it.
Give enough time for hand over (weeks not days). It’s not sufficient just to pass the documentation and say good bye as it often happens. This can’t be enforced by the developer itself but the management which has to schedule it.

You will be good adviced to inherit responsibility in order to create maintainable software.

What is your opinion?

Document Based WebServices

An interesting article Patterns and Strategies for Building Document-Based Web Services was posted on the Sun website which explains important aspects of developing document/literal web services.

The doc/lit encoding is important when it comes to interoperable web services as shown in the WS-I Basic Profile 1.0 and Attachments Profile Version 1.0. Although doc/lit is the preferred encoding most tookits don’t use it by default.

Recently I’ve tried to implement web service attachments in BEA Weblogic Server 8.1.SP3. Although it should work, it didn’t. The problem is that the ant tasks did not emit consistent type mapping descriptors and WSDL for the client and server side. At least on the same platform it should work but it doesn’t. That’s a humbling experience.

By now the easiest way to exchange binary data is still the base64binary schema type, which is larger on the wire but can be exchanged without trouble. If the caller of the service knows the mime type of the blob it’s possible to save it in an appropriate manner.

The following code snippet does the trick:

class Doc
{
byte[] blob;
String mimeType; // e.g. image/gif
}

class MyService
{
public Doc getDocument(){…};
}

By this you can exchange binary data of any type. At least until web service attachments work as expected on all major platforms.

To sum it up – if you have to be really interoperable with your web services you need a lot of knowledge about the underlying specs and technologies. The standard examples won’t help you very much.