CODEWITHSUNDEEP
web-serviceswsdlxml-namespacesorganization
Chris Welsh
Chris Welsh

Reputation: 349

Need some recommendations for WSDL namespace practices to cope with changing company names?

As someone who has worked for a company that has changed it's name (and hence domain name) at least three times over the last few years, the practice of namespacing our java code with com.[company].[product].[function] etc has meant frequent refactoring (or just living with odd looking java namespaces).

However, we're now publishing WSDL services as well, and they are also namespaced in a similar way. Here, the impact of a domain/company change is much more serious, as we can't change the namespace on a whim.

What are some recommendations for namespacing our services?

Upvotes: 1

Views: 377

Answers (2)

bmargulies
bmargulies

Reputation: 100051

The internets are full of java code with packages that exhibit that old principle: "Ontology recapitulates phylogeny." In other words, they have package names that reflect ancient corporate history.

Your goal here is confict-avoidance, first, and marketing second. So, I'd suggest that you register a domain name that is not the company name but is more or less descriptive of the code, and use it. Then, when the inevitable bigger fish comes along, the names are unperturbed.

The urn: suggestion is neither here nor there. If someone runs a code generator, whatever URI you use is going to be mapped to a Java package name or a C# name or whatever, and if that collides with some other name, it will be, of course, "the death of the internet as we know it."

Upvotes: 1

user159088
user159088

Reputation:

Use simple URNs ...

... like urn:OrderService, urn:BookSearchingService, urn:TradingService etc, something that signals what the service is doing. Your company (whatever its name is today) offers such a service (e.g. book searching), and that should be enough (don't stamp the company names all over the place).

Adding company name or project name to a public namespace can cause problems such as the one you mention. Sometimes you can refactor and change the names sometimes you can't.

In case of a Web Service you will break your clients if you refactor because messages comming from the old clients will not validate against the new namespace. You will have clients on the new namespace and clients on the old one. Repeat this a couple of times and it becomes frustrating remembering which is on what version of the thing...

Project name is also problematic. What happens if the company uses a name which is a trademark of another company which sues you and then the law says you can no longer use the name? You have to change the name and in this case you are forced to refactor and make all your clients upgrade to the new namespace. This is not good for business... you loose face.

For this reason, use a namespace that identifies what the web service is offering as operations.

Upvotes: 3

Related Questions