This content has been marked as final. Show 5 replies
you will have a seconds transaction in ADF, this is for sure. Forms has a built-in to provide you username and password for the database access, but I don't see a save option to pass these credentials to the client. You could use an encrypted cookie that you set from Forms and have ADF reading, decrypt and connect. The cookie may not contain username and password but a random key that identifies a database entry you can get username and password from. However, immediately after, you should delete all traces to close the possible attack window for hackers. SSO wont help IMO because it performs web based authentication, no physical database connection
You might want to take a look at our product OraFormsFaces at http://www.oraformsfaces.com
This is specifically targeted at your use-case: progressively migrate from Forms to ADF (or other JSF framework). It allows you to embed existing Forms as JSF components in your JSF/ADF application. This means you can offer a single integrated web application to your user that partially exists of existing (reused) Oracle Forms. OraFormsFaces allows you to embed the legacy forms and enables the exchange of data between JSF and Forms as well as each technology to raise events in the other.
As to your question regarding database credentials it can leverage Oracle SSO where the user first enters the JSF application that is protected by SSO. The application then embeds Oracle Forms which detects the same SSO session and uses the database credentials stored for this user in SSO/LDAP.
An alternative implementation is to implement a simple Java class in the JSF application that returns the database username and password to be used for this session/user. It could ask this from the user or retrieve it from some secure store. OraFormsFaces than takes care to securely transmit this information to Forms where it is used to logon to the database. See section 14.2.2 in the Developer's Guide at http://static.commit-consulting.com/oraformsfaces/OraFormsFaces-devguide-3.1.5.pdf
Either way your JSF application and Forms will both have a separate database connection and thus a separate transaction.
For more information about OraFormsFaces view the viewlets at http://www.oraformsfaces.com or simply download it from the Open Source and Partners Extension Center in JDeveloper using Help > CheckForUpdates. The JDeveloper extension includes the demo application from the viewlets so you can have a look around at how OraFormsFaces can be used.
As far as I heard here from previous trainings / presentations, the migration from forms to ADF was not done by embedding forms within ADF application but having both technologies, am I right ?
I have to be sure that your product fits to our needs, and that our clients are ready to pay for it. I mean that I'll be quite alone to check for bugs / malfunctions of the product and it can be really complicated for me.
You are correct that - from a developer/technical standpoint - you are embedding Forms into JSF/ADF which makes you run a hybrid application using both technologies. For the end user it can appear as a single integrated web application. The benefit to the organization is that you can now migrate individual (groups of) forms to the new JSF/ADF architecture while keeping one single integrated application to the end user. The full migration can be split up into many smaller projects and might take years to complete. The key thing is that the pace can now be dictated by business needs.
Simply put a 500 Forms application could be transformed to a 500 page JSF application where each page embeds a single legacy Form. This is a fairly straightforward process with the benefit you can start enhancing your JSF application with new technologies from day one. Over time the 500 legacy forms can be replace with true JSF/ADF pages.
OraFormsFaces itself is not a migration tool but it can be a vital component in a progressive migration strategy.
When it comes to the actual migration from Forms to ADF I personally don't believe in products promising a 100% full automated migration. The two technologies are inherently different and you want to end up with a properly architected JSF/ADF application, not some auto-generated converted bunch of unmaintainable code.
I only believe in migration products/tools that aim at ending up with a properly designed application and less on the perceived productivity of the migration itself. You should take a look at JHeadstart Forms2ADF for that purpose. It leverages the very productive JHeadstart tool which can generate an ADF application from high level metadata. The Forms2ADF extension analyzes your existing Forms and creates that metadata which can be used by the traditional JHeadstart tool to generate an application. This is far from 100% automated but it is much more productive than rebuilding from scratch. More info on JHeadstart and Forms2ADF can be found at www.jheadstart.com