Author: Wolfgang

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.

Generic Web Service Interfaces – The Right Choice?

Sometimes I hear the question “Why not decouple the service from the caller by using generic interfaces?”

To better understand this question let’s have a look at the following pseudo code example:

BookingService
{
Flight[] getAvailableFlights(date flightDate, string destination);
bool bookFlight(int flightId);
}

The Web Service BookingService has two methods, which can be called by the clients and is described in an BookingService.wsdl file.
If we would like to add a new method for instance cancelFlight(int flightId) we have to change the caller of the service. In most cases this means rebuilding the client side proxy.

Why not using a generic interface like one of the following:

Generic parameter approach:

BookingService
{
Map getAvailableFlights(Map params);
Map bookFlight(Map params);
}

This approach uses only generic parameters but no generic service operations.

Generic service approach:

GenericService
{
Map execute(int commandId,Map params);
}

This approcach uses the common command pattern. It means the client sends a command id toghether with the required parameters to the service.
Dependent of the command id the service dispatches the call to the service implementation.
In order to add the service method cancelFlight we simply have to add a new command. The contract remains unchanged and the proxy hasn’t to be rebuild.
And even better the parameters can be processed in a generic way. That’s cool, isn’t it?

At first glance this approach looks promising. But at what price?

A common misunderstanding is that the Web Service Signature described in the WSDL file forms the service contract. This is only one option.
More precisely said the name of the service operation (or command id) in conjunction with the required in and out parameters form the contract.
It doesn’t matter where this information is stored.

What really happens when using generic interfaces is that the contract is shifted from a standarized to a custom layer.
That means the contract is not described in the BookingService.wsdl file anymore. Now the service and the caller need a proprietary way to describe and exchange the contract.
Moreover the type safety is lost because only generic types are used.
The command dispatching must be implemented. This is usually handled by the Web Service infrastructure for instance by using the SoapAction in the HTTP-Header.
Generic parameter processing is not a reason to use generic interfaces. If necessary reflection can be used to process typed parameters in a generic way, but without loosing type safety.

I think the drawbacks of generic interfaces outweight the benefits.
What do you think?

What have Open Source Software and Cars in Common?

During the recent months I had to deal with several open source implementations like Log4J, Jacorb or Tomcat. While I was happy that it is free in terms of licence cost I was unhappy about some other issues that campe up when using it in an productive environment.

To make things clearer it sometimes helps to use an analogy.
In many aspects the use of software is similar to using like for instance a car or a hifi-system.

So what would you expect when buying a car? (at least I’m expecting that)
A .It should bring you from A to B in a secure and fast way.
B. It should be reliable and error free.
C. If an error comes up the garage should fix it as fast as possible.
D. The price/quality ratio should be reasonable.

Does it really matter, how the car works under the hood or that you can fix it on your own?
I think for 99% of drivers the answer is no.

The same applies to open source software. The fact that a software is open, semi open or closed source is not really a feature of a software (except of rare mainly academic cases).
The important thing is that the price/quality ratio is good so that it’s worth using it.
In brief the advantage of the features must be higher than the disadvantage of the cost.
I think this it true of all kinds of software.

My advice is as follows:

Use open source software when:
A. You can replace it easily without a lot of effort
B. The price/quality ratio is good in terms of total cost of ownership (TCO – be honest)
C. You are a geek and love it to do everything on your own
D. There is no other solution around

Don’t use open source software when:
A. You need a solution for infrastructure or mission critical applications except you can replace it easily
B. You need professional and guaranteed support
C. The open source software module can break the entire application
D. You have no choice due to your corporate policies

I know that this issue is very controversial – so what do you think?

Weblogic Server Supports WS-Security 1.0

BEA Weblogic Platform now supports the OASIS Web Services Security Specification.

Quote:
Implementation of the Final 1.0 OASIS Web Services Security Specification
WebLogic Web Services now implement the following OASIS Standard 1.0 Web Services Security specifications, dated April 6, 2004:

Web Services Security: SOAP Message Security
Web Services Security: Username Token Profile
Web Services Security: X.509 Token Profile

Although it’s great that Web Service Security ist standarized within a platform, the interesting question is whether it’s possible to connect distinct platforms in a secure manner.
Currently I’m setting up a new study in order to show whether WS-Security is mature enough to connect for instance BEA Weblogic Server 8.1 SP3 and Microsoft WSE2.0. If you would like to get involved in the study please let me know. I’ll keep you informed.