What is the main difference between CORBA and Java RMI?
403995
* CORBA isn't tied to one language; Java RMI is \n  tied to Java.  The down side to this for CORBA, is \n  that developers also have to learn to write \n  interfaces in yet another language, IDL.\n\n* CORBA doesn't allow executable code to be sent \n  to the remote system; RMI does.\n\n* CORBA allows remote method invocations as well \n  as the exchange of primitive data types and \n  structures.  RMI allows full objects to be \n  passed and returned.\n\nSee the references below.
985607
from sun.com\n\nif you looking for any specific third party jvm , look for from their specific sites.\n\nsay,ibm.com , bea.com .
196732
Same and JeffAv above.  SCSI are faster than IDE but you need a SCSI card reader. Nice feature about SCSI is that you can daisy chain (put multiple) hard drives all on the same card.
292447
Perl would be my preference.  There are interpereters available for all major platforms (UNIX, Linux, Windows, OSX, etc.), so your scripts will be fairly portable depending on the system calls you use.\n\nThere are many libraries (Perl Modules) available that allow your scripts to do things like connect to databases, access web servers, access mail servers, and more.
549462
I can't address the issue of the problems it causes in\na Service Oriented Architecture, but an RPC is a remote\nprocedure call.\n\nThe idea is that your program can make what *appears* to\nbe a typical function call, but what will happen "under\nthe covers" is:\n\n- the function arguments will be "marshalled" in some\nway in preparation for network transmission.  This may\nbe as simple as re-ordering the bytes of the arguments\nto account for machine "endianness" or it might involve\nserializing objects.\n- a server will be contacted on the remote machine which\nwill accept and unpack the arguments and then call the\nfunction on the remote machine to do the work.\n- whatever return value is generated will be packaged\nup and transmitted back to the calling machine, which\nwill unpack the value and allow the original "call" to\nretrieve the value.\n\nIt allows the source to make remote functions calls\nwhich appear to be local.
556103
J2EE is helpful in developing multitire enterprise application. you can go through this link also
165890
Mainframe COBOL is still VERY widely used in large business environments.\n\nDue to the huge existing COBOL code base in legacy applications, COBOL will  have a significant presence in mainframe shops for at least the next decade or two.\n\nI suppose another way to ask this question would be "will more new coding be done in J2EE or in COBOL?".  \n\nI work for a large North American bank and at my company the majority of new code development is still in COBOL.\n\nHope this helps.
631803
???\n\nIn the J2EE application model, the components support different kinds of tehcnicalities..\n\nIn the Entreprise Java Beans model, there are components that deal with transaction, security, and etc. They are already handled and have functions for you to play with to make it securer.\n\nEntreprise Java Beans is a big step but once you know it, you will program with ease, since everything (almost) is given
1158479
Have you tried using Enicna or the IBM MQ Series as Middleware components ? You could even use WebMethods for this purpose ..
1120250
Depends on the Operating System. I will mention the two most popular.\n\n In Windoze, create a thread\n In *nix call fork()\n\nThey are all different in some way and have their own set of 'gotchas' be prepared to do a lot of RTFM
745670
stateful beans are full of state. Stateless ones have less of it :-)\n"client call" is a single remote method invocation.\nStateful beans are more similar to "normal" local class instances. If you call a function on it, that sets a value for some instance variable, and then call another function, it'll see the value that the previous function set. If the bean is stateless, then calling the first function will generally have no effect on what the second one sees.\nThe states between different instances is, of course, different. Just like it is the case with regular java class instances.\n\nstateful beans is generally a bad programming practice. It wasn't even a term until recently, when a gush of bad programmers came in, and started "engineering" around it - "stateless" was a term, because it denotes a good engineering concept, and "stateful" is, pretty much, just a lack of such. \nWhen your server is stateless, you can be sure, that the result you get from calling a function depends only on the parameters you pass in. With a stateful "design", there is no such guarantee, you have to know the entire history of the server session to know what to expect from a function call.
1184418
As stated, all of these technologies would be usable by you for free.  The java core technologies are free to use (as are a number of middle-tier / application servers you may need) and since you wouln't be redistributing any mysql components (or embedding it in anyway) I believe it would be cost-free for you to use as well.  \n\nAs for servers I currently use both 1&1 and Rackspace (though not cheap) with more than adequate results.
556858
There is not much difference, both are writeable CDs. They say that +R is more compatible with most of the computers existing today.
680411
Absolutely no problem.\nI'm using an Oracle 8i both Client and Server Application in the place I'm working. No problem at all ...
404627
no im sorry but theres not. while its true that the two are the same basic thing, the interface is completely different. so its possible maybe if your a computer technician to jerry rig something...but if so you would have done so already instead of asking us.sorry.
525921
The Java Runtime Environment (JRE) consists of the Java Virtual Machine (JVM) core API libraries, and other supporting files. \nThe JRE is the smallest set of executables and files that constitute the standard Java platform.
402085
Oracle9iAS Containers for J2EE - Release 2Date: 06/27/02\n\nHow-To: Message-Driven BeansAfter completing this how-to you should be able to: \nUnderstand how Message-Driven Beans (MDBs) work and why they're useful. \nBuild, deploy and run the sample application code. \nSoftware RequirementsOracle9iAS Containers for J2EE (9.0.3) Developer Preview is installed, available from OTN \nJakarta Ant 1.4, to build the application example, available here \nSun's JDK 1.3_01 or above, available here \nIntroductionThe EJB 2.0 specification provides for a new EJB component, the Message-Driven Bean. MDBs are not accessed directly, as are other EJBs, but instead listen on a message queue and respond to the arrival of appropriate messages. MDBs provide a simple and powerful paradigm for implementing asynchronous transactional applications in Java. You'll notice from the code that MDBs are simpler than Entity and Session Beans with respect to the fact that since they are not accessed directly, they do not require local, remote, or home interfaces. They only need a bean implementation class.\n\nIn the example below, you will build, deploy, and test a simple J2EE application to OC4J. The application comprises an MDB and a small web-application that enables you to insert messages onto a queue via your web browser. The MDB is only a single Java class. When the MDB receives messages off of the queue, it will report its findings to the command-line via standard output.\n\n\n\nPrerequisites for running the exampleTo run the sample application you must have: \nAdd the following JMS topic and topic connection factory in the jms.xml file in the $OC4J_HOME/config directory: \n<topic name="Demo Topic" location="jms/theTopic">\n<description>A dummy topic</description>\n\n</topic>\n\n<topic-connection-factory name="Demo Topic Connection Factory" location="jms/theTopicConnectionFactory">\n<description>A dummy topic connection factory</description>\n</topic-connection-factory>\nAlternatively, you may use the jms.xml file provided in the example files discussed below.\n\nUnpack example filesDownload the examples files (messagelogger.zip) and unzip it into a directory of your choice <example_home>.  The zip file contains the following files and directories:\n\nsrc/ - contains all Java source code for the example. \nejb/ \nmdb/ \nMessageLogger.java - Message-Driven Bean. \nweb/ \nlogmessageform.htm - HTML file. \nlogmessage.jsp - JSP that puts message on the queue. \netc/ \napplication.xml - Standard J2EE Application descriptor file. \nejb-jar.xml - Standard EJBs descriptor file. \nweb.xml - Standard Web Application description file. \norion-ejb-jar.xml - OC4J-specific EJB decriptor file. (Holds the MDB <-> Topic mapping. See below.) \njms.xml - Example for modifying OC4J config file. \ndoc/ \nreadme.htm- This document. \nbuild.xml - An Ant build file. \nThe orion-ejb-jar.xml file holds the Topic and TopicConnection mappings that tell the container how to associate the MDB with a message service. Here is part of the configuration presented in orion-ejb-jar.xml:\n\n<enterprise-beans><message-driven-deployment name="MessageLogger" \ndestination-location="jms/theTopic" \nconnection-factory-location="jms/theTopicConnectionFactory"></message-driven-deployment></enterprise-beans>\n\nCompiling and deploying the applicationUsing Ant and admin.jarFrom the root of the example directory [the directory where the build.xml file is located] execute the following command:  ant \n\n\nYou should now have a newly created messagelogger.ear file in your <example_home>&#92;lib directory. \n\n\nDeploy this J2EE application to a running instance of OC4J R2 by executing the following command from the <example_home>directory: \nant deploy-usingadmin.jar \n\nTest the application by accessing the web app at the URL