subbu.org » soa

Service API Design – Context vs State

Subbu Allamaraju — Sun, 24 Dec 2006 20:45:26 +0000

Carlos Perez at manageability.org posted an interesting discussion on OO-styled interactions, and I can’t agree more.

It is very common to find most people listing statelessness as one of the key principles of service API design. Statelessness is an overloaded term. To my experience, when someone says that a service is stateful, he/she usually means that the service maintains some internal state. We can argue all day long on whether maintaing state is good or bad – the answer usually depends on what the service is doing. In most cases, whether a service needs to maintain state or not is a service implementation choice – service users do not need to know or care about it.

From the client’s point of view, statefulness of a service usually implies that interactions with the service need to happen in some sequence to be meaningful, i.e. the client maintains some context with the service it is interacting with. Context is what a client should care about – not about whether the service is stateful or stateless.

Shared context makes service invocation interesting and meaningful. The service needs to define the context which may then be updated by the service or the client, and may even include references to any internal state maintained by the service itself. Services that don’t require any client-managed context are usually general-purpose utility services. Most usuful services need to depend on some share context to be useful. Context is what makes it possible to break a task into sub-tasks and let the client invoke sub-tasks in some defined sequence.

Some designers may prefer combining shared context with the inputs and outputs of service invocations. IMO, keeping the context separate from the data being processed and returned makes the service interface definition lot more cleaner, easier to understand, and extend. One problem with most programming models used for implementing services is that they don’t provide for shared context. For instance, take stateful EJBs. They are becoming extinct (rightly so) because they emphasize on the stateful nature and not on the shared context. With stateful EJBs, sharing the context meant that the client held onto the bean till the work is done. That is not the same as the shared context. Unfortunately, later layers like Java web services extended the same notion, and don’t provide for shared context within the supported programming models. You can easily bind a web service implementation to a class or a EJB, but you need to invent your own mechanisms for supporting shared context. Then there is the Web Servces Composite Application Framework, but I don’t think that is what service developers really want to worry about.

This also reminds me of The Need for Shared Context by Anne Thomas Manes, which argued for the need for defining a shared context.

Another harmful aspect OO-styled interactions that Carlos did not mention is idempotency. One of the problems with object-oriented development is that it is difficult to tell whether a given service invocation is idempotent or not.

A Case for UDDI Registries

Subbu Allamaraju — Sun, 19 Mar 2006 18:58:28 +0000

Here is a realistic application of UDDI registries. This one is not
imaginary, and is not driven by a need to somehow use a registry to get
SOA qualified. Moreover, you may not find this use case prominently
anymore in white papers and brochures on UDDI registries.

In the past, I have blogged about the

hype around registries, repositories and SOA, and I have been

quoted for that. But now, I am about to describe a use case for which
using UDDI registry makes sense. This is one of the few use cases where
finding, and consuming business services at runtime (and not design time)
is possible. In this case, users search for services, select services, and
start using them almost immediately. Please be warned that this use case
does not involve any of the following use cases that registries have been
touted for:

Dynamic routing of service requests
Enforcement of policies
Controlling the integrity of services published
Governance

My use case is more basic than all of the above. Here it is.

A developer writes a an app with a web-based UI, and deploys it.
A user wants to find and it and use it.

In this use case, the app is a portlet, and the user is interested in
finding portlets based on some metadata, and using them. The user is not
interested in understanding the interfaces for services, or their
semantics, or designing software to use services. The user may be a
typical web surfer, or an administrator creating portals. Here is how UDDI
helps solve this use case:

The runtime hosting the app publishes the app as business service in a
UDDI registry. Note that the app is not a web service.
User searches against the registry using some high-level UI. The UI
presents portlets.
When the user finds a portlet that he/she is looking for, the user
will aggregate it into a portal page, and start using it right away.

As I have argued

previously on this blog, most typical service clients can not take
advantage of dynamic discovery of web services through a UDDI registry.
The reason is that most web services are tailored to to specific business
use cases, and a developer needs to know about the service at design time.
The developer will have to look up the WSDL, the schema for messages, and
some other documentation to understand the semantic meaning of each and
every detail of the service.

