Forte, iiop, and java 2 woes

We are running Forte 3L2, and Java 2. We'd like to make calls to a forte SO
from a Java client. We can configure the SO for export, and find the ior
file.
However, the java side never seems to work. The idl compiler for JDK 1.2.x
(idltojava, downloaded from SUN) gives lots syntax errrors, these appear
without explanation on apparently good lines. The compiler for JDK 1.3.0
(idlj) only complains about some errors coming from a escaped strings, which
I can patch around.
The java files resulting from idlj need some minor patching/renaming to
compile (Had to put some of the primitive class helpers into Framework
project manually). And then, they fail at runtime. They fail with a null
object error when run in the 1.3.0 runtime. They fail with the same CORBA
exception when run in either the JDK 1.2.2 runtime, or the naturalbridge
native java compiled runtime.
Does anybody have a specific combination of Java 2 jvm and idl compiler
which will work with Forte? Were any specific tricks needed to make it
work? I tried the technotes, but those that I found seemed out of date for
Java 2.

If you look at the exception information in the iiop manual it
discusses exteneded propties DefaultThrowsClause, ThrowsClause and
IsThrowable.
If you mark your exception class with IsThrowable it will show up in the
IDL as an exception. If you use either DefaultThrowsClause(project) or
ThrowsClause(method) you will get the appropriate raises in the idl.
This will cause the idl2java to produce code which will allow you to catch
the exception.
Tom.
At 09:41 AM 1/29/99 +0100, Giuseppe Sorce wrote:
>
Hi all,
I am currently working to an architecture to establish a communication
between a Forte' server and a Java client, using Visigenic's Visibroker and
IDL mode.
I have problems when I try to raise a Forte' exception from a method
invoked by the Java client; I would like the exception class
(ProductException) not to inherit from the class GenericException, because
the IDL I want to generate must have this structure:
exception ProductException {
string message;
Using this solution, the client application gets blocked waiting forever.
I am currently working with:
- Forte' 3.0.G.2 plus WebEnterprise 1.0.B
- JDK 1.1.5
- Visibroker 3.1
My question is: is it possible to raise an exception from the Forte' side
that is
compliant to the IDL mentioned above?
Of course it should be caught from the Java side.
Thank you in advance
Giuseppe Sorce
CSI Piemonte - C.so Unione Sovietica 216 - 10134 Torino - ITALY
tel. +39-011-3168736
fax +39-011-3168212
e-mail [email protected]
url http://www.csi.it
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
To unsubscribe, email '[email protected]' with
'unsubscribe forte-users' as the body of the message.
Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

Similar Messages

  • Forte IIOP / Corba / Java more questions...

    Hi,
    I wonder if any Forte / IIOP / Java people can help...
    We are a Forte site developing an application using the Forte Web SDK (
    window converter / Javascript etc ) and using the Forte external connection
    class to enable direct communication between Fort Service objects and Java
    applets. We are considering using Corba / IIOP for Java <-> Forte comms but
    I could use some advice.
    Has anyone compared data transfer rates for Forte client <-> Forte remote
    service object vs Java IIOP client to Forte IIOP Service object ( all
    across the same LAN ) ? There are of course many factors that might
    influence data transfer speeds - but any info would be appreciated. I
    really just want to know IIOP communication rates differ from those handled
    end-to-end by Forte.
    Secondly, does anyone know about scalability of the Forte IIOP Gateway or
    Forte IIOP listeners - how many simultaneous IIOP connections can be
    supported ?
    Thirdly, does anyone know if there are memory limitations for applets
    running in browsers - can an applet request additional memory - or is it
    simply part of the browsers overall allocation ( important for the Mac
    platform ? )
    Finally, has anyone used OrbixWeb as the IIOP Java client - experiences,
    warnings etc. appreciated.
    Cheers - Dave.
    Dave Maclaurin, ITS, University of Otago, Dunedin, New Zealand
    mailto:[email protected]
    Ph (03) 4798530

    Hi,
    I wonder if any Forte / IIOP / Java people can help...
    We are a Forte site developing an application using the Forte Web SDK (
    window converter / Javascript etc ) and using the Forte external connection
    class to enable direct communication between Fort Service objects and Java
    applets. We are considering using Corba / IIOP for Java <-> Forte comms but
    I could use some advice.
    Has anyone compared data transfer rates for Forte client <-> Forte remote
    service object vs Java IIOP client to Forte IIOP Service object ( all
    across the same LAN ) ? There are of course many factors that might
    influence data transfer speeds - but any info would be appreciated. I
    really just want to know IIOP communication rates differ from those handled
    end-to-end by Forte.
    Secondly, does anyone know about scalability of the Forte IIOP Gateway or
    Forte IIOP listeners - how many simultaneous IIOP connections can be
    supported ?
    Thirdly, does anyone know if there are memory limitations for applets
    running in browsers - can an applet request additional memory - or is it
    simply part of the browsers overall allocation ( important for the Mac
    platform ? )
    Finally, has anyone used OrbixWeb as the IIOP Java client - experiences,
    warnings etc. appreciated.
    Cheers - Dave.
    Dave Maclaurin, ITS, University of Otago, Dunedin, New Zealand
    mailto:[email protected]
    Ph (03) 4798530

  • IIOP and Java 2.0

    Has anyone had any success connecting a client written using Java 2.0 and
    the Java 2.0 ORB classes, to a Forte Service Object?
    When I try the approach taken in the Forte tutorial (Tech Note 10950), a
    security exception is raised. See following:
    C:\Projects\SkunkWorks\CE\IDLGen>java CEClient ce.ior
    Exception in thread "main" java.lang.SecurityException: ORBSingleton: access
    denied
    at
    com.sun.CORBA.idl.ORBSingleton.string_to_object(ORBSingleton.java:229)
    at CEClient.main(CEClient.java:80)
    When I try the approach taken in the Java tutorial, the NameService cannot
    be resolved. See following:
    C:\Projects\SkunkWorks\ForteDemo\IDLGen>java castaxc
    ERROR : org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: No
    org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: No
    at com.sun.CORBA.iiop.ConnectionTable.get(Compiled Code)
    at com.sun.CORBA.iiop.GIOPImpl.createRequest(GIOPImpl.java:78)
    at com.sun.CORBA.iiop.GIOPImpl.createRequest(GIOPImpl.java:62)
    at
    com.sun.CORBA.idl.GenericCORBAClientSC.createRequest(GenericCORBAClientSC.ja
    va:138)
    at
    com.sun.CORBA.idl.InitialNamingClient.resolve(InitialNamingClient.java:194)
    at
    com.sun.CORBA.idl.InitialNamingClient.cachedInitialReferences(InitialNamingC
    lient.java:275)
    at
    com.sun.CORBA.idl.InitialNamingClient.resolve_initial_references(InitialNami
    ngClient.java:184)
    at com.sun.CORBA.idl.ORB.resolve_initial_references(ORB.java:1098)
    at castaxc.main(castaxc.java:24)
    Thanks, in advance
    Perry Everitt
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

    Has anyone had any success connecting a client written using Java 2.0 and
    the Java 2.0 ORB classes, to a Forte Service Object?
    When I try the approach taken in the Forte tutorial (Tech Note 10950), a
    security exception is raised. See following:
    C:\Projects\SkunkWorks\CE\IDLGen>java CEClient ce.ior
    Exception in thread "main" java.lang.SecurityException: ORBSingleton: access
    denied
    at
    com.sun.CORBA.idl.ORBSingleton.string_to_object(ORBSingleton.java:229)
    at CEClient.main(CEClient.java:80)
    When I try the approach taken in the Java tutorial, the NameService cannot
    be resolved. See following:
    C:\Projects\SkunkWorks\ForteDemo\IDLGen>java castaxc
    ERROR : org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: No
    org.omg.CORBA.COMM_FAILURE: minor code: 1 completed: No
    at com.sun.CORBA.iiop.ConnectionTable.get(Compiled Code)
    at com.sun.CORBA.iiop.GIOPImpl.createRequest(GIOPImpl.java:78)
    at com.sun.CORBA.iiop.GIOPImpl.createRequest(GIOPImpl.java:62)
    at
    com.sun.CORBA.idl.GenericCORBAClientSC.createRequest(GenericCORBAClientSC.ja
    va:138)
    at
    com.sun.CORBA.idl.InitialNamingClient.resolve(InitialNamingClient.java:194)
    at
    com.sun.CORBA.idl.InitialNamingClient.cachedInitialReferences(InitialNamingC
    lient.java:275)
    at
    com.sun.CORBA.idl.InitialNamingClient.resolve_initial_references(InitialNami
    ngClient.java:184)
    at com.sun.CORBA.idl.ORB.resolve_initial_references(ORB.java:1098)
    at castaxc.main(castaxc.java:24)
    Thanks, in advance
    Perry Everitt
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

  • Forte IIOP / Corba / Java other questions...

    I've a problem with Forte (3.0.E.0) generating IDL that is causing
    Visigenic Visibroker 2.5 (for Java) compile errors...
    It has something to do with the order(ing) of interfaces declaration
    and referencing these interfaces within the generated IDL file ...
    To fix thix, I've to hand edit the IDL file and declare the interfaces
    before they are referenced in some other Interface declaration...Since
    we have a lot of classes, it can take time to do this...
    Is this a known bug ? undocumented behavior ? is there any way to
    workaround this ? I would assume that Interface declaration/referencing
    should be done in proper order (When forte generates IDL), but it is
    not.
    Thanks for any help,
    --francois
    Francois Orsini
    Evolve Inc - 615 Battery Street - San Francisco, CA 94111
    (415) 439-4076 - Email: [email protected]

    I've a problem with Forte (3.0.E.0) generating IDL that is causing
    Visigenic Visibroker 2.5 (for Java) compile errors...
    It has something to do with the order(ing) of interfaces declaration
    and referencing these interfaces within the generated IDL file ...
    To fix thix, I've to hand edit the IDL file and declare the interfaces
    before they are referenced in some other Interface declaration...Since
    we have a lot of classes, it can take time to do this...
    Is this a known bug ? undocumented behavior ? is there any way to
    workaround this ? I would assume that Interface declaration/referencing
    should be done in proper order (When forte generates IDL), but it is
    not.
    Thanks for any help,
    --francois
    Francois Orsini
    Evolve Inc - 615 Battery Street - San Francisco, CA 94111
    (415) 439-4076 - Email: [email protected]

  • RE: Java-based Client for Forte/IIOP

    We have deployed an application using JDK 1.1.6,
    Swing 1.0.3, Visibroker 3.2, and Forte 3.0.G.2.
    We are also using Forte's Java Interoperability
    Service.
    We have a closely-held client base (i.e. not a
    million random yahoos off the internet), so we can
    secure a Java port between client and server and
    download a fairly significant client. The Java
    client is deployed with Sun's JRE (to control the
    environment) with the following configuration:
    2.6 MB JRE
    765 KB Forte.zip
    2.0 MB swingall.jar
    1.6 MB vbjtools.jar, vbjorb.jar
    100 KB application classes
    1) The Swing controls don't interoperate well
    with the AWT and Symantec widgets, especially in
    an internal frame. They paint slowly on top of
    each other, move jerkily, and paint before moving
    to the programmed coordinates so it looks silly.
    100% Swing controls play well with other Swing
    controls and are reasonably fast.
    2) We used Symantec Cafe 2.5a to paint the
    screens, and had some problems with the
    setLayout(null) on things like the Swing tab
    folder and split panel. Commenting out the line
    fixed it, but I'm hoping Cafe 3.0 will fix it (I
    have a person installing it but haven't gotten a
    report...)
    3) The initial search time to turn an IOR file
    into a reference is an annoying 10 seconds, and
    the first method call takes about 7 seconds, but
    after that is less than a tenth of a second.
    Haven't done any digging to find out why yet.
    4) If we were deploying this as an applet, we
    would probably use the IDL IIOP export--when using
    the Java Interoperability service, any method call
    seems to load the whole 765K across the
    line...class by class. Ugly. IDL just gets what
    it needs and is smaller.
    5) Also, if deploying as an applet, we wouldn't
    have to download the JRE or visibroker jar files,
    and would only download the swing and Forte IDL
    generated classes as needed, so it would be a much
    smaller footprint than the 7MB above. (Note:
    However, we would be at the mercy of the browser
    being used by client.) Different strokes for
    different folks...
    -DFR
    From: [email protected]
    Date: Tue, 01 Dec 1998 15:15:18 -0800
    Subject: RE: Java-based Client for Forte/IIOP
    Sean,
    My worry is that Swing, while eloquently designed,
    represents an attempt to
    write a totally new display system which, at least
    in the case of my
    project, will run on top of Windows. I really like
    the Java (or a Java-like
    i.e. J++) language, but I feel safer using the
    native MS widgets. It does
    not seem that anyone on this forum has used Swing
    extensively and can
    testify to its stability and performance.
    Regards,
    David
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

    We have deployed an application using JDK 1.1.6,
    Swing 1.0.3, Visibroker 3.2, and Forte 3.0.G.2.
    We are also using Forte's Java Interoperability
    Service.
    We have a closely-held client base (i.e. not a
    million random yahoos off the internet), so we can
    secure a Java port between client and server and
    download a fairly significant client. The Java
    client is deployed with Sun's JRE (to control the
    environment) with the following configuration:
    2.6 MB JRE
    765 KB Forte.zip
    2.0 MB swingall.jar
    1.6 MB vbjtools.jar, vbjorb.jar
    100 KB application classes
    1) The Swing controls don't interoperate well
    with the AWT and Symantec widgets, especially in
    an internal frame. They paint slowly on top of
    each other, move jerkily, and paint before moving
    to the programmed coordinates so it looks silly.
    100% Swing controls play well with other Swing
    controls and are reasonably fast.
    2) We used Symantec Cafe 2.5a to paint the
    screens, and had some problems with the
    setLayout(null) on things like the Swing tab
    folder and split panel. Commenting out the line
    fixed it, but I'm hoping Cafe 3.0 will fix it (I
    have a person installing it but haven't gotten a
    report...)
    3) The initial search time to turn an IOR file
    into a reference is an annoying 10 seconds, and
    the first method call takes about 7 seconds, but
    after that is less than a tenth of a second.
    Haven't done any digging to find out why yet.
    4) If we were deploying this as an applet, we
    would probably use the IDL IIOP export--when using
    the Java Interoperability service, any method call
    seems to load the whole 765K across the
    line...class by class. Ugly. IDL just gets what
    it needs and is smaller.
    5) Also, if deploying as an applet, we wouldn't
    have to download the JRE or visibroker jar files,
    and would only download the swing and Forte IDL
    generated classes as needed, so it would be a much
    smaller footprint than the 7MB above. (Note:
    However, we would be at the mercy of the browser
    being used by client.) Different strokes for
    different folks...
    -DFR
    From: [email protected]
    Date: Tue, 01 Dec 1998 15:15:18 -0800
    Subject: RE: Java-based Client for Forte/IIOP
    Sean,
    My worry is that Swing, while eloquently designed,
    represents an attempt to
    write a totally new display system which, at least
    in the case of my
    project, will run on top of Windows. I really like
    the Java (or a Java-like
    i.e. J++) language, but I feel safer using the
    native MS widgets. It does
    not seem that anyone on this forum has used Swing
    extensively and can
    testify to its stability and performance.
    Regards,
    David
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

  • Can Forte' IIOP Client catch Java exceptions?

    Hi all,
    we are using Forte' IIOP features in IDL Mode, to integrate a Forte' client
    and a Java server.
    Our configuration is:
    - java jdk 1.1.5
    - Visigenic VIsibroker 3.1 for Java ORB
    - Forte' 3.0.G
    Is it possible for the Forte' client to catch a Java exception?
    We tried to define an IDL file based on our Java server:
    module querye
    interface QueryClass
    exception MiaSQLException{};
    string EseguiQuery(in string query_string) raises
    (MiaSQLException);
    Using forte' corbagen utility we generated the forte' .pex file:
    begin TOOL querye;
    forward QueryClass;
    class QueryClass inherits from Framework.Object
    class MiaSQLException inherits from FrameWork.GenericException
    end class;
    has public method EseguiQuery(
    input query_string : string
    ) : string;
    has property
    distributed=(allow=on, override=on, default=on);
    end class;
    method QueryClass.EseguiQuery(
    input query_string : string
    ) : string
    begin
    end method;
    end querye;
    We we tried to import the .pex file in the forte' repository, forte' raise
    a Syntax Error.
    Any idea?
    TIA
    Giuseppe Sorce
    CSI Piemonte - C.so Unione Sovietica 216 - 10134 Torino - ITALY
    tel. +39-011-3168736
    fax +39-011-3168212
    e-mail [email protected]
    url http://www.csi.it
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

    I am trying to get Forte to communicate with Orbix (not the web
    version) via IIOP. Right now I am trying to set up an Orbix C++
    server with Forte being the client. Eventually I will need to
    communicate the other way (Forte being the server -- I need to do
    both). Right now I cannot get Forte to connect to the server. Any
    suggestions would be appreciated.
    Thanks in advance,
    Dale Boan
    Details
    I am running Forte on an NT machine and the Orbix server under HP-UX.
    Under NT, I am using Forte 3.0.F.2 with IIOP enabled (I think - it
    shows up in the partition GUI).Which version of Orbix are you using? I believe 2.3c is required. At least I
    know that Forte has successfully called Orbix services using 2.3c.
    - Coty

  • Forte' and Java IOOP in mission criticalapplications.

    Hi,
    Has anybody had any experience in the development of Java/IIOP/Forte'
    applications in large scale, mission critical, environments?
    We've developped a full function prototype application and it looks as if
    the Forte' IIOP listener could easily become a bottleneck in the overall
    architecture configuration: infact we think it is not possible to configure
    it for load balancing and/or failover and that any solution in this field
    should be carried out outside Forte'.
    Any ideas/comments?
    Thanks a lot,
    Ernesto Moscatelli
    SEMAGROUP Italy
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

    Hi
    I've been playing with a variation of the custom router you describe below to
    avoid having my server side partitions being pulled onto my client.
    Essentially each of my server side partitions registers themselves with a
    router set up to service that particular partition. The "clients" then request
    a reference to the server side partition from the custom router. This
    reference is then used to invoke the services provided by my server side
    partitions.
    On the box I am testing (RS 6000) my custom router (performing round robin
    routing) is between 90ms and 100ms slower the Forte's own router. However,
    since my server side partition can be multi-threaded as soon as there are more
    tasks requiring the service than there are partitions I start to see a
    performance improvement.
    While I was testing this (and a few other things) I noticed that it seemed to
    be awfully easy to flood a Forte partition (running Forte threads) with tasks
    (around 8 as far as I could tell) to the point where the partition seems to
    spend all of its time servicing the threads rather than doing any real work.
    Does anyone know at what number of tasks the Forte threading model breaks down?
    Or, if there are any ways of controlling the "thread processing time".
    Cheers,
    Darren
    From: Scott Irwin <[email protected]>
    To: 'Peter Sham (HTHK - Assistant Manager - Software Development, IITB)'<[email protected]>; [email protected]
    Cc: [email protected]
    Subject: RE: Forte' and Java IOOP in mission critical applications.
    Date: 23 March 1999 13:44
    We are implementing a Java Bean which communicates via IIOP to our SO. We
    didn't like forte's router so we developed a custom 'Intelligent' router.
    The Bean first resolves the CustomerRouterSO. The CustomerRouterSO is set
    for only Fail-Over. Our real SO that does all of the work is our
    ReplicateSO which is load balanced and registers with the CustomerRouterSO.
    The CustomRouterSO does not hold state in case it fails. ReplicateSO know
    (based on env) if they are primary or secondary type SO and tell the
    CustomRouterSO.
    In the CustomRouterSO you can add any type of logic you need to determine
    which ReplicateSO you want to assign back from the connect(). In our case,
    each ReplicateSO keeps a count of the number of clients assigned, and the
    CustomRouterSO asks the ReplicateSO if it can handle another assignment.
    We needed this type of behavior because our objects are chockfull of state.
    If you need Message type duration then it's another game. We are heading
    into Stress Test in a few weeks so we will see if this will fly.
    Have Fun!
    Scott Irwin
    -----Original Message-----
    From: Peter Sham (HTHK - Assistant Manager - Software Development,
    IITB) [SMTP:[email protected]]
    Sent: Tuesday, March 23, 1999 4:38 AM
    To: [email protected]
    Cc: [email protected]
    Subject: RE: Forte' and Java IOOP in mission critical
    applications.
    Hi,
    I'm not expert on this field, but if the configuration is like this,
    should
    this load-balance/failover responsibility be on the shoulder of the
    COBRA
    ORB, instead on Forte?
    Peter Sham.
    -----Original Message-----
    From: [email protected]
    [SMTP:[email protected]]
    Sent: Tuesday, March 23, 1999 4:57 PM
    To: [email protected]
    Subject: Forte' and Java IOOP in mission critical
    applications.
    Hi,
    Has anybody had any experience in the development of
    Java/IIOP/Forte'
    applications in large scale, mission critical, environments?
    We've developped a full function prototype application and
    it looks
    as if
    the Forte' IIOP listener could easily become a bottleneck in
    the
    overall
    architecture configuration: infact we think it is not
    possible to
    configure
    it for load balancing and/or failover and that any solution
    in this
    field
    should be carried out outside Forte'.
    Any ideas/comments?
    Thanks a lot,
    Ernesto Moscatelli
    SEMAGROUP Italy
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive
    <URL:http://pinehurst.sageit.com/listarchive/>
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive
    <URL:http://pinehurst.sageit.com/listarchive/>
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>-
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

  • Java-based Client for Forte/IIOP

    My project is evaluating tools to build the next version of order
    entry/production management system. The first version is written entirely
    in Forte.
    We are considering 3 options for the client:
    1.Visual J++/ORBIX COMet (WFC widgets)
    2. Visual Cafe / ORBIX for Java (Swing Widgets)
    3. GOFC (Good old Forte Client)
    The back-end will probably remain Forte/Oracle on Solaris.
    If anyone has experience with these tools I would like to hear from you.
    I've tried J++/WFC last week and it seems to be solid. I am curious if
    Swing is ready for prime time.
    Regards,
    David
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

    Sean,
    My worry is that Swing, while eloquently designed, represents an attempt to
    write a totally new display system which, at least in the case of my
    project, will run on top of Windows. I really like the Java (or a Java-like
    i.e. J++) language, but I feel safer using the native MS widgets. It does
    not seem that anyone on this forum has used Swing extensively and can
    testify to its stability and performance.
    Regards,
    David
    At 12:40 PM 12/1/98 -0700, you wrote:
    The last I heard it is Swing and JDK 1.2 in release 4.
    Cornice Consulting Inc.
    Phone: (303) 688-5016
    mailto:[email protected]
    -----Original Message-----
    From: [email protected]
    [<a href="mailto:[email protected]">mailto:[email protected]]On</a> Behalf Of Thomas Mercer-Hursh,
    Ph.D.
    Sent: Tuesday, December 01, 1998 10:20 AM
    To: [email protected]
    Subject: Re: Java-based Client for Forte/IIOP
    At 08:56 PM 11/30/98 -0800, [email protected] wrote:
    I am curious if
    Swing is ready for prime time.Isn't Swing what Forte is using in R4?
    =========================================================================
    Thomas Mercer-Hursh, Ph.D email: [email protected]
    Computing Integrity, Inc. sales: 510-233-9329
    550 Casey Drive - Cypress Point support: 510-233-9327
    Point Richmond, CA 94801-3751 fax: 510-233-6950
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:<a href=
    "http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
    >>
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:<a href=
    "http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>
    >
    >
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:<a href=
    "http://pinehurst.sageit.com/listarchive/">http://pinehurst.sageit.com/listarchive/</a>>

  • RE: (forte-users) RE: Forte 3 vs Java --Productivity

    I think you should compare language to language, product to product
    and standard to standard. J2EE is a standard, like CORBA. It's not
    a product and it's not a language. J2EE is a standard, based on the
    language Java, but the same standard can be used in the context
    of Smalltalk, Cobol, Basic or TOOL as well. We have yet to see any
    development tool that actually supports full J2EE. And how many
    ORB's out there are really 100% CORBA 2.0 complient and offer
    full interoperability through IIOP with other CORBA 2.0 complient
    products?
    The title of this entire thread is wrong. It's not Forte vs. Java, but
    TOOL vs. Java or Forte vs. any Java-based ADE.
    EJB, J2EE and CORBA are open standards, intended to facilitate
    building large, component based applications. But they're only
    standards, they're not usable products. Forte is a usable product.
    It is a (propriaty) ORB, if offers lots of advanced component based
    features and it uses a propriaty OO language called TOOL. Forte
    was doing all this way before the world was debating CORBA, then
    Java, then EJB and now J2EE.
    Sure, when you really look at it, these standards are more complete
    and include more design patterns than the way Forte solved the
    problem, but the situation is still that, despite all those wonderfull
    standards, Forte is still the product with the most advanced capa-
    bilities that actually delivers.
    The challenge to Forte is to incorporate those standards within their
    own product. Are they going to build 2 products, one TOOL-based
    and one Java-based, or are they going to integrate TOOL and Java,
    or are they going to drop TOOL? Are they going to support J2EE
    and will they keep offering those wonderfull distributed features that
    are currently in Forte and are not part of J2EE? Will they switch
    completely to JDBC or will they integrate DBSessions with JDBC?
    Will their ORB functionality remain closed or will the Forte environ-
    ment become a full CORBA 2.0 complient environment? Will they
    keep supporting DCOM? Will they allow JavaBeans, EJB, Forte
    service objects, OLE-objects, Servlets and Active-X components
    to co-exist or will that remain SF? Are they going to support Swing?
    Are they going to include an HTML-Browser widget? Are they going
    to, natively, support JavaScript? What about VB-script? What
    about Perl-script? What about TOOL-script??? Will they include
    an object-based reporting tool, so you don't have to circumvent
    the application and report against the relational database? Will
    this reporting tool be Java-based, TOOL-based, both, EJB-based,
    CORBA-based or whatever? Will they support JPEG and PNG as
    well as BMP and GIF? Will they allow you to store these images in
    the repository? Will they include a full-featured web-publisher that
    supports HTML and XML as well as seemlessly integrate with Forte
    applications? Will they allow you to deploy your (static) web-pages
    on a web-server using E-console?
    -----Original Message-----
    From: Thomas Mercer-Hursh, Ph.D. [SMTP:thomascintegrity.com]
    Sent: Monday, February 14, 2000 6:10 PM
    To: 'kamranaminyahoo.com'
    Subject: (forte-users) RE: Forte 3 vs Java -- Productivity
    At 09:04 AM 2/14/2000 , Genesio, Fabrizio wrote:
    Our users/customers are waiting for application right now, and
    today with Java you may do it, but how expensive and reliable are all
    the "+" signs of your equation? I am sure, in the moment somebody (Fort&eacute;
    For Java?) will propose an integrated Java environment capable to
    seriously support development/assembly/deployment/maintenance, everybody
    will immediately consider it as an alternative to Fort&eacute;.Not an alternative ... check out FJEE, formerly known as SynerJ. They did
    it right with TOOL, now they have done it right with Java. I still prefer
    TOOL as the more productive, more elegant language, but if you have to use
    Java, Forte has given you the way to do it right.
    =========================================================================
    Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
    Computing Integrity, Inc. sales: 510-233-9329
    550 Casey Drive - Cypress Point support: 510-233-9327
    Point Richmond, CA 94801-3751 fax: 510-233-6950
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

    I think you should compare language to language, product to product
    and standard to standard. J2EE is a standard, like CORBA. It's not
    a product and it's not a language. J2EE is a standard, based on the
    language Java, but the same standard can be used in the context
    of Smalltalk, Cobol, Basic or TOOL as well. We have yet to see any
    development tool that actually supports full J2EE. And how many
    ORB's out there are really 100% CORBA 2.0 complient and offer
    full interoperability through IIOP with other CORBA 2.0 complient
    products?
    The title of this entire thread is wrong. It's not Forte vs. Java, but
    TOOL vs. Java or Forte vs. any Java-based ADE.
    EJB, J2EE and CORBA are open standards, intended to facilitate
    building large, component based applications. But they're only
    standards, they're not usable products. Forte is a usable product.
    It is a (propriaty) ORB, if offers lots of advanced component based
    features and it uses a propriaty OO language called TOOL. Forte
    was doing all this way before the world was debating CORBA, then
    Java, then EJB and now J2EE.
    Sure, when you really look at it, these standards are more complete
    and include more design patterns than the way Forte solved the
    problem, but the situation is still that, despite all those wonderfull
    standards, Forte is still the product with the most advanced capa-
    bilities that actually delivers.
    The challenge to Forte is to incorporate those standards within their
    own product. Are they going to build 2 products, one TOOL-based
    and one Java-based, or are they going to integrate TOOL and Java,
    or are they going to drop TOOL? Are they going to support J2EE
    and will they keep offering those wonderfull distributed features that
    are currently in Forte and are not part of J2EE? Will they switch
    completely to JDBC or will they integrate DBSessions with JDBC?
    Will their ORB functionality remain closed or will the Forte environ-
    ment become a full CORBA 2.0 complient environment? Will they
    keep supporting DCOM? Will they allow JavaBeans, EJB, Forte
    service objects, OLE-objects, Servlets and Active-X components
    to co-exist or will that remain SF? Are they going to support Swing?
    Are they going to include an HTML-Browser widget? Are they going
    to, natively, support JavaScript? What about VB-script? What
    about Perl-script? What about TOOL-script??? Will they include
    an object-based reporting tool, so you don't have to circumvent
    the application and report against the relational database? Will
    this reporting tool be Java-based, TOOL-based, both, EJB-based,
    CORBA-based or whatever? Will they support JPEG and PNG as
    well as BMP and GIF? Will they allow you to store these images in
    the repository? Will they include a full-featured web-publisher that
    supports HTML and XML as well as seemlessly integrate with Forte
    applications? Will they allow you to deploy your (static) web-pages
    on a web-server using E-console?
    -----Original Message-----
    From: Thomas Mercer-Hursh, Ph.D. [SMTP:thomascintegrity.com]
    Sent: Monday, February 14, 2000 6:10 PM
    To: 'kamranaminyahoo.com'
    Subject: (forte-users) RE: Forte 3 vs Java -- Productivity
    At 09:04 AM 2/14/2000 , Genesio, Fabrizio wrote:
    Our users/customers are waiting for application right now, and
    today with Java you may do it, but how expensive and reliable are all
    the "+" signs of your equation? I am sure, in the moment somebody (Fort&eacute;
    For Java?) will propose an integrated Java environment capable to
    seriously support development/assembly/deployment/maintenance, everybody
    will immediately consider it as an alternative to Fort&eacute;.Not an alternative ... check out FJEE, formerly known as SynerJ. They did
    it right with TOOL, now they have done it right with Java. I still prefer
    TOOL as the more productive, more elegant language, but if you have to use
    Java, Forte has given you the way to do it right.
    =========================================================================
    Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
    Computing Integrity, Inc. sales: 510-233-9329
    550 Casey Drive - Cypress Point support: 510-233-9327
    Point Richmond, CA 94801-3751 fax: 510-233-6950
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

  • RE: Forte, Tuxedo and ACMS

    Hallo Rick,
    I have no confirmation about the actual status at Fort&eacute;, but we
    interfaced Tuxedo using a normal C wrapping.
    It works very well, with good performances.
    By the way, it exists a shareware about a Tuxedo interface. You can
    download it from www.forte.com.
    Let me know if you need more information,
    Best regards
    Fabrizio Genesio
    Datasign AG f&uuml;r Informatik
    Ch. d'Eysins 53a
    CH-1260 Nyon, Switzerland
    Tel. : +41 22 361 04 04
    Fax : +41 22 361 01 10
    Mobile : +41 79 601 81 31
    E-mail : mailto:[email protected]
    Web : http://www.datasign.ch
    -----Original Message-----
    From: Rick Greenwald [SMTP:[email protected]]
    Sent: Friday, February 06, 1998 10:20
    To: '[email protected]'
    Subject: Forte, Tuxedo and ACMS
    All -
    Does Forte have an interface to Tuxedo and/or ACMS? Have any of you
    used it?
    I would appreciate any information I could get. Please respond to me
    directly, as I am not a regular member of the list.
    - Rick Greenwald

    If you look at the exception information in the iiop manual it
    discusses exteneded propties DefaultThrowsClause, ThrowsClause and
    IsThrowable.
    If you mark your exception class with IsThrowable it will show up in the
    IDL as an exception. If you use either DefaultThrowsClause(project) or
    ThrowsClause(method) you will get the appropriate raises in the idl.
    This will cause the idl2java to produce code which will allow you to catch
    the exception.
    Tom.
    At 09:41 AM 1/29/99 +0100, Giuseppe Sorce wrote:
    >
    Hi all,
    I am currently working to an architecture to establish a communication
    between a Forte' server and a Java client, using Visigenic's Visibroker and
    IDL mode.
    I have problems when I try to raise a Forte' exception from a method
    invoked by the Java client; I would like the exception class
    (ProductException) not to inherit from the class GenericException, because
    the IDL I want to generate must have this structure:
    exception ProductException {
    string message;
    Using this solution, the client application gets blocked waiting forever.
    I am currently working with:
    - Forte' 3.0.G.2 plus WebEnterprise 1.0.B
    - JDK 1.1.5
    - Visibroker 3.1
    My question is: is it possible to raise an exception from the Forte' side
    that is
    compliant to the IDL mentioned above?
    Of course it should be caught from the Java side.
    Thank you in advance
    Giuseppe Sorce
    CSI Piemonte - C.so Unione Sovietica 216 - 10134 Torino - ITALY
    tel. +39-011-3168736
    fax +39-011-3168212
    e-mail [email protected]
    url http://www.csi.it
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>
    To unsubscribe, email '[email protected]' with
    'unsubscribe forte-users' as the body of the message.
    Searchable thread archive <URL:http://pinehurst.sageit.com/listarchive/>

  • WebEnterprise - HTML Editors and Java

    I'd like to know any opinions on HTML editors and their use with
    WebEnterprise. Have any of you done
    evaluations to determine the best editor to use with the Forte product? Also,
    do you have experience using
    a Java applet as the front-end to a Forte service object? In this instance,
    are you able to do so with Forte 30f2 and
    WebSDK?
    Thanks,
    Peggy Adrian
    Eli Lilly and Company

    Peggy,
    FrontPage 97 / 98 have both worked really well for us, however we
    discovered a slight hitch with 98 where the Editor would gobble up
    <?FORTE ..> tags inside the SELECT OPTION tag, but you can work around
    that one, apart from this FP98 is a great HTML editor. I also thought
    HotMetal was a good fit.These observations come out of evaluating about
    5-6 leading HTML editors.
    Some recommended steps in the process:
    1) Create a prototype by laying out all the HTML using an Editor. Figure
    out all the navigation within your web. More recent features seen in
    HTML editors such as JavaScript generation and DHTML / CSS support are
    really difficult to work out on your own, let the advanced Editors do as
    much dirty work for you as poss.
    2) Once the prototype is finalized, for all the pages requiring any
    dynamic content generation, figure out all the Tag Handlers you will
    need. Change the HTML Content by inserting the FORTE tags as required,
    code the corresponding Handlers.
    3) Figure out the relation between page requests and the security
    requirements for your pages, design the Session properties and data
    tracing across requests using the Session object.
    4) Do refer to all the Tech Notes on the Forte web site for known
    issues.
    As for the Java applets frontend, we have used Java - IIOP - Forte since
    early beta through every Forte release (3.0.X) and it works fine with
    WebEnterprise and release 30f2.
    - Sameer
    From: Peggy Lynn Adrian <[email protected]>
    Date: Wed, 07 Jan 1998 15:19:58 -0500
    Subject: WebEnterprise - HTML Editors and Java
    I'd like to know any opinions on HTML editors and their use with
    WebEnterprise. Have any of you done
    evaluations to determine the best editor to use with the Forte
    product? Also,
    do you have experience using
    a Java applet as the front-end to a Forte service object? In this
    instance,
    are you able to do so with Forte 30f2 and
    WebSDK?
    Thanks,
    Peggy Adrian
    Eli Lilly and Company

  • Forte compile error java source files must have a .java suffix

    Hello Guru's,
    I am using Forte for Java release 2.0 build 1160, and Java SDK 1.3.1.
    When I try to compile a project in Forte I get the following error :
    "fastjavac: java source files must have a .java suffix C:\Program"
    I have looked at the source files and they do hav .java suffix!
    If this is not the correct form can someone point me in the right direction. If this is a correct forum then help is very much appreciated.
    Cheers...Harki

    Hi,
    Try to compile like this:
    javac yourfile.java
    Hope this helps you.
    Cheers.....Dinesh

  • RE: (forte-users) RE: Forte 3 vs Java -- Productivity ( wasFutur e of F

    Bravo. I completely agree. Right now Forte is helping me solve my business
    requirements fast and that's all I care about. If Java will do that for me
    tomorrow and I will use it. Otherwise I will keep using whatever
    language(s)/tool(s) that helps me get the job done.
    Ka
    -----Original Message-----
    From: Genesio, Fabrizio [mailto:fabrizio.genesiodatasign.ch]
    Sent: Monday, February 14, 2000 5:22 AM
    To: kamranaminyahoo.com
    Subject: RE: (forte-users) RE: Forte 3 vs Java -- Productivity ( was
    Futur e of Forte )
    What an interesting debate....
    May I just add some considerations?
    - Successful Project capable to produce effective and maintainable
    system. That's in my opinion should be our goal as professional IT
    actors. Languages are just means to reach this goal. Therefore I would
    like to see IT professional considering all the aspects of software
    development, and not only the code and the languages.
    - About distributed features in Java systems... Sure, you can do
    in Java a lot of nice things, but, today, how much would it cost to
    develop in Java real mission-critical distributed application?. I am
    talking here about the IT "headaches" Fort&eacute; has been capable to solve
    during the past 5 years. Should I make examples? What about distributed
    events, what about distributed transactions, what about fail-over, what
    about load-balancing? Or, to move towards a more comprehensive view of
    software development (and maintenance), what about partitioning (or, to
    talk J2EE slang, assembly), what about deployment, what about monitoring
    and run-time management? Is there, available today, an alternative to
    Fort&eacute; that cover so many aspects of enterprise-class systems? I
    apologize, but I do not see one, or at least not yet. It not only a
    matter of languages...Nevertheless, I believe tomorrow is another day,
    Java will evolve as well as the environments for it (including Fort&eacute; for
    Java), and the all will be mature enough to really support distributed
    application.
    - This leads me to express a wish. I like the way one can turned
    down the Singleton issue. However this is a perfect example of the
    difference from Fort&eacute; to Java. On one side you have an abstraction, that
    hides complexity. On the other side you are (again) back at the
    "plumbing" level. Now I do not know what you think about in my opinion
    it is about time we move on from the "prehistorical age", making
    abstraction, start to worry more about the business requirements (and
    the users' needs). We should stop this sort of religious fight for the
    best language (the term "crusade" came to my mind), and using our energy
    to push for an easier integration, a effort-less plug-in between
    components. There is no perfect solutions, all languages have positive
    and negatives points. However all we really need is to learn to use each
    technologies at the right time and place, and having all pieces
    collaborating between each other. Pretty much like a house, where
    several material are used, each of them useful but none of them capable
    to replace all the others. Of course, it is clever to use sometimes only
    wood, and some other times only concrete. However, most of the time you
    need both, and you absolutely want them "collaborating" together to be
    able to live in your house. Well, that's what "in primis" we have to ask
    for to Fort&eacute;, and to SUN, in particular: easy integration and
    collaboration between TOOL and Java, a seamless cooperation between
    partitions and EJBs.
    I look forward to discuss all this at FORUM2000....
    Fabrizio Genesio
    Datasign AG f&uuml;r Informatik
    ch. d'Eysins 53a
    CH-1260 Nyon
    Switzerland
    Tel.: +41 22 361 04 04
    Fax: +41 22 361 01 10
    e-mail: fabrizio.genesiodatasign.ch
    <mailto:fabrizio.genesiodatasign.ch>
    URL: www.datasign.ch <http://www.datasign.ch>
    -----Original Message-----
    From: David Vydra [SMTP:dvydrajavamentor.com]
    Sent: Thursday, 10 February 2000 04:57
    To: Thomas Mercer-Hursh, Ph.D.
    Cc: kamranaminyahoo.com
    Subject: Re: (forte-users) RE: Forte 3 vs Java --
    Productivity ( was Future of Forte )
    At 03:06 PM 2/10/00 -0800, you wrote:
    >At 06:28 AM 2/10/2000 , David Vydra wrote:
    >How familiar are you with this product? Does it tell you
    something that
    >all of the FJEE tools are written in TOOL?
    So what? IBM's VisualAge for Java is written in Smalltalk.
    Look, if Forte management thought that they could fight the Java
    invasion
    they would tell their engineers to make TOOL much, much better.
    Instead
    they put most of the effort into SynerJ and sold the company to
    Sun. Smart
    move if you ask me.
    >As for what is or is not a 4GL, I think that there are so many
    >incomparabily different types of languages available these days
    and in so
    >many flavors, that any kind of division into generations is, at
    the very
    >best, extremely subjective. Certainly, TOOL isn't very much
    like some of
    >the classic procedural 4GLs, but personally I am very
    comfortable calling
    >it an OO4GL in comparison to the more common OO3GLs around,
    like Java.
    Agreed.
    =========================================================================
    >Thomas Mercer-Hursh, Ph.D email:
    thomascintegrity.com
    >Computing Integrity, Inc. sales:
    510-233-9329
    >550 Casey Drive - Cypress Point support:
    510-233-9327
    >Point Richmond, CA 94801-3751 fax:
    510-233-6950
    >
    >--
    >For the archives, go to: http://lists.xpedior.com/forte-users
    and use
    >the login: forte and the password: archive. To unsubscribe,
    send in a new
    >email the word: 'Unsubscribe' to:
    forte-users-requestlists.xpedior.com
    >
    >
    David Vydra
    dvydrajavamentor.com
    www.javamentor.com
    (877) 270 - 9003
    For the archives, go to: http://lists.xpedior.com/forte-users
    and use
    the login: forte and the password: archive. To unsubscribe, send
    in a new
    email the word: 'Unsubscribe' to:
    forte-users-requestlists.xpedior.com
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

    At 06:28 AM 2/10/2000 , David Vydra wrote:
    Also, it is a little unfair to compare a product in its third production
    release with a beta product. I agree that for certain projects Forte 3 is
    the right choice today. The issue for me is: will Sun continue the support
    of TOOL? How much of a 4GL is TOOL? Will TOOL become more 4GL in the
    future or will it be phased out?How familiar are you with this product? Does it tell you something that
    all of the FJEE tools are written in TOOL?
    As for what is or is not a 4GL, I think that there are so many
    incomparabily different types of languages available these days and in so
    many flavors, that any kind of division into generations is, at the very
    best, extremely subjective. Certainly, TOOL isn't very much like some of
    the classic procedural 4GLs, but personally I am very comfortable calling
    it an OO4GL in comparison to the more common OO3GLs around, like Java.
    =========================================================================
    Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
    Computing Integrity, Inc. sales: 510-233-9329
    550 Casey Drive - Cypress Point support: 510-233-9327
    Point Richmond, CA 94801-3751 fax: 510-233-6950

  • RE: (forte-users) RE: Forte 3 vs Java -- Productivity (wasFutur e of Fo

    Excellent point David, and right on the money in my opinion.
    -----Original Message-----
    From: David Vydra [mailto:dvydrajavamentor.com]
    Sent: Thursday, February 10, 2000 10:57 AM
    To: Thomas Mercer-Hursh, Ph.D.
    Cc: kamranaminyahoo.com
    Subject: Re: (forte-users) RE: Forte 3 vs Java -- Productivity ( was
    Future of Forte )
    At 03:06 PM 2/10/00 -0800, you wrote:
    At 06:28 AM 2/10/2000 , David Vydra wrote:
    How familiar are you with this product? Does it tell you something that
    all of the FJEE tools are written in TOOL?So what? IBM's VisualAge for Java is written in Smalltalk.
    Look, if Forte management thought that they could fight the Java invasion
    they would tell their engineers to make TOOL much, much better. Instead
    they put most of the effort into SynerJ and sold the company to Sun. Smart
    move if you ask me.
    As for what is or is not a 4GL, I think that there are so many
    incomparabily different types of languages available these days and in so
    many flavors, that any kind of division into generations is, at the very
    best, extremely subjective. Certainly, TOOL isn't very much like some of
    the classic procedural 4GLs, but personally I am very comfortable calling
    it an OO4GL in comparison to the more common OO3GLs around, like Java.Agreed.
    =========================================================================
    Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
    Computing Integrity, Inc. sales: 510-233-9329
    550 Casey Drive - Cypress Point support: 510-233-9327
    Point Richmond, CA 94801-3751 fax: 510-233-6950
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com
    David Vydra
    dvydrajavamentor.com
    www.javamentor.com
    (877) 270 - 9003
    For the archives, go to: http://lists.xpedior.com/forte-users and use
    the login: forte and the password: archive. To unsubscribe, send in a new
    email the word: 'Unsubscribe' to: forte-users-requestlists.xpedior.com

    At 06:28 AM 2/10/2000 , David Vydra wrote:
    Also, it is a little unfair to compare a product in its third production
    release with a beta product. I agree that for certain projects Forte 3 is
    the right choice today. The issue for me is: will Sun continue the support
    of TOOL? How much of a 4GL is TOOL? Will TOOL become more 4GL in the
    future or will it be phased out?How familiar are you with this product? Does it tell you something that
    all of the FJEE tools are written in TOOL?
    As for what is or is not a 4GL, I think that there are so many
    incomparabily different types of languages available these days and in so
    many flavors, that any kind of division into generations is, at the very
    best, extremely subjective. Certainly, TOOL isn't very much like some of
    the classic procedural 4GLs, but personally I am very comfortable calling
    it an OO4GL in comparison to the more common OO3GLs around, like Java.
    =========================================================================
    Thomas Mercer-Hursh, Ph.D email: thomascintegrity.com
    Computing Integrity, Inc. sales: 510-233-9329
    550 Casey Drive - Cypress Point support: 510-233-9327
    Point Richmond, CA 94801-3751 fax: 510-233-6950

  • Difference between RMI-IIOP and CORBA-IIOP

    Hello,
    What is the difference between RMI-IIOP and CORBA-IIOP?
    Thanks
    Larry

    Lawrence Manickam <[email protected]> writes:
    What is the difference between RMI-IIOP and CORBA-IIOP? RMI-IIOP is the protocol represented by the mapping of Java RMI
    artifacts to IDL, i.e. you start with Java and use the RMI programming
    model. CORBA / IIOP is really just the protocol used for IDL sourced
    objects, i.e. you start with IDL and use the CORBA programming model.
    andy

Maybe you are looking for

  • How to export the data from table to excel sheet

    hi experts i have some problem am trying to export the data fro table to Excel sheet  in the view controller i have created one button wit public void onActionCLEAR(com.sap.tc.webdynpro.progmodel.api.IWDCustomEvent wdEvent )     //@@begin onActionCLE

  • I am very dissatisfied with the replacement phone. How do I get help?

    We purchased a casio phone, there was issues with it, and I was sent to the warranty center. They were very courteous with sending a replacement phone..but the problem was, they replaced it with a phone that was in no way comparable to the one we bou

  • Premiere cs6 crashing with Quicktime

    I've recently started having problems with video disappearing in Premiere. Usually happens when I have other cs6 applications open, like after sending a sequence to Audition, or using AE dynamic link. The program monitor displays a black screen, the

  • Workflow_BOR object

    I am dealing with BOR object BUS2091 for SES entries workflow When ever i need some info like initialtors mail ,stauts etc i use the expression ZBUS2091.ZWFInitMail which are the attributes of Zbus2091 My doubt is whenever the worflow is triggered ho

  • How soon will DW CS5 Live View Webkit support CSS3?

    See above.  I just tried CSS3's text-shadow (although I don't believe it's totally CSS3) and while the shadow works well in Chrome, in Opera and in Safari, DW's Live View does not render the shadow, but rather an offset black copy of the text.  Webki