Follow Us on Twitter

Agile SOA Infrastructure – Token configuration

by Tony van Esch on November 20, 2013 · 1 comment

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.

token_serverUrl

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.

token_configuration_EMTogether 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


Ratings:
VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

One comment on “Agile SOA Infrastructure – Token configuration

  1. Pingback: Using global token variables for SOA and BPM SCA composites | J@n van Zoggel

Leave a Reply

Your email address will not be published. Required fields are marked *

*

* Copy This Password *

* Type Or Paste Password Here *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

 

Previous post:

Next post:

About Whitehorses
Company profile
Services
Technology

Whitehorses website

Home page
Whitebooks
Jobs

Follow us
Blog post RSS
Comment RSS
Twitter