However, in my use case, the services and the clients are generic, and in
most cases, users can use a service as soon as finding one. Here is how:

The business service in my use case is a portlet. A portlet is usually
an app encapsulating some UI, business logic and data.
The runtime for portlets (a.k.a portlet producer) supports

WSRP, and can offer portlets over web services to any client
supporting WSRP.
The producer publishes each portlet as a business service in a UDDI
registry. The producer can do this behind the scenes without requiring the
portlet developer/deployer understand UDDI.
The client is a portal or an application (a.k.a. consumer) that can
aggregate portlets into web pages. The client implements WSRP.
When a user searches for portlets, the consumer searches the registry
for matching business services, and presents the results as portlets.
The user aggregates portlets found into web pages.

In this use case, both the service and client are generic, and that is the
key to publishing, finding, and using services dynamically at runtime.

I must say that I’m quite excited about supporting this use for the next
release of

WebLogic Portal due to be released in a couple of months. Prior to
supporting this use case, finding portlets was not very easy. Let’s say,
portlets are hosted in a number of producers. Each producer offers a
WSRP-compliant WSDL, and one of the operations in the WSDL can be used to
fetch a list of portlets available on a producer. To search for portlets,
the user will have to go through this list from each producer. This can be
tedious if the number of portlets is large. UDDI helps simplify this use
case. By mapping portlets into business services, and publishing them into
a registry, the problem is much simplified. Instead of browsing lists of
portlets, users can type in keywords or other criteria to search for
portlets. To help this use case, the WSRP TC released a

technical note that describes a mapping portlets and portlet producers
into services that can be published into

UDDI or

ebXML registries.

There are few issues that may stand in the way of using portlets found in
a registry immediately. In some cases, the user may not have enough
privileges to use a portlet. In other cases, the user may require the
assistance of administrators to help meet the security policy requirements
of portlet producers. But once these infrastructure issues have been
related, finding and using portlets is as easy is getting some plumbing
help via yellow pages.

Despite this simplicity, I don’t imagine emergence of global portlet
registries. The main reason is that a portlet registry makes sense when
there are a large number of remote portlets deployed, and typically such
deployments may be limited to large enterprises. Secondly, there are still
issues around security and other quality of service, and these require
out-of-band negotiation in most cases.

SOA Definition

Subbu Allamaraju — Fri, 27 Jan 2006 12:22:57 +0000

Given the frequent appearance of the word “SOA”, I would expect that whoever is “doing” and “preaching” SOA must know very well what SOA is all about. But it turns out that most people are confused about the “definition” of SOA. Check JP Morgenthal’s Enterprise Architecture: The Holistic View: The A in SOA is Architecture.

So my question is “what exactly are you doing when you say you are doing SOA?” Or, are you calling whatever you are already doing as SOA? Hmm. Is that why SOA is now called a strategy and not a technology?

Real World Vs. Buzz World

Subbu Allamaraju — Sun, 04 Dec 2005 20:22:37 +0000

My thoughts after reading a lot of blogs and articles on SOA that appeared this year.

Real World

XML, XSD, SOAP, WSDL, WS-*, APIs, Platforms, Tools

===> Seperation of concerns, Granularity, Complexity, Performance

=====> Code

Buzz World

Service oriented, Loosely-coupled, Dynamic, Coarse-grained, Agile, Efficient, Reuse, Composite, Ecosystems, Symbiosis (yes, some blogger used the last two words recently).

===> Vapor

======> More vapor

e-Nough. Let me get back to the real world.

Web Services Versioning – Part 2

Subbu Allamaraju — Sun, 21 Aug 2005 21:18:00 +0000

Several months ago, I blogged
about versioning of web services. Between then and now, I realized that versioning of web services is a very nebulous topic, and that the problem of versioning could test the motivation of even the most committed web services architect. In this post, I would like to take the next step and discuss some possible ways of versioning web services. In this process, I would like to answer two questions:

