Author: Wolfgang

Globalflyer Took Off

For the Virgin Atlantic GlobalFlyer and its pilot Steve Fossett to set a world record for the first solo, non-stop, non-refuelled circumnavigation of the world they will have to follow a strict set of rules laid down by the governing body of aviation record attempts, the Federation Aeronautique Internationale.

In actual fact, as Guinness World Records pointed out to us, the fact that it’s a ‘first’ doesn’t in itself make it a record. Therefore, Steve will have to do the circumnavigation faster and higher than any others in order to take an official record. All in all, we think there are at least 3 and possibly up to 7 different records that could be broken with this single flight. We’ll let you know more about which ones when we’ve researched them all through!

The FAI’s rules state that a record attempt like this must start and finish at the same airfield and cross all meridians of the globe. What’s more the course must not be less than the very precise figure of 36,787.559 kilometres (around 23,000 miles) which is equal in length to the Tropic of Cancer. To allow the Virgin Atlantic GlobalFlyer to catch the vital jet stream winds, the FAI rules don’t oblige that record attempts follow the imaginary line of the Tropic itself but simply that the distance flown exceeds it.

That doesn’t mean, however, that Steve Fossett could fly across the Poles. The course must also be kept away from the North and South “Frigid Zones”, defined as being at latitudes of over 66degrees33minutes.

With the Virgin Atlantic GlobalFlyer capable of speeds of over 250 knots (285mph) the flight should be completed inside 80 hours. The route will begin from an airfield in mid-Western United States and will then follow the jet stream winds across the Atlantic to the UK. From there Steve will head south-east across the Mediterranean and the Gulf before turning east towards Pakistan, India, China and Japan. The final leg of the journey will take the plane out over the Pacific towards Hawaii before crossing the west coast of the US and returning to its launch site.

In the course of the epic journey Steve should fly over or near the following major cities: Montreal, London, Paris, Rome, Cairo, Bahrain, Karachi, Calcutta, Shanghai, Tokyo, Honolulu and Los Angeles. He will also cross major flight routes, meaning that keen-eyed passengers on commercial airliners may be able to spot the Virgin Atlantic GlobalFlyer as it flies several miles above them at around 45,000 feet

Whidbey Nomination

One of my customers was nominated for the Visual Studio 2005 (Whidbey) Ascend program. Even better they asked me to support them. The task is to migrate a JSP/Tomcat application to ASP.NET 2.0 using a lot of the new features.
Part of the ascend program is a special VS.NET 2005 training to prepare the participants for the work with the new tools.
As I missed the one in my area I’m going to attend in Milan/Italy in March.
By now I’ve already been working with the VS.NET 2005 Beta. I think the new features are great.
VS.NET 2005 will certainly be one of the the most productive development tools on the market.
A lot of code, e.g. for login or user management, written again and again for every application will be part of the ASP.NET framework. The framework is very extensible and open. Therefore it’s possible to embed this technology within existing applications.

I like J2EE technology very much, especially on the server side. But the client side rich clients and web applications seem to be the domain of Microsoft technology. In my opinion often the ideal technology mixture would be J2EE (EJB, JMS, etc.) on the server and .NET (Winforms, ASP.NET and of course Office) on the client. But only a few companies realize that as they prefer either J2EE or .NET. A lot of people are somewhat biased in terms of the “other” technology.

Be that as it may. I look foward to telling you in the future about my migration experiences and of course the pitfalls that every technology comprises.

Long Is Not Long

If you need to be interoperable with your Web Services you have to follow a lowest common denominator approach.

Currently I experienced an example as I tried to call a Java Web Service from VBA through a COM Wrapper and .NET (VBA->COM->.NET->SOAP->Java).
I used an long type (64 bit) in the Java Web Service interface. When I included the COM Type Library in Winword I recognized a non supported Variant type for this parameter.
Unfortunately a long in VBA is 32 bit. The Web Service died on the last mile to the client.

Web Services and Null Values – Part III

