Uniface migration to some other language
Petr
We are thinking of a possibility of migrating our 2400 component
application from Uniface to Java. But for business to buy our proposal,
we will need to provide strong points stating the problems that
application can have if it remains in Uniface and the advantages that
it will have if migrated.
Have any of us worked on similar lines? Or can of of you provide some
information on how to go about this? We could think about the problems
related to scalability, maintainablity, memory related issues, etc.
The scope here is only to find out convincing reasons to either migrate
or not migrate the application from Uniface to Java.
The techniques for migration can be taken up once the business is
convinced that migration would be beneficial.
Any inputs will be really helpful for me
Thanks and regards,
Petr Antoshin
Petr
Morris, Jeffrey B
1500-form Uniface client/server application in java web.
The stated reason for doing this is that my employer wants to stop
paying maintenance to Compuware and instead use open source tools
because they are cheaper. They fail to take into account that they are
spending way more person hours to rewrite the system than it would take
to support the current system for the next decade. In fact, the total
amount of money allocated to the rewrite project would actually pay our
license to Compuware for many decades to come, so it's pretty much
nonsense to claim that moving away from Uniface is saving us any money
at all.
There is also a huge reduction in developer productivity. We recently
had a request for a new feature in the existing Uniface system, which
will later also have to be implemented in the new java system. The
development manager for that part of the java system estimated 6 weeks
for initial development in java, not to mention debugging, testing, etc.
In Uniface, I was able to add the feature, including user testing and
bug fixing, in 6 hours! That means the new system is over 200 times
less efficient as far as developer time. Somehow my employer calls this
"progress".
Management is already aware that the new system will run slower than the
existing system, and many features will be lost. Of course the users
will not be happy. But still the project continues under the guise that
we are saving money. (The other stated goal is to move to the web
because management feels client/server is not a good technology these
days, but I completely disagree with that as well. Web has its uses and
client/server has its uses. I am sure that client/server will have a
resurgence in a few years, possibly under a different name or in a
different way. These things always go in cycles, and there is no clear
"right" answer.)
Uniface has the great advantage of being a 4GL, and as long as your
developers understand this and its power, they should be more effective
with Uniface.
Compared to java, a disadvantage of Uniface is that there is a licensing
cost associated with it. Of course, you get what you pay for, so be
prepared to spend what you're saving in licensing on paying more
employees to support java instead.
Another theoretical disadvantage to Uniface is that it is owned by a
company who could decide to discontinue the product. Then what would
happen? Well, at the NAUUG a few years ago, someone from the Amsterdam
labs told me that even if no one new ever bought Uniface, there would be
enough support work to keep the developers in the lab working for
another decade. Also, note that Uniface has been around for nearly two
decades already (about twice as long as java), so it's not a fly by
night product. If Compuware were ever to decide to drop it, perhaps
another company would buy it.
Another issue that has occasionally been mentioned around here is that
it's easier to find people to hire who know java than who know Uniface.
That is surely true, but I've never seen this as a big issue. Any
really good programmer should be language agnostic. The basics of
Uniface are not hard to pick up. It should not be hard to train a new
hire in Uniface. Even if you're using java and the new hire already
knows java, it will take that person some time to come up to speed on
how everything is handled in your environment. I maintain that it would
not take significantly longer to do the same in Uniface even including
training the new developer on Uniface itself. (If it does, then hire me
instead! ;)
Petr
Regards,
Petr.
Petr
Regards,
Petr.
Disco Octopus
Hi Petr,
Don't get me wrong.. but I would like to know *your* reasons for doing
this??
By the content of your query here, it looks to me like you have given a
resolution to a non-existant problem.
Why would you be "thinking of a possibility of migrating your 2400
component application from Uniface to Java" if you can't think of any
points to sell this idea.
You say that there are "problems related to scalability,
maintainablity, memory related issues, etc". Are you talking about
Java with these problems? You surely can not be talking about Uniface
for these problems!
What is it you can't face with Uniface?
Disco Octopus
Hi Petr,
Petr
Actually, the company vision states the applications be converted to
WEB architecture by 2008. But the business users are not very
comfortable with changing the application technology.
So i want to know whether there is any justifiable reason for migrating
the application from Uniface to some other technology. In the past, I
am sure that some migration activity would have taken place. I
basically want to know whether there were any tangible improvements or
savings by the entire exercise. If at the end of it, the company gains
from migration to a newer technology, then just intertia to migrate
should not stand as a road block.
Thats the basic point.
Please let me know our view points on this.
Regards,
Antoshin Lazar.
Petr
Actually, the company vision states the applications be converted to
WEB architecture by 2008. But the business users are not very
comfortable with changing the application technology.
So i want to know whether there is any justifiable reason for migrating
the application from Uniface to some other technology. In the past, I
am sure that some migration activity would have taken place. I
basically want to know whether there were any tangible improvements or
savings by the entire exercise. If at the end of it, the company gains
from migration to a newer technology, then just intertia to migrate
should not stand as a road block.
Thats the basic point.
Please let me know our view points on this.
Regards,
Antoshin Lazar.
Arthur Barrett
I've seen a lot of companies *try* and replace a Uniface application
with a non-Uniface application. It's not really a uniface or
non-uniface thing. All legacy applications tend to be feature-rich and
very stable. Any replacement system project will spend a LOT of money
simply documenting the business requirements, then compound that cost
with development resources. If the old system is still ongoing the
"new" project tends to struggle to keep up with the improvements being
made to the "old" system.
If you need to go to web you should look at Uniface server pages, or
using a mixture of USP/ASP/JSP for the client/customer facing stuff and
Uniface services at the back end.
Ultimately it *should* come down to cost/benefit analysis. And just
like COBOL systems, Uniface systems will be maintainable for many
decades to come.
In the very very very rare cases (err - 2 actually) I have seen a
successful (ie: compelted) migration from Uniface to something else -
the reason has been an unlimited budget - they were willing (wanting) to
get away from Uniface no matter what it cost them - and cost them dearly
it did. In one case it was semi justified (I guess) because it was a
VAR - where the application is then on-sold to a customer - so the cost
of the redevelopment was weighed against the benefit of increased sales
through lower licensing fees. In the other case the job of rewriting
was outsourced as a fixed price contract - the contractor estimated 3
months and ended up working 30 months, that's 27 months unpaid by my
estimate.
The grass is no greener on the other side - your application will
benefit most if you invest some money in:
* business analysis
* staff training
* good procedures and tools for configuration management
BTW - very few web applications are written in Java. Some have the web
pages written in JSP, some in ASP and some in Cold Fusion or Web
Objects, but almost all use some sort of "service" at the backend to get
the data: usually Oracle or IBM WebSphere. This is not the same as the
"database" - it's almost identical in strategy to the Uniface services
with either a Uniface client or USP web browser.
Regards,
Arthur
Roger
Because of the bad support for VARs - (the application on-sold to a customer)
from Compuware Uniface, it has been a must to me to know another development
environment, which mean that I have learnt VS.Net , which honestly speaking
have a great potential. And it supports both win-forms and web-forms on the same
premises.
However, I agree with the others, you should think twice before migrating
an existing Uniface-application. At least you should know that you have to do a
lot of extra work, bulding your DALs, BLLs (OR-mappers) and especially connecting the
presentation interface (search-profiles etc.) to these, work that you often get
almost for free in Uniface. You should have good "developers",
not to fail in some aspect.
Regards RogerW.
PS. I hope that the support for VARs will improve.
_______________________________________________
Uniface User Group Discussion Forum
For more information: http://lists.umanitoba.ca/mailman/listinfo/uniface-l
To unsubscribe/set options: http://lists.umanitoba.ca/mailman/options/uniface-l
Petr
recommendable to migrate the application to a different technology from
Uniface.
If somebody can provide any more input, it would be great.. We are
having a very nice discussion out here
Regards,
Antoshin
Roger wrote:
> Hi,
>
> Because of the bad support for VARs - (the application on-sold to a
> customer)
> from Compuware Uniface, it has been a must to me to know another development
> environment, which mean that I have learnt VS.Net, which honestly speaking
> ------=_Part_58751_5957445.1165567844631
> Content-Type: text/html; charset=ISO-8859-1
> X-Google-AttachSize: 2567
>
> <div>Hi,</div>
> <div><br>Because of the bad support for VARs - (the application on-sold to a customer)<br>from Compuware Uniface, it has been a must to me to know another development<br> environment, which mean that I have learnt VS.Net
> , which honestly speaking<br>have a great potential. And it supports both win-forms and web-forms on the same<br>premises.<br>However, I agree with the others, you should think twice before migrating<br>an existing Uniface-application. At least you should know that you have to do a
> <br> lot of extra work, bulding your DALs, BLLs (OR-mappers) and especially connecting the <br>presentation interface (search-profiles etc.) to these, work that you often get<br> almost for free in Uniface. You should have good "developers",
> <br>not to fail in some aspect.<br><br>Regards RogerW.<br><br>PS. I hope that the support for VARs will improve.<br> </div>
> <div><br><br> </div>
> <div><span class="gmail_quote">On 6 Dec 2006 02:17:23 -0800, <b class="gmail_sendername">Petr</b> <<a href="mailto:anto...@gmail.com">anto...@gmail.com</a>> wrote:</span>
> <blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi all,<br><br>We are thinking of a possibility of migrating our 2400 component<br>application from Uniface to Java. But for business to buy our proposal,
> <br>we will need to provide strong points stating the problems that<br>application can have if it remains in Uniface and the advantages that<br>it will have if migrated.<br><br>Have any of us worked on similar lines? Or can of of you provide some
> <br>information on how to go about this? We could think about the problems<br>related to scalability, maintainablity, memory related issues, etc.<br><br>The scope here is only to find out convincing reasons to either migrate
> <br>or not migrate the application from Uniface to Java.<br><br>The techniques for migration can be taken up once the business is<br>convinced that migration would be beneficial.<br><br>Any inputs will be really helpful for me
> <br><br>Thanks and regards,<br>Petr Antoshin<br><br>_______________________________________________<br>Uniface User Group Discussion Forum<br>For more information: <a href="http://lists.umanitoba.ca/mailman/listinfo/uniface-l">
> http://lists.umanitoba.ca/mailman/listinfo/uniface-l</a><br>To unsubscribe/set options: <a href="http://lists.umanitoba.ca/mailman/options/uniface-l">http://lists.umanitoba.ca/mailman/options/uniface-l</a><br></blockquote>
> </div><br>
>
> ------=_Part_58751_5957445.1165567844631--
Petr
recommendable to migrate the application to a different technology from
Uniface.
If somebody can provide any more input, it would be great.. We are
having a very nice discussion out here
Regards,
Antoshin
Roger wrote:
> Hi,
>
> Because of the bad support for VARs - (the application on-sold to a
> customer)
> from Compuware Uniface, it has been a must to me to know another development
> environment, which mean that I have learnt VS.Net, which honestly speaking
JKinSoCAl
extensions to use. A far better option would be .Net using VS 2005.
The productivity tools in VS 2005 would be superior to Uniface for web
development.
JKinSoCAl
extensions to use. A far better option would be .Net using VS 2005.
The productivity tools in VS 2005 would be superior to Uniface for web
development.
Jack Eisenberg
free download from www.tenfold.com as a replacement for Uniface. As a
repository-based requirements-driven tool, it can make use of much of the
skill-set inherent in Uniface programming. However, I find there are many
dimensions to the development process that are automated in Enterprise
Tenfold -- making it an intriguing possibility.
Theo Neeskens
really should have look at Uniface 9.
Good standards & guidelines, like our Frameworks in One, also help a lot.
Sorry for the plug, but I mean it !
Theo Neeskens
Application Development Center
Compuware Professional Services
"JKinSoCAl" <jken...@protocol-national.com> schreef in bericht
news:mailman.83.1165580...@uug.org...
Theo Neeskens
really should have look at Uniface 9.
Good standards & guidelines, like our Frameworks in One, also help a lot.
Sorry for the plug, but I mean it !
Theo Neeskens
Application Development Center
Compuware Professional Services
"JKinSoCAl" <jken...@protocol-national.com> schreef in bericht
news:mailman.83.1165580...@uug.org...
Extance, Paul
We have 2 very large Uniface Apps, 4000+ forms/services
We over a number of years developed a Java Framework to give us many of the
features our Uniface based architecture gave us.
This java framework has been open sourced (http://jaffa.sf.net) and also
includes programs to convert a Uniface Conceptual Schema into Jaffa domain
objects and then auto generate quite sophisticated 'fast forms' based on it.
We have also used this framework for migrating COBOL applications too.
We chose Java as it is Platform independent like Uniface, and in addition it
is also Vendor indepenent too, unlike Uniface. There is also a huge volume
of quality java open source projects to build on too.
For the IDE NetBean or Eclipse are great tools. For the App Server we use
JBoss as its free, but any of the major ones are fine too.
Paul Extance
Chief Technology Officer
MIRO Technologies
-----Original Message-----
From: uniface-...@uug.org [mailto:uniface-...@uug.org] On Behalf
Of JKinSoCAl
Sent: Friday, December 08, 2006 4:13 AM
To: uniface...@lists.umanitoba.ca
Subject: [Uniface-L] Re: Uniface migration to some other language
_______________________________________________
Extance, Paul
Petr
Thanks and regards,
Antoshin
Petr
Thanks and regards,
Antoshin
Andy Heydon
As you've probably deduced from this thread there's more to a migration
that just a pure technology switch. Indeed that maybe the least of the
issues. Java doesn't magically make it easier even with the thousands
of options and addons available, and as Jeff mentions productivity
gains are not to be had unless you invest heavily in frameworks that
handle so much of the work that Uniface does.
But web development is a totally different animal from traditional
client/server. There are many more variables and technologies involved
and IMHO there is not a single technology covering everything.
We, for instance, do not use Uniface's skeleton files anymore. Instead
we use Uniface to serve up XML and other dynamically generated graphic
elements. We use AJAX frameworks to build the front end that are
presented in the browser. This is a split that is working very well for
us as we can build UI intense applications that mimic a client/server
app but retain all of our existing Uniface infrastructure to maintain
the business and data logic.
It has been a relatively easy and trivial process to develop Uniface
server pages (as that is the only entry point from the web) that serve
up the data in XML. The beauty of the very clear separation of concerns
is that our customers can use their own front end generation tools
(PHP, .NET, JSP or whatever) to handle the XML and we can extend the
services unencumbered by UI issues.
Andy