How to version the public view of a web serice, i.e. the WSDL?
How to make web service implementations support versioning?

Before I get too far in this discussion, let me clarify that in some situations it may be perfectly acceptable to not support previous versions of a web service, i.e. break backwards-compatibility. For instance, between close-knit applications, it is possible to make changes to both the service and its clients at the sime time, and avoid the question of compatibility altogher. On the otherhand, there are cases where the web service and its clients cannot be upgraded at the same time for a variety of reasons. I would argue that the more popular and useful your web services are, the more difficult it would be to make simultaeous upgrades to clients. In a loosely-coupled enterprise, such a big-bang migration should not even be required. For a certain period of time (if not indefitely), the service implementation may be required to support multiple versions of its interface at the same time, just because some of the clients have not chosen to upgrade.

Since web services carry XML messages, it would seem logical that recognizing the version of an incoming message is adequate for building a web service that can support multiple versions of the services it offers. For instance, a web service could accept two kinds of messages, with each message described by a different schema. The problem is then to version those
schemas, e.g. as discussed here.

|-------------|
----->{Message m1/Schema v1}----->|             |
| Web Service |
----->{Message m2/Schema v2}----->|             |
|-------------|

The web service could, at least in thoery, examine the message, and depending on the version, or the presence/absence of certain elements/attributes in the message, could support multiple versions of the service using the same implementation. For those bothered with versioning, this is the most ideal solution. However, in reality, current web services related standards and tools make it difficult to support such a simplified solution. Firstly, SOAP and WSDL’s view of web services is more complex than the simplified view above. Secondly, web services programming standards like JAX-RPC (or JAX-WS as JAX-RPC is called now as) and JWS do not consider versioning either.

WSDL Versioning

Since WSDL is the de-facto standard for specifying web service interfaces, the first problem to tackle is versioning the WSDL. WSDLs have service bindings, port types, messages and types. Messages are constructed using elements of types, ports specify operations with input/output messages, bindings bind operations to a protocol, and finally services associate bindings to a network address. Therefore, you must start the versioning exercise from the types used in the WSDL, and then extend it to the WSDL level.

Let me start with a simple web service that creates a new employee.

where the imported file contains the following.

Given employee details, this web service creates an employee. In this WSDL, I defined the bindings, messages, and types in another WSDL file. Except for the “hello world” kind of web services, I find it convenient to split the WSDL into smaller chunks and wire them up together by using imports.

Extending the example used in my schema versioning post, let us add a country field to the address of the employee. As I discussed in that post, adding a country to the AddressType requires creating a new EmployeeType, and we cannot use schema extensions (i.e. via xs:extension) to add this element. We need to create a new schema and add the country to the AddressType in the new schema with a new namespace URI that reflects the new version. Here is my new schema.

From the WSDL’s point of view, we also need to define new messages, port types, and bindings, since the same set of messages/port types/bindings cannot be used to carry messages from two different schemas.

Here is the new WSDL.

Here is the imported vs_bindings.wsdl file.

By choosing to define a new schema for the types for versioning sake, we, in essence, defined a new set of messages, port types, bindings, and a new WSDL port for the versioned operation. At the WSDL level, this is as far as we can get for introducing a new version of a web service. To summarize, the following are the steps for versioning a WSDL.

Define new or extended types for changes in types in a new namespace.
Define new messages.
Define new port types and bindings.
Add a new service or new ports to an existing service in the WSDL.

For the client, this approach means that, it must choose the WSDL port based on the version it can support.

|-------------|
----------|             |
----->{Message m1/Schema v1}----->| Port v1 |             |
----------|             |
| Web Service |
----------|             |
----->{Message m2/Schema v2}----->| Port v2 |             |
----------|             |
|-------------|

Clients supporting the new version will therefore use new ports, and clients using the old version(s) will continue with old ports.

Implementing Versioned Web Services

I consider versioning the WSDL the easier part of the problem. Once we decide how to version schma types, the rest of the process is simple to deal with. For the web service provider as well as the client, a more difficult problem is supporting multiple versions at the same type. Moreover, web services programming standards like JAX-RPC and JWS have not matured enough to support versioning of web services yet.

It is interesting to note that the latest public draft of JAX-WS 2.0 specification does mention in one of the introductory sections that "versioning and evolution of web services" is one of goals of the specification, but the rest of the specification stays silent on this. I will not be surprised if this goal is dropped from the final diaft of this specification.

Let me now start with the above versioned WSDL. When you generate code from thus WSDL using various WSDL to Java tools, you will essentially get two sets of artifacts, one for each version. For instance, here is a the Java interface generated by Axis 1.2’s wsdl2java task.

public interface EmplManagerService extends javax.xml.rpc.Service {
public java.lang.String getEmplManagerPort_v2Address();

public v2.EmplManagerPort getEmplManagerPort_v2() throws javax.xml.rpc.ServiceException;

public v2.EmplManagerPort getEmplManagerPort_v2(java.net.URL portAddress) throws javax.xml.rpc.ServiceException;
public java.lang.String getEmplManagerPortAddress();

public v1.EmplManagerPort getEmplManagerPort() throws javax.xml.rpc.ServiceException;

public v1.EmplManagerPort getEmplManagerPort(java.net.URL portAddress) throws javax.xml.rpc.ServiceException;
}

This interface has two different sets of methods one for each version. From the WSDL-to-Code translation point of view, this interface is valid, and is to be expected. However, from versioning point of view, the developer implementing this interface will have to deal with supporting two seperate code paths, one for each version, and that makes it supporting versioning more challenging.

For example, take the implementation of v1.EmplManagerPort.

public class EmplManagerPortImpl implements v1.EmplManagerPort
{
public java.lang.String createEmployee(v1.EmployeeType createEmployee) throws java.rmi.RemoteException
{
// Validate the employee object

// Create the employee record in a DB

// Return the employee ID
}
}

In order to support the new version of the WSDL, you will need to create an implementation of v2.EmplManagerPort.

public class EmplManagerPortImpl implements v2.EmplManagerPort
{
public java.lang.String createEmployee(v2.EmployeeType createEmployee) throws java.rmi.RemoteException
{
// How to implement this?
}
}

The question is how best to create this implementation. One of the most obvious answers is to simply duplicate the code. You may even be able to share some code at a lower level, but code dealing with schema types will have to be duplicated. So, the downside of this approach is maintenance of two versions of the software with different source code.

|-------------|
----------|             |
----->{Message m1/Schema v1}----->| Port v1 | Web Service |
----------|             |
--------------
----------|             |
----->{Message m2/Schema v2}----->| Port v2 | Web Service |
----------|             |
|-------------|

Subsequent versioning only worsenss this duplication, and leads to more code maintenance nightmares.

Here are some choices that, though take considerable effort to build, would address versioning given the current state of support in web services standards.

Message transformation and Routing
Common layer for version-indepent types and business logic

Let me elaborate on these approaches.

Message Transformation and Routing

I have explored the idea of transformation of XML documents from one version to another in one of my previous posts on processing versioned XML documents.

|-------------|
-------------    |             |
----->{Message m1/Schema v1}----->| Transform |    |             |
-------------    |             |
|          | Web Service |
|          |             |
----->{Message m2/Schema v2}---------------------->|             |
|             |
|-------------|

The core idea is to somehow transform v1 messages to conform to the v2 schema, and then route messages targeted to v1 port(s) to corresponding v2 port(s), such that the same code path can be used for both versions. For such a transformation and routing, you may need some extra plumbing not often found in most web service stacks. In these web service stacks, such message transformation can only happen before a message reaches the server, but not afterwards. For example, in JAX-RPC based web service stacks, the first entry point for programmatic manipulation of an incoming SOAP message is a JAX-RPC handler. But in JAX-RPC, handlers are associated with specific ports, and you cannot change the message after the web services runtime already bound the message to a given port. Doing so would most likely cause subsequent message processing to fail.

