Agile SOA Infrastructure – Token configuration

We are currently working on smoothing out some rough edges in our continuous delivery process for a project. This delivery process needs to facilitate java applications, SOA/BPM artifacts, OSB artifacts, database scripts etcetera.

Important for the delivery process, is that the package containing the artifacts, should be environment independent. Any environment variable, be it some network reference or configuration item, should be abstracted out of the deployed code.

For the composites (SCA’s) in the Oracle SOA Suite, this was only partly possible. References  to concrete WSDL’s can and should always be abstracted into the MDS through service decoupling@[design|deploy]time (see Best Practices for Decoupling Services and Avoiding Invalid Composites at Server Startup).

But we are still left with the binding of concrete endpoint references in the composites. To alleviate these configuration issues, SOA Suite has the option of using a configuration plan (see Customizing Your Application for the Target Environment Before Deployment).

Configuration plans are a nice feature, but the problem lies in the fact that we now need to maintain these configuration plans. And these plans are tied to a single composite. Ofcourse we can write a script that also solves this problem, but that solves the problem only at deploy time. Essentially the concrete values are still compiled, thus ‘hard-coded’, into the composite. This makes changing these values impossible without redeploy.

Going global: Tokens, tokens, tokens…

With the release of patchset 6 (11.1.17) for Oracle SOA Suite, a new feature called global token variables has been added to address this shortcoming (Managing Global Token Variables for Multiple SOA Composite Applications).

Through global token configuration we now can address several issues:

• No more environment specific values in the runtime.
• Endpoint configuration is shared across SCA’s
• Central management of tokens through Enterprise Manager
• Deployment of token configuration is clusterwide.
• Through the default serverURL token the SOA Suite access point is available already.
• Supported properties:
  • Protocol, host & port for ws.binding location
  • Any property under reference tag

So now we can deploy composites using global variables and these variables are resolved not only @[design|deploy] time, but @runtime aswell. We now only need to maintain a global configuration in the SOA infrastructure.

The serverURL token can be managed through the common properties of the SOA infrastructure.

The other tokens can be configured and managed through Enterprise Manager aswell. Go to Token configuration under SOA adminstration and you’ll be able to manage the entries or even bulk load a whole set of tokens.

Together with the SOA lead and Oracle ACE Jan van Zoggel, a setup was done to test the token configuration. Check out his blog for more details on the development side of the token configuration.

With the token configuration a really interesting opportunity arises. Apart from being able to deploy the exact same composite in every stage of the  development lifecycle (DTAP), without configuration plans, we now have the possibility of cloning the production SOA infrastructure to any test environment. We only need to change the global SOA infrastructure settings, where applicable and we are good to go. Now we can actually test deployment on a real production copy including any other test cases (regression etcetera) you can think of.

This is a real killer feature for developers and administrators (devops), which fits perfectly in our search for an optimized continous delivery process.

Update:
Found some really nice information on global tokens on the Oracle a-team site, concerning naming restrictions of tokens. Only use alphanumeric characters and underscores. They also mention a second default token called applicationURL, which converts to ${serverURL}/{partition of calling composite}. Perfect for interpartition calls.

References:

Best Practices for Decoupling Services and Avoiding Invalid Composites at Server Startup
Customizing Your Application for the Target Environment Before Deployment
Managing Global Token Variables for Multiple SOA Composite Applications
Using global token variables for SOA and BPM SCA composites
Using Global Token in PS6 (11.1.1.7)

And a quick pointer to Martien’s post. He was a little bit quicker with blogging this feature.

Ease up your SoaSuite deployment using global Tokens in composites