[Openroad-users] Comments please

[Antill, Jim]

Hi Kim,
 
I'm afraid I'm not very well up on the OR application server so can't really
comment on it at all, which is why I considered OpenROAD to be a thick-client
in my mail. Something I'll need to look at when I get the time.
 
A big problem I feel is that OpenROAD is somewhat limited in how it can
communicate with other things. Enterprise computing is now all about
communication between reuseable components in different layers, possibly
written in different languages thus enabling the developer to pick the
best-fit language to accomplish a task. And this is something that I think
OpenROAD needs to get better at quickly. 
 
For example, whilst communication with web-services can be achieved by using
3rd party software I think the facility needs to be offered natively within
OpenROAD itself, providing the various mechanisms etc. to make it easy to
form messages, handle errors etc. With OpenROAD being targeted at the
Enterprise market where SOA/web-services are being used more providing this
facility would, I think, vastly increase the appeal and potential of
OpenROAD.
 
Regards,
Jim

-----Original Message-----
From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com]On Behalf Of Kim Ginnerup
Sent: 04 November 2007 07:15
To: International OpenROAD Users
Subject: Re: [Openroad-users] Comments please


*************************************

This e-mail has been received by the Revenue Internet e-mail service. (IP)

*************************************
	

Hi Jim (Frank),

 

It seems to me that you compare web and OpenROAD as thin versus thick.

In my view it is more like: do I install anything application specific stuff
on the client or not.

I think that eClients (and mclients) can be considered kind a thin as well.

I think the only real benefit that html-based thin-client brought was the
simple deployment.
But they left the user back in the middle age when it comes to effective user
interfaces. 

OpenROAD Eclients address this seen from an OpenROAD perspective. Having a
simple deployment mechanism and keeping the rich GUI.

An efficiently written eClient does not give the extra load on the servers as
really thin clients do, because it doesn't need to call the server

Just to scroll to page two in a table. (I now you can do that as well in web
apps if you are willing to invest the time).

With this comment I only address the client side of your mail.


There a pros and cons on the SOA / web-services side as well.

By using OpenROAD servers you can keep the efficient access to data from
OpenROAD clients (and others)

For those that need a web-services access I see the web-services as another
client to the OpenROAD server.

 

 

Kim


  _____  


Fra: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com] På vegne af Antill, Jim
Sendt: 2. november 2007 11:34
Til: International OpenROAD Users
Emne: Re: [Openroad-users] Comments please

 

Frank,

 

Here's a few thoughts on your mail...... I'm not trying to do anyone down,
cast nasturtiums or anything by the way. I also sent this from home and
assume it got bounced, so apologies if people get two copies.

 

I think it's pretty difficult to compare a thick-client application to a
web-based application as the two setups are better suited to different tasks.
Take the GUIs for example. A thick client application can present an
extremely rich user interface that uses many different controls and allows a
large amount of interaction and complexity on a single screen. Whilst this
can be done using a thin client I find that web-applications work better and
are more responsive when using a larger number of simpler screens. Thin
client applications will never mean the end of thick-client and nor should
they. Each has their own place in the scheme of things.

 

One of the benefits of web-applications is that the business logic can be
made accessible relatively easily to other applications by providing an SOA
layer of web-services. Note, by easily I'm not saying it's a piece of cake.
If you're using Tuxedo then I'd say you've pretty much got a service layer in
place. The degree to which your Tuxedo services can interact with other
things would depend, to a degree, on how closely coupled they are to your OR
application e.g do the service inputs mirror userclasses in your OR
applications. Another factor is the granularity of the services e.g do they
perform extremely specific functions, can they be grouped by an intermediate
layer to provide coarser functions? It might be necessary to use an ESB to
make communication between different applications and the Tuxedo services
easier e.g the ESB provides an adaptor that Tuxedo can use. But it should be
possible to expose your Tuxedo services to other applications.

 

Moving on, I'm not 100% sure that a detailed analysis of the client code is
particularly relevant to a re-write. If the rewrite was made necessary by the
code being so confusing/outdated then why spend a load of time analysing it?
Surely the analysis should be focused on the problem that the application
solves, looking at analysis documents constructed at the start of the
application, during it's development and then incorporating any new
requirements. Also included in this would be database design, failings of the
current application, user feedback etc. At the end of the day you're trying
to provide a new application that provides a better solution to a problem
that already has a solution, not trying to replicate the current solution
using new technologies for possibly little gain.

 

Hmm, IMHO anyone that says there are no disadvantages to web-enabling
functions isn't telling the whole story. The biggest disadvantage is that the
whole area of SOA, web-services etc. is still in it's infancy. There are a
lot of things still to be discovered, a lot of ways of doing things badly
without knowing it immediately. It's a lot of analysis work, a lot of
learning, and also a lot of new problems such as increased security, new
types of errors e.g message failure etc. all needing to be taken into
account. The increased communication between the client and server also
places an increased load on the network and also on servers. It could be that
your current network isn't suited to the job and I would certainly take this
into account before waving the "Web-services are the only way" flag. Using
new technologies and making cost savings aren't inherently linked at all.
Just by using something new doesn't mean I'll save money or even expect to.
It might be more expensive but I'd be happy with this if the app I get at the
end of it provides enough benefits over a cheaper solution. Don't get me
wrong, I think there are a lot of advantages of going the web-service route
too, though it depends on whether your application needs to take advantage of
them as whether is an appropriate route to go.

 

The web-enabling XXX functions section doesn't really give any reason as to
why it's better this way for your application. Point 6 is quite true in
theory but how does it work in practice and how relevant is it to your app?
Does the business change so regularly that redeploying a thick-client app is
unmanageable? Given that you're using Tuxedo to supply Business Logic I'd say
this probably isn't the case, unless the services are really tightly-coupled
to the OpenROAD.

 

One approach may be to take things gradually. OpenROAD can call web-services
using SOAP messages, so it would be possible to develop new parts of the
application using SOAP and web-services whilst slowly moving other things
over as required. (You could even introduce a layer so that Tuxedo services
can be called using SOAP, thus loosening the coupling between the OR and
Tuxedo). That way you could see the benefits, the downsides and also get a
feel as to how useful the change in approach would be without spending the 36
months doing it.

 

Just a few rambling thoughts that turned into a longer mail than expected.

 

Regards,

Jim

-----Original Message-----
From: openroad-users-bounces at peerlessit.com
[mailto:openroad-users-bounces at peerlessit.com]On Behalf Of Frank Barratt
Sent: 31 October 2007 09:15
To: openroad-users at peerlessit.com
Subject: [Openroad-users] Comments please


*************************************

This e-mail has been received by the Revenue Internet e-mail service. (IP)

*************************************

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.

 

************************

This message has been delivered to the Internet by the Revenue Internet
e-mail service (OP)

*************************
	



************************

This message has been delivered to the Internet by the Revenue Internet e-mail service (OP)

*************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.peerlessit.com/pipermail/openroad-users/attachments/20071105/3725a015/attachment.html