Problem solve Get help with specific problems with your technologies, process and projects.

How to use an XML appliance for versioning, governance

XML appliances are only able to enforce policies placed in the request path, reminds enterprise architect Todd Biske, so it's important to ensure systems can't go around the gateway.

What are some examples of how to use XML appliances for versioning/governance?

Todd Biske Todd Biske

First off, there's really no difference between using XML appliances or any other intermediary (e.g., an enterprise service bus (ESB) when trying to provide capabilities associated with versioning or governance. While there certainly are differences that the vendors will be happy to call out, the basic techniques are the same. This question is not, "Should I use an XML appliance or a software-based ESB for versioning/governance?" so I won't go to go into any more depth on that subject. What's important is that the techniques here really can apply to any intermediary, not just XML appliances.

Run-time governance

Let's start with the broader topic of run-time governance. Capabilities associated with run-time governance include security (authentication, authorization, validation, encryption, threat protection) and traffic management (routing, request rate throttling and other traffic shaping techniques). Additionally, there are ancillary capabilities that are required for governance such as metric collection. You can't enforce a request rate agreement in a service contract if you're not collecting metrics about usage.

When using an XML appliance or any other intermediary, it is only able to enforce the policies if it is inserted in the request path. Think of it as a gateway for getting to the actual service container. Putting it in the request path normally isn't a problem, but ensuring that consuming systems can't go around the gateway is something you need to consider.

There's really no difference between using an XML appliance or any other intermediary.

In the case of externally facing gateways, this isn't as much of a problem, as your actual service containers are typically on a different network than the gateways, and firewalls prevent the containers from being accessed directly. For internal gateways/intermediaries, that may not be the case, so you may need to use two-way SSL or other methods to ensure that requests always flow through the gateway. Whether you choose to rigidly enforce this or apply techniques that make it difficult, but not impossible, will depend on your company's information security policies.

For security policies, the techniques are straightforward. Consume the request, extract and validate credentials, check authorization policies and validate the request message for XML threat vectors. How they do this is important because there are XML threat vectors that can quickly cause problems for parsers. What's good about doing this in a gateway is that you can enforce policies that apply regardless of the service and consumers involved. This is a very important point.

Transformation and orchestration

My opinion on gateways, whether software-based or appliances, is that they should do a few things and do them very well. Those things should be part of the process for the majority if not all of the messages being processed. This is why I did not include transformation or orchestration as capabilities associated with governance.

Transformation is not something that needs to be done on every single message flowing through your gateway. If you do include it, the performance of your gateway becomes much more difficult to predict. What if you get a surge of requests that involve transformations? These will consume more CPU (central processing unit) and put your gateway at risk of starving out other message traffic. 

You want your profile to be based on the overall amount of message traffic, and not on the traffic associated with one particular message type. Security falls into this category. Every request should have the credentials validated and an authorization check performed. If externally exposed, they should have the message scanned for potential threats. It applies to all incoming traffic.

For traffic management, the same thing is true, although it does get trickier. The basic capability that will always exist is routing/load balancing, although you may choose to delegate load balancing to a dedicated appliance for that purpose. Evaluate content-based routing for performance impact. Typical load balancers will look for information in a specific location (e.g., TCP/IP headers), make decisions on that information, and are optimized based on that assumption. If you now have to look in custom locations for information to determine routing, the overall performance of the appliance may be reduced.  

Versioning support

Finally, let's talk about versioning support. First, what are the capabilities associated with versioning? If a consumer explicitly specifies the version of a service to use, there's nothing for a gateway to do except verify that the consumer is authorized to use that version. If a consumer doesn't specify an explicit version, now you need to route that request to the appropriate version for that consumer. Or do you?

This gets into the area of backward compatibility. Once you make a change to a service, you need to look at that change and determine if it is backward compatible with previous request and response messages. If it is, there should be nothing you need to do in a gateway. Simply route the requests to the new implementation. You can apply traffic shaping rules to slowly roll from the old to the new, but there are no transformations or anything involved, at least at the gateway. If the interface is not backward compatible, then treat it as a new service.  

By definition, if the interface is not backward compatible, existing consumers must make changes to use it. You can choose to keep the old one around to allow consumers to migrate over time, but at some point you will need to tell them it's getting turned off. You may also have changes that on the surface are not backward compatible but can be made backward compatible via transformation. For example, if you change the structure of the information in an XML service, but do not add any new content, that could be addressed via a transformation.

My advice is to avoid doing that in your intermediary, but instead do it in your service implementation. Expose the new interface as a new service, but route requests going to the old interface to the new service implementation. Within your implementation, detect whether it is an old request or a new request, and apply the transformations there and likewise on the response path. Why? Performance. Avoid doing custom activities in your gateway that only apply to one service that can potentially impact the processing of other message traffic.  

So in a nutshell, use gateways where you need to do a common set of activities across all of your message traffic, regardless of the particular consumer or service involved. When you need to do activities that are unique to a particular service, like transformations or orchestration, either do it in the service container itself or in an intermediary that only handles traffic for that particular service.

Follow us on Twitter @SearchSOA and like us on Facebook.

Dig Deeper on Application performance management and testing

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.