Do not use generated database webservices in Cordys


Cordys BOP4 has the great option (just like all other respected EAI tool) to generate webservices on top of your databases.
In fact you can even generate a GUI on top of it, so that you can adapt data within your database through a GUI.
Sounds great or not !?

Watch out, because there can be a catch and this all has to do with a good SOA design!

Using webservices

In a project I work in, there has been decided to use generated webservices within the BPM processes.
This can easily be done by generating the MetaData of the database and then generate webservices for it, or even customized webservices by
using you own SQL statements.
This all works fine, but ..
1) You have to catch exceptions within all the BPM processes that use these webservices
2) The data within the databases can change (types, extra data elements, data elements removed, partitioning of data, primary key changes)
3) This will impact all the BPM processes that use these generated webservices

Define Data Services

The advise I want to give is to encapsulate the generated database webservices in Data Services (sub processes).
This way:
* Define the interface of the Data Service within a WSDL and use Contract By Design
* Call the generated database webservices within the Data Service
* Handle all technical errors within the Data Service, or expose when needed
* Use this Data Service within the other BPM processes

This way the changes of the database are encapsulated within the Data Service.


By using Service Oriented Principles within the Cordys BOP4 product it will increase the maintainability and usability.

* Abstraction (by using Contract By Design pattern and Data Service)
* Loose Coupling (by adding just an extra layer on top of your generated database services, so that database changes can be handled better)

So actually use the generate webservices feature of Cordys !
But use it with care and keep the SOA principles in mind!

No comments:

Post a Comment