Message parts


Service definition

Internet now has twenty years of experience with providing services. Initiating a service (the first specification of a service) is usually quite simple, but once it gets users it gets incredible hard to upgrade them: mechanisms to handle interface upgrades are simply missing.

In the XML world, WSDL files are used to describe the service. These combine an end-point (URL) with an operation (function name) and in- and outgoing messages. You can specify alternative end-point sets, usually for the test infrastructure.

WSDL files are already quite complex already, but lack any kind of interface maintenance needs. How do you change the interface? One approach is to require regular reload at URL "$endpoint?WSDL". Without pre-notice, your application may pick-up changes. Nice for developers, horrifying for operations.

An other approach to publish interfaces was implemented by OASIS UDDI (which seems to have stalled) and Apache jUDDI (which is maintained).
TODO: describe differences between UDDI and MSI.

Interface maintenance features

Deprecation cycle
It is always easy to add functionality to an interface, but it is much harder to get rid of outdated interfaces. MSI adds support for deprecation and removal of end-points. Humans can be warned by their client applications that changes are due.
Parallel versions
When the deprecation cycle works well, it gets easier for designers to upgrade their features. Old versions of operations MUST stay supported for some time while newer versions are already available. This gets complicated by XML's traditional use of namespaces.
Client-side sharding
Service-side sharing is common practice: service applications use a key to distribute their data-set over multiple databases, or processing over multiple hosts. When services need to stick to normal society regulations, you will need to distribute and access knowledge based on jurisdiction. But also, you may have separate redundant networks for parts of the data-set. This can be implemented with server instigated redirections (late) or smarter clients (early).
Supported features
The service lists the transport features it supports, like packaging and compression. This may differ per end-point. Read more on the transport of data.
MSI focuses on automated optimizations. One of the best mechanisms to lure people into spending time implementing optimizations, is to differentiate in price. For instance, loading huge data-sets at night PST could be cheaper than at daytime.
Not to be bothered by the development efforts of dozens of developers of client applications, the service will offer debugging and processing logs on request.
Flow control
Per end-point static and dynamic flow control is needed to be able to keep agreed service levels.

TODO: describe each of the ideas on a separate page.

mark@overmeer.net      Web-pages generated on 2023-12-19