Disclaimer : This blog space does not necessarily reflect my views/ideas on the technology and beyond doubt, never reflects the views of my employer.

Saturday, September 27, 2008

Oracle Forms Modernization with Fusion Middleware

I was reading about Forms Modernization on OTN. There are some links to good white papers and articles are available about Oracle Forms modernization; specially EuroTransplant and Griffiths Waite. Thought to put a post of my idea about how this process is executed

The key reasons for Form’s modernization could be:
Retain the current Investments
With continued support and investment in the technologies of your legacy applications, you have the ability to modernize from a platform of stability.
Adopt New Technologies
Service Oriented Architecture (SOA) allows you to realize new practices and technologies and to do so in a step-by-step basis
Integrate them
Both your legacy and new systems can integrate and share services allowing legacy applications to continue to run your business as you build up new systems and services.

Oracle Forms and SOA
The SOA Roadmap deconstructs legacy Oracle Forms systems into elemental components and recomposes them into a vast set of new application services.

The transition from Oracle Forms client/server to SOA should be a journey, not a single transformation. A staged (that is, phased) modernization effort enables Oracle Forms applications to be migrated over time. This lengthens the period of time during which Oracle Forms remains an architectural element, but reduces the overall migration risk during that time period. The first phase focuses on protecting customer’s existing investments by stabilizing the application and upgrading it onto a supported platform. Subsequent transformation phases will then gradually evolve the application to a Service Oriented Architecture.

The most critical and also the most difficult step in the transition to SOA is the migration to an n-tier Architecture focusing on establishing the business logic as independent to the database and client application. Once this has been achieved the transition to the upper levels of the Roadmap becomes significantly easier. Critically, system modules / business processes can be migrated one at a time and proceed at different speeds through the roadmap.

As per the white paper given on OTN, there are three areas where Oracle Forms can be integrated with a Service Oriented Architecture:

• Usage of external service

With functionality recently added to Forms it is now possible to call from Forms to Java making it feasible to use Web services and BPEL processes.

• Exposure of Oracle Forms business logic to the outside world

In a world of distributed applications, Forms code might need to be moved out of Forms and into a place where it can be used by other applications.

• Using the Application Server's infrastructure

Oracle Forms coexists and integrates with Oracle's Applications Server's infrastructure functionality. Forms' integration with Oracle Single Sign-on and Enterprise Manager falls in this section.

Here I have tried to create a diagram which gives an idea about the Forms Modernization Architecture.

Fig : Possible Forms Modernized architecture, also suggests
1) Integrating Forms with SSO using Enterprise Server
2) Separating the business logic to DB
3) Exposing the Forms business logic as PL/SQL Procedure of Web service
4) By using Java, calling outside objects directly from the Forms
5) Desired Integration options
a. Connecting Legacy/ERP applications using BPEL PM
b. Exchanging Information with Business Partners using BPEL PM and B2B

Some points below which can be explained in details for the above diagram.

1. When Forms becomes a part of a larger setting it needs to be able to participate in application server wide functions such as maintenance and management and user authentication. It doesn't make much sense to have one application use its own authentication scheme and all the others use another scheme. In versions 9 and 10 Forms is a full member of the Application Server infrastructure and is automatically configured to be able to use both the Single Sign-on server (Oracle OID and SSO) and to be managed thru Oracle Enterprise Manager.

2. The outside world use existing Forms business logic. Forms business logic can be exposed as a Web service Or Forms business logic which can be written in PL/SQL can be called directly ad Database Objects.

What we’ve to remember is that it is possible to move Forms PL/SQL code from Forms to the database and from there expose it to the outside world, either as a database procedure/function or as a PL/SQL Web service.

3. Oracle Forms use of external services hinges on recent functionality regarding Java integration. Oracle Forms can call out to Java on the file system. It can make use of Java beans and its native screen widgets can be customized with custom Java code (the Pluggable Java Component architecture). In this section we are going to touch on the functionality of calling out to Java code residing on the file system.

Once that functionality put in place Oracle Forms ables to call all kinds of external services such as Web services and be part of a BPEL process flow.

4. WebFoms : WebForms could be achieved by running APS on a Web server and emulating the graphical user interface in a generic applet in the client. So, instead of the traditional Oracle Client Server Forms solution, a Java UI can be presented to the user within a browser. The N-tier architecture of Web Forms is much more responsive when run across a large company network, significantly reducing the network traffic between the client and the data center, compared to the client/server architecture.

Hope this has given idea about Form’s modernization process. The references can be availed @ http://www.oracle.com/technology/products/forms/forms_modernization.html



No comments: