Prevent Enum in Java XML Web Services

Question

I love Enum for the type safety and also it makes code much more readable. I always make use of Enum whenever I get the chance.

Problem started when I need to expose these codes as web services. For example, if I have an enum like this:

public enum Language {
    ENGLISH(1),
    BAHASA_MALAYSIA(2);
}

It will be exposed in wsdl as this:

<xs:simpleType name="language">
<xs:restriction base="xs:string">
  <xs:enumeration value="ENGLISH"/>
  <xs:enumeration value="BAHASA_MALAYSIA"/>
  </xs:restriction>
</xs:simpleType>

If in the future if I decided to add a new language I will be in trouble, the wsdl file will be different and it will break older clients.

My question, how do I prevent the enum be exposed as enum in wsdl? I want it be exposed as simple datatype either String or int.

I am using JBoss WS if that matter.

Wouldn't your clients still break? Not knowing how to handle the new values, no matter how they are encoded? — biziclop, May 19 '12 at 11:36
It is the value that change, not the wsdl, so a good client should be able to handle that. Say if I start returning `3` for `FRENCH` and the client does not understand that, they should handle that gracefully (by defaulting to `ENGLISH` for example). But if the wsdl changes their code will break until they rebuilt their proxy code. — Rosdi Kasim, May 19 '12 at 11:46

score 6 · Accepted Answer · answered May 19 '12 at 12:37

6

If in the future if I decided to add a new language I will be in trouble, the wsdl file will > be different and it will break older clients.

No, it won't break older (well constructed) clients. Adding values to an enumaration can be considered a backwards compatible change. See articles like Extensibility, XML Vocabularies, and XML Schema.

From what your telling I'm guessing your working code first and let JBoss-WS generate the WSDL and XSD. There is nothing wrong with that. However if backward and foreward compatibilty is such a big concern to you you should work contract first (ie. design the WSDL and XSD manually). Because you never know what WSDL's and XSD's newer version of JBossWS are going to look like.

If you really want JBoss-WS to generate something different then an enumeration you need to look into JAX-B. JAX-B is what the actual XSD generation does.

answered May 19 '12 at 12:37

Jasper Siepkes

1,412
16
25

Yes I indeed doing code first then let JBoss WS generate the WSDL. Come to think of it your answer makes perfect sense... I got to test this out. – Rosdi Kasim May 19 '12 at 15:50
I'm having trouble understanding how contract-first helps in this situation. If the resulting WSDL file contains enumeration types then you still have the same problem where outdated clients will break if new values are added to the enumeration type? Or are you would not define it as an enumeration type in the WSDL and use a standard string instead? – craigrs84 Aug 05 '14 at 16:06
@craigrs84 Those are 2 separate things. First of all adding enumerations is a backwards compatible change as stated. Sure poorly constructed clients can break but besides making multiple different versions of the same endpoint there is not much you can do about poorly constructed clients. Second if you want to guarantee a consistent endpoint you should work contract first instead of code first. I would advise against using a string; Use enumerations when appropriate and too bad for poorly constructed clients. – Jasper Siepkes Aug 05 '14 at 19:39
If you send a new language to an old client, it will crash. So it's not forward compatible. – Matsemann Sep 05 '17 at 10:45
"If you send a new language to an old client, it will crash. So it's not forward compatible." If it is an enum you only accept in a request it's a forward compatible change. But yeah, if you start sending it as a response it could cause problems with older clients. – Jasper Siepkes Sep 08 '17 at 09:39

Prevent Enum in Java XML Web Services

1 Answers1