Exposing Gen

I attended a session yesterday in which I was discussing the appropriate way of exposing Gen functionality into an SOA. I discussed three ways of getting Gen functionality “out” of a Gen environment.
One of the questions that I fielded was “How easy is it to take Gen functionality and expose it at different levels”.
“Different levels” in this case means – either at the procedure step level or at the action block level.
In principle, it is the same, but it transpires that in our organisation, where we have complex procedure steps aligned to a single business process, consisting of MANY hundreds of action blocks, each containing a piece of common functionality – basic field validation, business rules etc etc… that the appropriate exposition level is BOTH, BUT IN DIFFERENT WAYS !!
For simple, quick pieces of individual validation which do NOT require any database access, we thought that we would generate raw java code and deploy that straight into our web application sever infrastructure (hand-crafted java), for speed, but for more complex pieces of validation and business logic, and the final database update stuff, we would expose a web service, via the Java proxy of the full procedure step, minus any appropriate validation that we had already deployed to the web application server. Bearing in mind that the back end deployment is deployed on a cluster of Unix boxes in C, again for speed.

Thinking about this, it seems that reuse is ALWAYS achievable, but we have to be careful WHAT we reuse and in which way, and that a number of deployment decisions have to be made as to HOW the deployment is done.

Sometimes, picking small bits of existing business transactions and deploying them to the web is appropriate, since the paradigm of web data entry is usually different to “traditional office keying”, where a web screen consists of a small number of entry fields, and validation “as you go”, and a final “submit” where the user shouldn’t be told “by the way you have a problem on screen 1 (of 10)” – they should be told as they go that there is an issue. Traditional office keying, especially in a high-throughput environment is a “key the lot, then check it” approach.

Picking bits of business logic and validation from an existing business transaction that is to be web-enabled can be done in a number of ways (the way described is just one) allows maximum reuse, maximum flexibility in deployment (not discussed yet !!) and uniformity of business rules and inplementation – demonstrating yet again that Gen can abstract an organisation from technology, but still be confident that multiple technologies can implement consistent rules, since the rules are stored in a model !!!!