[Openroad-users] Comments please

[Frank Barratt]

Hi, I am going to be a bit candid with this but we have a consultant who is looking at replacing our current application written in OpenROAD with "more up to date technology" his words.
 
I have had to change the names of the application and a few other bits and pieces but you will get the idea, I have not taken any extracts from the document out of context.
 
Sorry it’s a bit long but some constructive comments from uninvolved 3rd parties would be great.
 
Option 1- Continue Using OpenRoad and Tuxedo
 
Advantages
1. Technology is known and proven
2. Ingres does offer a proprietary OpenRoad Applications Server product which is intended as an upgrade 
path for organisations wishing to move away from older thick client technologies to a 
modern web based approach but still leverage their skills base in OpenRoad development
3. XXXXXXX (a company working with Ingres) has developed tools for code analysis and migration to 
OpenRoad Applications Server which have been used to assist other companies 
faced with the same situation as we have with XXX. However a proof of concept exercise would be required to 
ensure an XXX migration would gain sufficient benefits from these tools, e.g. 
through a speedier migration of code and ease of support to justify the additional costs. 
 
Disadvantages
1. The OpenRoad product is viewed as a constraint. It is a “thick client”, requiring 
software delivery to PC’s, it is vendor specific and not standards based, 
also the developer skills base is in decline.
  2. Discussions have been facilitated with Ingres, however XXX remains to be convinced this new supplier has serious 
intentions to develop the product in any major way going forward. 
  3. XXX do not believe the OpenRoad server is the correct way to move XXX away from thick client technology and 
using the Ingres product would also involve third party consultancy and additional licensing costs, 
neither of which are required for this customer for new developments in Java / WebLogic. 
4. While Tuxedo has a place in XXX and serves it well in the transaction management arena it is not able to 
offer non proprietary, standards based interactions with other applications and systems. 
5. Other systems are coming on line and wanting to interact with XXX - and the answer is always if they can talk to a 
Tuxedo service XXX can write one for you. This has already impacted the XXX system, where significant extra licensing costs were incurred in acquiring a 
XXXXXXXXXX Tuxedo adapter and is presently impacting XXX, which is being developed by a third party who want to 
utilise a web service to interact with XXX.
6. A detailed analysis of the XXX client code is a pre requisite for re writing the application, 
however there are no doubts as to feasibility and manageability of a migration to Java and .NET environments.
7. The down side of moving entirely away from Ingres products is the re write of XXX,
however XXX has in recent releases been made deliberately more modular in its design (FB Comment - no it has not) 
with recently added new functionality, such as XXXX Applications.
 
Option 2 – Web Enabling XXX functions
XXX proposes the introduction of BEA WebLogic server, Java and .Net which will “web enable” XXX functions.
Advantages
1. Applications will make calls to XXX processes, services and data using the Simple Object Access Protocol (SOAP). 
SOAP is an Extensible Markup Language (XML) protocol allowing applications to exchange information over 
Hyper Text Transfer Protocol (HTTP).
2. WebLogic is already deployed as part of other XXXXXXXXXXXXX applications supported by XXX and is enterprise site licensed 
when used in the XXXXXXXXXXXXX account, meaning there are no new licensing costs.
3. Java technologies will provide replacement applications with a modern browser based look and feel. 
This technology aligns internal Intranet applications with XXXXXXXXXXXXX existing Internet applications such as XXX. 
.NET will also be used where the richness of the user interaction and / or complexity of processing does 
not lend itself to a browser based application. It is envisaged this will cover a few selected areas 
of business functionality including the existing Visual Basic applications already targeted for re write in .NET 
(these are XXX and XXXX, which are closely integrated with XXX). .NET components will also use web services as their means of interacting with centrally managed processes and data.
4. The use of the XXX OpenRoad client will be run down over time, with its business logic processing being moved to the 
WebLogic layer with front end applications mostly handling just the presentation functions. 
WebLogic is the logical choice to web enable XXX due to out of the box integration with Tuxedo and existing corporate 
licensing agreements for use in the XXXXXXXXXXXXX estate.
5. webLogic is already deployed as part of other XXXXXXXXXXXXX estate. XXX has already produced web services 
using Java / WebLogic so that XXX clients can access XXXXXXXXXXXXXs and perform location based XXXXXXXXXXXXX and 
so the technologies are already deployed to production environments and developer skills widely available.
6. Greater responsiveness to business change requirements – a business area can be updated without a 
complete application upgrade. More functional releases possible in shorter timeframes, 
and reduced development and operating costs.
7. XXXXXX charges will apply to new and enhanced services offered as a result of adopting this strategy. 
Savings are expected through lower unit production costs for releases by using standard and up to 
ate technologies and reductions in support overheads by using common products.
 
No Disadvantages!!!!!!
 
Our current application has lines of code, rewriting in Weblogic/Java/.net is expected to take 36 months.
 
Thanks in advance.
 
Frank.

   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.peerlessit.com/pipermail/openroad-users/attachments/20071031/ab5464e8/attachment.html