One possibility is to build a proxy server (or use a SOAP intermediary) to transform SOAP messages to conform to the latest version, and route the messages targeted to v1 ports to corresponding v2 ports. Most products offering web services management frameworks/tools provide some degree of transformation and routing capabilities. It would be interesting to see if such products can be put to use to solve web services versioning.

Common Data Abstraction Layer

Another possibility is do the transformation within the application implementing the web service.

|-------------------------------------------|
----------|     -------------                         |
----->{Message m1/Schema v1}----->| Port v1 |---> | Transform |                         |
----------|     -------------     ------------------  |
|            |--------> | Business Logic |  |
----------|     -------------     ------------------  |
----->{Message m2/Schema v2}----->| Port v2 |---> | Transform |                         |
----------|     -------------                         |
|-------------------------------------------|

In this case, the core business logic of the web service needs to be implemented in a version independent manner. Preferrably, this core layer should not also depend on any code generated using the WSDL of a particular version. For each version, you need to translate the incoming request into API calls of this core layer. In this case, versioning related changes can be limited to the layer that does this transformation.

In the case of the above sample web service, the first step is to build (or refactor from the existing version) an EmplManager component that can create an employ.

public class EmplManager
{
public String createEmployee(Employee employee) throws EmplManagerException
{
// Validate the employee object

// Create the employee record in a DB

// Return the employee ID
}
}

Here, the Employee object must semantically match the latest version of the EmployeeType used in the schema, so that Employee objects can be created from both v1.EmployeeType and v2.EmployeeType objects.

public class EmplManagerPortImpl implements v2.EmplManagerPort
{
public java.lang.String createEmployee(v2.EmployeeType createEmployee) throws java.rmi.RemoteException
{
// Create EmployeeType
Employee empl = new Employee();
// Set data
empl.setFirstName(createEmployee.getFName());
...

return emplManager.createEmployee(empl);
}
}

Similar code could be used to implement the v1.EmplManagerPort interface. The only difference between these two would be the new optional elements added in the v2 schema.

Although cumbersome to implement, the advantage of this approach is that you can maintain compatible versions of a web service without duplicating core business logic.

Yet another possibility is to implement the business logic using low-level APIs like SAAJ and DOM. Since SAAJ and DOM are not typed, you can use the same processing code to process documents of compatible versions. Unfortunately, most web service stacks don’t make it easy to generate SOAP response messages at this low level. For example, in the case of JAX-RPC, handlers can be used to process request and response messages but can replace the need for port components that use schema-generated types.

Similar approaches could be used on the client-side, and so I will skip repeating these for the client implementation.

Lessons Learned

As I remarked at the beginning of this post, versioning is a very nebulous topic. One of the basic issue is specifying what a version is. As in my previous posts on this topic, in this post, I assumed that only compatible changes are allowed in the schema as well as WSDL. But what is a compatible version? If you change the name of an element or attribute, is it still a compatible change? I think the answer varies on a case by case basis. A change considered compatible on one case may turn to be incomatible in some other case. I think the key point is semantics. Even when an element or an attribute is changed in the new version of a schema, the change may not alter the sematics. The change may enhance an existing semantic, but not alter it. Such a change is compatible.

Here are some guidelines that may help minimize the impact of versioning in an implementation.

Keep changes compatible: This is the basic versioning rule. You may have reasons for incompatible versions, but the consequences of incompatible changes are usually painful.
Avoid using generated types: Avoid using WSDL/schema generated classes/interfaces in your business logic. Instead design your core business logic to use simple Java objects (a.k.a. POJOs). This would keep the core part of your implementation independent of version-specific code generated by web services toolkits.
WSDL first: Although most toolkits encourage Java-first approach to designing web services, I find it useful to start with WSDL and schema first, mainly because it allows me to focus on the external view of the web service without worrying about how it is implemented.

Is Everything Built Before SOA WASTE?

Subbu Allamaraju — Mon, 25 Jul 2005 06:23:53 +0000

