Configurable settings and endpoint replacements - II

Almost a year ago, I blogged about Configurable settings and endpoint replacements , just want to reiterate as few more options are available for same functionality.

It feels like a very basic fundamental problem, which I would describe as, a configuration setting (be a URL or anything else), should be :

• Must not be hard coded inside your code or binary
• Must be able to replace it from environment to environment, and changing the those value must not cause server to restart

Java or any programming language has solved this problem tens of years ago, but Oracle keep seem to be providing one after another solution for last 10 years in SOA 10g/11g, and makes it really complicated problem than it sounds..

Configuration Settings

DVM
Pros

• Stored in MDS
• Changes are independent of deployment
• Nice UI for update

Cons

• Hard to modularize per Composite
• If managed via both UI and SVN, it can quickly can get out of sync in multiple environment.
• Not too sure about what level of caching is done

DB Lookup (may be with custom XSL)

• Probably a bit more overhead vs having things in memory

AIA Configuration Properties (More info: http://chintanblog.blogspot.com/2012/10/aia-configuration-and-dynamic.html)
 Pros

• MDS stored
• Changes are independent of deployment
• Different level of modularization - System/System Module/Service

Cons

• No UI to make changes - hopefully in future release

Preference along with config plan (More info: http://chintanblog.blogspot.com/2012/06/bpel-preference-11g.html)
Pros

• Run time changes via Mbean browser and changes can withstand server restart

Cons

• Modularization is not flexible (e.g. two composite cannot share same property)
• Changes via MBean are still temporary. Deployment will overwrite changes from composite (or config plan).
• Have to keep config plan in sync with UI changes

Code migration and reference to end point URL
Custom search/replacement
Pros

• Much better control, as it is raw search and replace

Cons

• Custom scripting
• Unless it is highly sophisticated, search term has to be known in advance
• It breaks my principal #1 - why hardcode stuff in the code at first place?

Token Replacement (link)
Pros:
Cons:

• Only works in specific files and specific section of composite.xml
• Requires server restart
• Can not be used for config other than binding.ws URL

Configuration Plan
Pros

• OOTB, and it is xpath based replace so no need for search term

Cons

• It breaks my principal #1 - why hardcode stuff in the code at first place?
• have to manage one per env
• If composite is constantly changing, it is really hard to manage multiple plans
• No support for runtime URL change

Dynamic Partnerlink Lookup (DPL) - using AIAConfig (More info : link)
Pros

• Centralized config for all end points (and preference) - better governance
• OOTB functions for lookup and merge during deployment
• Just one MDS stored file

Cons

• Changes requires MDS update via script and reloading via AIA console
• No UI to make changes - hopefully in future release
• Only supported in AIA, if not AIA, need to have custom XSL function to support same functionality 
• It comes close to what I would like to have, but involves entire AIA FP infrastructure to be installed plus the licensing cost

Oracle Service Registry (OSR)

• It's dead, man, get over with it.