Implementation
For comparing the different methods I used a simple synchronous HelloWorld BPEL process with audit logging turned off. The property to be fetched is the greeting (Hello). The process itself returns its input prepended by the greeting followed by a space. Thus for example input: Maarten, output: Hello Maarten.
Domain Value Map
Domain Value Maps (http://docs.oracle.com/cd/E14571_01/integration.1111/e10224/med_dvm.htm) are an underestimated feature from Oracle SOA Suite. An XML file called DVM (domain value map) allows storing domains and domain values. In JDeveloper wizards are available to create and fill the DVM file. XPath expressions can be used to easily query these domains and use them in for example BPEL, BPM or the OSB (http://guidoschmutz.wordpress.com/2009/12/25/implement-domain-value-maps-dvm-with-oracle-service-bus-osb-10r3/). The SOA Composer (http://docs.oracle.com/cd/E15523_01/integration.1111/e10224/med_dvm_ui.htm) provides a GUI for editing DVM's at runtime. DVM's can be shared among processes by putting them in the MDS.
Development
The below screenshot shows how JDeveloper makes it easy to create and use a DVM. In one screenshot how a DVM can be edited at design-time in the top/left part of the screenshot and XPath expressions can be used (bottom part) to let the BPEL process query the DVM at runtime.
Performance
On average the BPEL process including DVM query took 15ms for it's execution.
GUI for runtime update
To allow updating the value, as described, the SOA Composer can be used. This GUI can be presented and used by business users. It is the same GUI which allows updating of Oracle Business Rules. I have not looked at if it is possible to script changes to a DVM. My estimate is that uploading a new DVM to the MDS is how this is done (which can be automated using Ant or WLST).
Use them for
DVM's can be used for properties/preferences. They however have a domain name/value structure which makes them especially suitable for translation lists. For example translating a country code to a country. The example of the country code is something which is also suitable to put in the MDS for re-use. Re-use is limited to the SOA Suite unless exposed by other means.
BPEL Preference
In Oracle BPEL, preferences can be used. This feature is specific to the BPEL component. Other components of course have other means to achieve similar functionality. XPath expressions are provided to allow querying preferences (ora:getPreference). They are defined in the composite.xml file. They can be updated at runtime from the MBean browser in the Enterprise Manager Fusion Middleware Control: http://eelzinga.wordpress.com/2009/10/28/oracle-soa-suite-11g-setting-and-getting-preferences/ (for getting/setting) and http://beatechnologies.wordpress.com/2011/11/04/persisting-component-preferences-in-oracle-soa-suite-11g/ (for persisting). BPEL preferences can be set by using configuration plans upon deployment.
Development
In the composite.xml file, BPEL preferences can be added. There is some GUI support for it but not as extensive as for the DVM.
Performance
Performance is very similar to the performance of DVM's. About 15ms for a request/response.
GUI
For updating properties, the MBean browser can be used from the Enterprise Manager. Drawback is that the path to find the preferences is rather deep and if there is a large amount of preferences, it can take a while to find the right one. I have looked at scripting changes to property values but this was not done easily and requires custom Java code.
Use them for
These preferences are not suitable for lists or more complex lookups since they contain a single value per preference. Also they do not allow specifying domains and cannot easily be used for translations like DVM's. Also the EM GUI for updating preferences is not suitable for searching through large amounts of preferences or for business users. Since replacing of preferences can be done in configuration plans, the values are hardcoded in more then one place so it is best to keep the amount of these preferences limited. These preferences can be used to indicate for example an environment (replacing it with a correct value using a configuration plan) in order to forward this as part of an header. Since the preferences are part of the composite.xml file under the BPEL component, re-use is limited to the component.
Database properties table
Storing properties in the database has been done even before Oracle SOA Suite in it's current form existed. This method has the highest re-use potential since every piece of software which can query a database, can use the properties stored there. A drawback is that it is always a custom implementation and there's no standard GUI available to update properties. Also querying a database costs some performance since the properties are obtained from a different server (usually by using an abstraction framework) and not available locally.
Development
As indicated, designing and implementing a properties table is done manually. Also querying the table is custom code since it is specific to the table implementation. The below screenshot shows SQLdeveloper and an example of a custom table.
In BPEL to provide a layer of abstraction, location to allow logging and to make database developers aware of the impact of their changes, I tend to use a custom table API (TAPI) to obtain values. In BPEL the DbAdapter is used to call the TAPI.
Performance
The test was performed on a local XE database running inside a virtual machine. A single request took about 18ms. This is not much slower then using a BPEL preference or a DVM lookup. Had a database on a remote machine been used, the performance would of course have been worse because of network overhead.
GUI
A custom table needs a custom GUI. You can use APEX or ADF for that if you want to allow business users to change the properties. If you're ok when only people with a technical background to change the values, you can do so by means of SQL scripts or a tool like TOAD or SQL Developer.
Use them for
When you need to re-use your properties outside the scope of Oracle SOA Suite or among different SOA Suite servers, storing properties in a database could be a good idea. Also when you have large amounts of 'properties' / domain values (millions), my estimate is that a database is more scalable then for example a DVM. A custom database table provides most flexibility in that it allows you (if you build it) to track changes to it and keep a history. Additional functionality can also be added if required.
Conclusion
There is not a one size fits all solution for using properties/preferences/parameters. Different requirements require different solutions. In my experience though the following are good guidelines;
Use the database if properties need to be re-used among different servers using different technologies or if there a large amount of domain values. Also if you have specific requirements concerning the use of properties, a custom implementation provides most flexibility. It requires most development time and without a custom GUI business users can't change values. Mind that when you change a property in a database table and a long running BPEL process had previously fetched the database value, this is not automatically updated without a recheck! DVM's and BPEL preferences don't have this issue since using them usually implies fetching them by using XPath.
Use domain value maps for translation tables or properties which will have to be changed by business users without requiring IT personnel (using SOA Composer GUI). The scope of re-use is limited to a SOA Suite domain unless exposed.
Use BPEL preferences to allow limited local control on BPEL process flow. Especially suitable for properties which change among environments such as file system paths or a short name for the environment. These are usually the properties which will be replaced with configuration plans and hardly ever changed at runtime. They can however be (ab)used to allow changing the flow at runtime without requiring redeployment of a process.
No comments:
Post a Comment