The JDJ newletter dated 07/21/2005 contains an ad that starts with the presumption that everything built before SOA cannot easily be integrated into the new SOA world, and someone is there is to help us. If not FUD, what is this?

Here is the complete text of this advertisement.

Is everything built before SOA WASTE?

While delaying SOA everything you create will not be native services and may need to be re-tooled for conversion. Quickly create, manage and monitor web services & Java services. Test a sample project to see how easy it is to capitalize on SOA!

I think the second word is supposed to read “deploying” but this is a verbatim of the text appeared in the JDJ newsletter. When you click on to this ad, it takes you to this page. This ad is for a group of products for building and managing services using some GUI tools. The products may very well be innovative for solving some related problems, but the text of the ad itself is very misleading and the only purpose seems to cause some FUD. Just to be clear, I have nothing against the products or this company, and my comments are limited to just the contents of the ad.

This ad raises a rather misleading question. What was it like before SOA? A quick google search points to a very common definition of SOA as "an architectural style whose goal is to achieve loose coupling among interacting software agents". The key point here is loose-coupling of sub-systems involved.

Most architects of enterprise software systems would definitely agree that loose-coupling is desirable for a variety of reasons. As an architectural style, SOA is just one piece of a puzzle. Loose-coupling is just one of the desired qualities. It is not the whole.

Now the quiz question. Can you untangle all your tightly coupled apps to make them SOA-friendly? Still want clues?

SOA – A Shot in the Arm for Registry Fans?

Subbu Allamaraju — Sat, 09 Jul 2005 21:42:15 +0000

It seems so. Registry fans are just beginning to get the attention they have been hoping for the last few years. As I was catching up with my email, I just came this article titled “Registry + Repository = SOA Platform“. Very interesting! A registry and repository to build and deploy SOA!

Let me try to make sense of the contribution of registries to SOA first. The author of this article quotes that “registries hold references to things”. That is right. Registries hold metadata of services and other interesting things. But this article fails to say why and how it helps SOA. As I discussed here, in most applications, registry is a development-time component, but not a runtime component. Developers intending to make use of web services can search repositories to find services that match certain classification criteria. Once a service is found, the next step is to build a client application, which usually starts with some codegen tool to generate interfaces/classes that proxy the service, and then programming to those interfaces/classes. This is the old-fashioned way of wiring up distributed applications. The only exception is when the client already knows how to use the service, and is consulting the registry only to know the where-abouts of the service.

So registries can be useful when the client wants to be directed to an instance of a service based on some runtime criteria such as QoS, fail over etc. Some web services management (WSM) tools advertise such “dynamic routing” as one of the main features of their products. Such tools can indeed take the help of registries for looking up for services (including their WSDL). The difference between the old-fashioned style of fail-over and load-balancing and the new age dynamic routing is the ownership of routing. For instance, in the HTTP world, proxy servers do the routing. In most RPC style applications, client consults some look-up service (such as a JNDI or a naming service) to do the routing. In this context, I don’t see much difference between these styles. The role of registries in this context is not as phenomenal as the author of this article is hoping for. Moreover, WSM-controlled routing has its disadvantages. I will post more about these limitations in a future post.

The second part of the equation is repositories. The author quotes that “repositories hold things”. But what things? I have read this article a few times to understand what he meant by a repository. Is he talking about an XML repository used as a general purpose database? Or is he is referring to a repository for service metadata? Although the article is not very clear, my hunch is that it is the latter. But how does it contribute to SOA? Hmmm.

Looks like my fad-analyzer is not working very well. Time to upgrade?

Web Services Versioning – Part 1

Subbu Allamaraju — Mon, 06 Dec 2004 21:50:17 +0000

Managing change and versioning of web services can be hard. Although based on loose coupling and extensibility concepts, when it comes to change, web services are not far from older supposedly not-so-loosely coupled RPC-style technologies.

Most changes have good intentions – either they fix something broken, or try to enhance the service by adding new features. However, except in the most ideal cases, changes are disruptive. As David Bau explains in his "morning
after" scenario, the need for compatibility can scuttle most plans for change. It is not always easy to foresee changes and future-proof the design, but eventually, we all get tasked to make changes.

