Sunday, November 23, 2003

Web Services: Not Java nor .NET Was helping out a partner Friday track down how they could utilize Oracle Forms in a Web services business process.  Suffice it to say it initially seems like it is a bit of work but appears quite do-able.  The problem is not calling out to a Web service from Forms which is well documented (even with a viewlet) but calling *into* Forms client from a Web service and passing back the result via a Web service. The strategy we are working with looks like this (alternatives would be interesting to hear): 1. In the Forms client application build a message polling mechanism - perhaps using Oracle AQ in the back end as your queuing mechanism - a good choice would seem to be AQ as it has a rich  PL/SQL API that makes it friendlier to Forms or perhaps the Pluggable Java Component (PJC) framework in Forms could be wired to an OC4J MDB listening on the JMS API on top of AQ.  This is clearly the tricky part of the solution. 2. In the Web services client to the Forms application (in this case, a long running business process), push your inbound Forms message onto that queue - in this partner's case, it would be a Web service call to push a message onto a queue.  This example in the OTN Web Services Center shows how to publish an Oracle9i AQ queue as a Web service. 3. Once the Forms application receives the inbound message - in reality, really just a trigger to do something - execute the business logic in the Form that is to be incorporated in the external process.  Next format the resulting data so that it can be sent externally. 4. Finally, because the outbound message from the Forms application also has to be a Web service, use the Forms call out to the Web service mentioned above or perhaps call a stored procedure in the database which itself can do a database call out to a Web service (whichever suits your needs). The main drawback of this approach seems to be that it requires an active Forms client and consequently is limited by how many active Forms clients you have in your Web service business process *server* environment.  The main reason to take this approach is not wanting to re-architect the Forms application to put the client logic into the database.  If this re-architecting approach were taken, it is reasonably easy to publish PL/SQL in the database as a Web service, especially with JDeveloper making it a point and click exercise.  This latter approach, though invasive to the application, would clearly be the simpler style.  It also gains the inherent scalability of the database. News on how this one works out will be interesting to track ... I suspect given the rather huge community of Forms developers out there, this problem has been encountered more than a few times and there are probably a number of innovative solutions out there. Overall, this is a good example of why Web services as a mainstream technology seem to be emerging in fits and starts.  Every other piece of the process worked fine based on existing technology, but this one had a bit of challenge.  It too appears workable, but like most projects in real life, there are some interesting technical hurdles to overcome.  To make this all seamless, not only do the standards need to keep on evolving, but the vendors have to keep on stepping up to the plate! Update December 9, 2003: Today I met with the vendor ClickMarks which actually does re-purpose Forms client applications as Web services.  They have a design time for extracting the data from the client applet and packaging it as a Web service which is complemented by a runtime environment to drive the Forms applet clients.  Non-invasive to the Forms application and solves the same problem as the above entry.  Quite slick if this is your problem. comment [] 10:56:50 PM