Re: Forms 9i middle tier on client?

DA Morgan <damorgan_at_exesolutions.com> wrote in message news:<3E67C80F.D02D8742_at_exesolutions.com>...
> Ryan Gaffuri wrote:
>
> > mark.beck_at_gmx.de (Mark Beck) wrote in message news:<d055eff1.0303050635.3882c0fd_at_posting.google.com>...
> > > Hi,
> > > due to the approaching desupport of Forms6i, which was client/server
> > > based,
> > > I'm searching for a solution with Forms9i. The design of my
> > > application is
> > > and should be c/s in the future, therefore without a dedicated
> > > application server/middle tier.
> > > The idea is to place the middle tier on the client(OC4J+Forms9i
> > > Servlet&Listener). As long as it meets the hardware specs(P3 >500 MHz;
> > > RAM 256Megs), this should be ok.
> > > The problem is, that I have found an oc4j standalone client on
> > > otn(<25Megs), which installs properly, but I don't know how to fit in
> > > the Forms90-Servlet. On the other side you have to install the
> > > complete OracleiDS Developer Suite(iDS) to get the Forms Developer and
> > > the Forms Servlet Engine on the client(no manual installation
> > > possible). That's around 1.8GB that I don't want to have on
> > > every client.. No option either is to install the complete iAS..
> > >
> > > Is there any way to get a "thin" oc4j+forms9i engine on a client?
> > > Has anyone tried that?
> > >
> > > Kind Regards
> > > Mark
> >
> > You lost me on your reasoning. Oracle took out all client server
> > support in 9i. If you want to use a client/server forms you can still
> > license 6i? Please explain WHY you are doing this?
> >
> > As far as thin. NO forms is a heavy weight tool. This is a huge
> > drawback to web base forms deployment. The network traffic is much
> > higher than with java or even with .net.
> >
> > BTW, why are you even doing a client/server application? All the above
> > being said its cheaper and easier to do a web deployment with forms
> > than a client/server. Ive done both. Now setting up the web server can
> > be a real pain to learn how to do it and making sure all your users
> > have a qualified browser is a little more work, but when that is done,
> > no other deployments????
>
> I can answer your question pretty easily. No need to a web server/app server, no need for that in-house web
> expertise, the fact that installation and configuration of 9iAS is a nightmare for almost everyone that
> hasn't been doing it for a long time, small user base sitting in a single office where client-server is
> faster, easier to maintain, and a lot less hassle.
>
> I'm building an app right now for a client that specifically doesn't want iDS 9i. They have a single
> server, 6 people in one office, and couldn't care less about web vs. client-server. They just want
> something that works.
>
> I am not at all convinced that iDS 9i was a great idea ... either technically or for marketing. In fact I
> think it was a blunder to remove functionality without a single benefit to show for the effort. And there
> is no excuse for a Form being any less efficient than Java other than someone at Oracle not forcing the
> developers to think smarter.
>
> Daniel Morgan

The reason for moving to 9i is simply the desupport at the end of 2003. Oracle has moved this date from formerly 2006. I just don't like the idea of using a desupported product like 6i in a production environment. I think you know the answer from Oracle support in that case if you have a problem: "move to...version x.. and call back later".
So moving away from 6i becomes necessary. One option to stay c/s is to migrate to java/oc4j/jdbc. Migration tools are available, but they do only 95%, I guess. And most people know that the last 5% are the biggest part of work
and costs. On the other side I'm familiar with forms and I tried the 9i developer. It is almost exactly the same as 6i. The surface, the development process and everything else. The only thing you have to do to "migrate" from 6i to 9i is to recompile your *.fmx. The difference is only the place of execution ( ifrun0.exe <->ifweb90.exe) and 9i works impressingly well, surprisingly fast... ...and with the least possible effort.

Just compare the old and the new communication:

client(6i.fmx <-> ifrun60.exe <-> sqlnet) <-> server client(9i.fmx <-> applet <-> forms servlet <-> oc4j <-> jdbc) <-> server

Ok, there are some more layers on the client and you need more memory, but who cares? Everthing is working the same way as it did before. And all you have to do would be to install java,jinitiator,the "thin" forms engine on the client, that isn't available from Oracle(not yet?!?), and recompile
your forms. That's it. Just simple!

The reason why I don't like a dedicated app server is simple too: Imagine 1000 Users working on a 24*7 high availability database. With that scale you need an application server that is as big as the database server itself( doubled costs) and the availability drops due to an additional point of failure. And that is marketed to be better than the way it is working now? I can't believe that.

And to say it with a wink: Today you can answer user problem questions like "I'm sorry, but another user has locked the row you're working on; you can't change it at the moment" and that's understandable. And in future? You'll have to answer this questions with sentences like: "I'm sorry, but your persistent bean must have been fallen out of the container.". "Hm?, Container?"...

The only thing Oracle has to do to make a 9i c/s solution possible is to allow the custom installation option of the iDS. That can't be that complicated.

I think it's ok to use iAS and pay for it if you're using an internet application that has to take care of SQLNet Roundtrips for example or just need a thin client without an Oracle installation. But to force users to migrate to a complete new solution with additional costs(app server license+hardware), which is worse( availability) and in that short time( end 2003) is far from being ok; it's just silly.

Mark Received on Fri Mar 07 2003 - 17:22:41 CET