On 3/09/99 at 20:46 Tony Blomfield wrote:
>There seemws to be very little mileage in going this way.
>
>1. Is this really "Thin" technology is per my earlier goal statement.
Which was the reduction of network traffic, right? Then sure - it can be as thin (or
fat) as you want to make it.
>2. Financially the only winners in this race are Borland. From what I read
>there is absolutely NO financial incentive for me to go down this road.
If you bought CORBA, it would mean that you wouldn't have to spend the time to develop
a similar product yourself. Akin to the decision to buy Delphi, rather than to code
your own language in Assembler, or the decision to buy Interbase, rather than develop
your own database.
>Loosly put, anybody including the end user can buy this product at exactly
>the same price as me.
But the end user could buy Delphi and develop an application too, if they wanted.
Problem is that (especially with CORBA) an average Joe wouldn't have any clue how to
use it. There would be no point. It would be like me buying a soldering iron, thinking
I could use it to modify my Fridge to recieve Sky TV. Unfortunately end users *can* by
Delphi and start developing approximations of applications.
> It also looks like using this technology puts me in a
>competitive situation with Borland rather than a Technology
>supplier/Developer relationship. Please correct me if I am wrong.
CORBA is just a technology to make integration between software components painless.
There are bridges from CORBA to things like Lotus Notes and SAP, for example.
You could develop your own CORBA-like technology, in the same way that you could
develop your own relational database. Thing is though, it's a lot of work, it's
non-standard, it's not been tested by thousands of users, and it's probably not
something your client is interested in your developing (they just want to solve their
immediate business problem).
>3. There seems to be a hell of a learning curve
There *is* a learning curve, but I don't think it's insurmountable. Here's a complete
(Java) example. First we start with an IDL file describing our remote object. IDL is a
very simple declarative language, related to C++, but anybody can understand it:
module dugEg {
interface OrderProcessing {
string placeOrder(in long customerId, in long quantity, in float price);
};
};
In this example I have defined an interface (you can think of it as a class
definition) with a single method, called 'placeOrder'.
Now here's the *complete* source code to implement our business logic for the
OrderProcessing interface. It's all standard Java code - the only thing that gives it
away as being a CORBA object is that it descends from _OrderProcessingImplBase.
package dugEg;
public class OrderProcessingImpl extends dugEg._OrderProcessingImplBase {
public OrderProcessingImpl(java.lang.String name) {
super(name);
}
public java.lang.String placeOrder( int customerId, int quantity, float price ) {
System.out.println("Calculating stuff");
return "Order Placed!";
}
}
Now in order to make our object available to the world, we need an executable to put
it into. Here's the *entire* code needed to create that executable:
package dugEg;
import java.util.*;
public class MyCORBAServerClass {
public static void main(String[] args) {
try {
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init(args,System.getProperties());
// A
org.omg.CORBA.BOA boa = ((com.visigenic.vbroker.orb.ORB)orb).BOA_init();
// B
dugEg.OrderProcessing implObject = new
dugEg.OrderProcessingImpl("OrderProcessing"); // C
boa.obj_is_ready(implObject); // D
boa.impl_is_ready(); // E
}
catch (Exception e) {
e.printStackTrace();
}
}
}
Much of the code is standard Java baggage. Lines A, B, and E are needed once per
server executable. Lines C and D are needed for each CORBA object we wish to make
available to CORBA clients. Not a lot of code yet :-)
Finally, here's the *complete* code for a simple CORBA client:
public class MyCORBAClient {
public static void main(String[] args) {
org.omg.CORBA.ORB orb = org.omg.CORBA.ORB.init( args, null);
OrderProcessing op = OrderProcessingHelper.bind( orb, "OrderProcessing" );
System.out.println( op.placeOrder( 1234, 15, (float)15.50 ) );
}
}
... so that's it. A complete working CORBA server and client. Not bad really :-)
> deployment appears complex,
In order to deploy this application, you pick a random machine on your network and run
the server executable. Then pick another machine at random on your network and run the
client. The client finds the server, and it all works as advertised - none of your
DCOM configuration nightmares here!
>and the overall solution looks very complicated with lots of potential to go
>wrong.
No more potential than any other multi-tier solution, and rather more flexibility than
a web-based application. It's huge advantage over DCOM is that it *works*.
There's a lot more to Visibroker, of course, things like transaction handling and load
balancing. While they're important, you don't need to know everything about CORBA in
order to start being productive (as I hope my example has showed).
It's not a lot different in Delphi, now that it (nearly) has an idl2pas compiler.
Cheers,
Kerry S
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
