Re: Forms 9i middle tier on client?
From: Frank <fvanbortel_at_netscape.net>
Date: Fri, 14 Mar 2003 22:51:23 +0100
Message-ID: <3E724EDB.3010406_at_netscape.net>
>
>
> 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
Date: Fri, 14 Mar 2003 22:51:23 +0100
Message-ID: <3E724EDB.3010406_at_netscape.net>
Mark Beck wrote:
> DA Morgan <damorgan_at_exesolutions.com> wrote in message news:<3E67C80F.D02D8742@exesolutions.com>...
>
[Quoted] >>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
End 2003 wasn't what stuck in my brains... Now that doesn't say much, so I just checked... ECS 31-12-2004, EAS 31-12-2007. See: http://metalink.oracle.com/metalink/plsql/ml2_documents.showDocument?p_database_id=NOT&p_id=228666.1
-- Regards, Frank van BortelReceived on Fri Mar 14 2003 - 22:51:23 CET