Compatibility is one of the painful aspects of changes. Dave Orchard gives an exhaustive overview of extensibility and versioning scenarios for XML schemas in his "Extensibility, XML Vocabularies, and XML Schema", and this post (and the following) are partly motivated by this paper. In this post, I would like to jot down some of my thoughts on versioning of web services. My objective is to set some constraints for the kinds of changes allowed, and then think of how to go about making changes under those
constraints.

Before making changes to any web service, it is important to discuss and understand the impact of a change. This impact can best be discussed in terms of compatibility. Essentially, there are two kinds of compatibility, viz. backwards compatibility, and forwards compatibility. Depending on how service and client instances are deployed, one or both may be important.

Backwards compatibility ensures that older clients need not be upgraded to use an instance of the modified service. That is, when you upgrade your service instance to offer the latest and the greatest service interface, your clients must be able to ignore that fact and continue to use the service as though nothing changed.

On the other hand, forwards compatibility guarantees that new clients need not be downgraded to work with an old service. That is, when you deploy a new client that conforms to the modified web service interface, it should be able to work with old web service instances without having to downgrade.

Whether your goal is to guarantee backwards compatibility, or both backwards and forwards compatibility depends on how many instances of the service are deployed currently. If there are "n" clients interacting with just one instance of the service, backwards compatibility alone may be sufficient. But if there are "n" clients interacting with "m" instances implementing the service, forwards compatibility becomes an issue. This is because, of those "n" clients, some clients may be using instances offering the old service, some others may be using instances offering the new service, while the rest may be using both.

So, here is our first constraint:

Constraint 1: Changes must guarantee backwards compatibility and possibly forwards compatibility.

Note that I don’t include the possibility of simultaneous upgrades in this discussion. Simultaneous upgrades are not always practical, and can be disruptive when attempted. Moreover, the whole idea of loose coupling goes against simultaneous upgrades. Why should a client/service upgrade just because the service/client at the other end of the wire upgraded? This may be a reasonable requirement when the software is monolithic, but not when it is loosely coupled. Check Christopher Ferris’s "Loose
Coupling and WSDL Versioning" for some arguments on this point. So, the second constraint is:

Constraint 2: Service instances and their clients should not be forced to upgrade simultaneously.

Any change that breaks backwards or forwards compatibility is an incompatible change. Incompatible changes are bad, and include:

Removing an operation from a WSDL port. This breaks both backwards and forwards compatibility, and forces simultaneous upgrades of clients with service instances.
Replacing an input or output message type with a different message type for the same operation in a WSDL port. This kind of change also breaks both backwards and forwards compatibility.
Adding new required elements to existing messages.

Compatible changes include

Adding optional elements or attributes to existing messages.
Adding new operations to an existing WSDL port.

There is one additional detail to consider, and this could be more painful to the folks making changes than anyone
else. Assume that you have the following piece of code at the service end prior to making the change:

   public ResponseMessage doSomething(RequestMessage requestMessage)
// Do something
return responseMessage;
}

After the change, the service implementation might end up looking like the following:

   public ResponseMessage doSomething(RequestMessage requestMessage)
// Do something
return responseMessage;
}

public ResponseMessage1 doSomething1(RequestMessage1 requestMessage)
// Do something better
return responseMessage1;
}

You could possibly refactor this to share some common logic, but there are two pieces of code to deal with.

The client may have to follow a similar code pattern as well.

      // if service is old
...
// dispatch the old request
...
// else if the service is the "better" version
...
// dispatch the new request
...

At first, this option may not look so bad, but this kind of code can be very difficult to maintain. After a few
rounds of changes, it will become spaghetti-like. So, the changes should be evolutionary and additive, leading to
the third constraint:

Constraint 3: Changes to the service should allow evolutionary changes to a service/client implementation.

The idea behind these constraints to make the change process manageable and not make clients tightly-coupled to
the services. In the next part, I will discuss some possibilities, and whether those possibilities honor these
constraints.