As mentioned in Web Services and Null Values – Part I-II one should not return a Java wrapper type, e.g. Boolean, from a Web Service as this type is modeled as xsd:boolean in the WSDL file.
If the service returns a null value for an xsd:boolean the caller might get in throuble.
In .NET it’s not a problem to return a Boolean because it can’t be null. That’s because Boolean is a value type.
Whereas in Java boolean and Boolean are different types in .NET they are the same System::Boolean.

Java

boolean (native)
Boolean (java.lang.Boolean reference type)

C#

bool (System.Boolean value type)
Boolean (System.Boolean value type)

Web Services and Null Values – Part II

If you need to transfer an parameter in a Web Service message for which null is a legal value always use a custom complex type.

Assume you have the following Web Service method:

public bool isCompany()
{
    return true;
}
If the requested information is not known it might be good idea to use Boolean instead of the native type boolean like in the following code snippet:

public Boolean isCompany()
{
    return null; // that means unknown
}
Here null is returned to indicate that the information is not known.

If you generate the WSDL from this code you will get an xsd:boolean on the wire. The result is the same for Boolean and boolean.
That means in XML the boolean value is not nullable anymore.
If you want the transfer a nullable type wrap it in a complex type:

public class WSBoolean
{
    public boolean;
}

public WSBoolean isCompany()
{
    return null; // that means unknown
}

I experienced this behaviour on BEA Weblogic 8.1 SP3, but I expect other frameworks/platforms like .NET or Websphere to behave in the same way.
If you wrap your nullable types you are on the safe side.

Interoperable Web Services and Null Values

The meaning of a null is “value not set”. Apparently it is a difference whether you say the credit limit is zero or not set. Therefore sometimes it is necessary to convey null values over Web Services.
Luckily Web Services provide the means to express null values.
Assume the following Web Service method:

public String getName()
{
    return null;
}

The reponse in the SOAP Message uses the xsi:nil=”true” to express the null value on the wire.

This is fine as long as we use certain types as e.g. strings.
But if we use types which have a different representation on different plattform we might run into problems. Even though they are represented by a legal XML Schema type.
For instance the java types java.util.Date and java.util.Calendar are reference types on the Java platform.
The equivalent type System.DateTime is a value type on the .NET plattform which can’t be null.
If a reference type set to null is returned from a Java Web Service it causes a System.FormatException on the .NET plattform.
As the SOAP reponse is valid it seems to be a bug in the .NET implementation.

To avoid the problem wrap the reference type in an complex type as follows:


public class ServiceCalendar
{
    public ServiceCalendar(Calendar date)
    {
        this.date=date;
    }

    public Calendar date;
}

public class Service
{
    java.util.Calendar cal= new GregorianCalendar();

    public ServiceCalendar getDate()
    {
        return new ServiceCalendar(cal); // or return null;
    }
}

Enjoy

Interoperable Web Services and Null Values

The meaning of a null is “value not set”. Apparently it is a difference whether you say the credit limit is zero or not set. Therefore sometimes it is necessary to convey null values over Web Services.
Luckily Web Services provide the means to express null values.
Assume the following Web Service method:

public String getName()
{
    return null;
}

The reponse in the SOAP Message uses the xsi:nil=”true” to express the null value on the wire.

This is fine as long as we use certain types as e.g. strings.
But if we use types which have a different representation on different plattform we might run into problems. Even though they are represented by a legal XML Schema type.
For instance the java types java.util.Date and java.util.Calendar are reference types on the Java platform.
The equivalent type System.DateTime is a value type on the .NET plattform which can’t be null.
If a reference type set to null is returned from a Java Web Service it causes a System.FormatException on the .NET plattform.
As the SOAP reponse is valid it seems to be a bug in the .NET implementation.

To avoid the problem wrap the reference type in an complex type as follows:


public class ServiceCalendar
{
    public ServiceCalendar(Calendar date)
    {
        this.date=date;
    }

    public Calendar date;
}

public class Service
{
    java.util.Calendar cal= new GregorianCalendar();

    public ServiceCalendar getDate()
    {
        return new ServiceCalendar(cal); // or return null;
    }
}

Enjoy