WebService architecture for flexible SQL-WHERE condition

[MT]

Hi,

I am looking for the best architecture or job design for following problem:
I have to create an RTI WebService to run a SQL statement against DB2. The service will get about 30 parameters which are potentially part of the WHERE condition - filtering the answer set.
The problem is now that I can get maybe only one filter criteria (so only one WHERE condition attribute) or 25 of them (or even 30) but I want only a single WebService for that.

Some guys suggested an always on WebService with an RTI Input and RTI-Output stage. Having this I have to have a multi-row lookup which is possible in an ODBC stage and I would habe all the thirty (theoretical possible) fields als lookup key. This would then need a way to kind of default the unsused filter fields...
Any ideas how this can be done in an optimal manner?

The alternative in my eyes is a WebService with only a TI-Output stage - so it would be more like batch mode and not "always on" - I know how to handle that one I think.

Any ideas and suggestions are welcome

Thanks in advance

Michael

[eostic]

Michael....

One key thing I don't think we talked about earlier was the frequency of calls.... how often is this service invoked? How many times per day, per hour, per minute, per second......?

That will also help determine the necessity of doing this as a lookup technique vs a pure parameter based technique.

Ernie

[MT]

Michael....

One key thing I don't think we talked about earlier was the frequency of calls.... how often is this service invoked? How many times per day, per hour, per minute, per second......?

That will also help determine the necessity of doing this as a lookup technique vs a pure parameter based technique.

Ernie

Hi Ernie,

yes sorry - the frequency is variing because is it called from an internal application where several people could request data - so I guess 50 - 100 times a day....

Michael

[eostic]

At that low rate, "always on" might be overkill..... if the flexibile technique you need is easier to do with straight job parameters supplied directly to a SQL statement, using a single rdbms stage going ultimately to a single WISDOutput may be fine.....especially if it is a Server Job, with very low startup times.

Ernie