Scribd
Upload
71 views

Java and Delphi

This document discusses using Java and Delphi together. The author had issues finding documentation and examples for enterprise solutions in Java from a few years ago. Specifically, the author wanted to implement a transactional component-based backend but found Java technologies like RMI, Visibroker and EJB lacked documentation and examples for this use case. The author also notes it is easier to find documentation, examples and community support for Microsoft technologies compared to Java. At the end, the document discusses calling EJBs from Delphi and provides some potential approaches.

Uploaded by

namdam_redrum
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
71 views

Java and Delphi

This document discusses using Java and Delphi together. The author had issues finding documentation and examples for enterprise solutions in Java from a few years ago. Specifically, the author wanted to implement a transactional component-based backend but found Java technologies like RMI, Visibroker and EJB lacked documentation and examples for this use case. The author also notes it is easier to find documentation, examples and community support for Microsoft technologies compared to Java. At the end, the document discusses calling EJBs from Delphi and provides some potential approaches.

Uploaded by

namdam_redrum
Copyright
© © All Rights Reserved
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 4

It begins here

Java & Delphi Together


///////////////
I tried looking into Java about 2-3 years ago and here's some of my experiences that made me look away:
My interest is in designing backend solutions for enterprise systems. I have a decent amount of knowledge in things
like distributed components, transactions, statelessness, scalability issues, etc. When I started looking for these
things in Java, the one thing I noticed was the lack of definitive documentation and practical examples and bestpractices on solving real problems.
For example, I understand implementations such as RMI or Visibroker or EJB. What I don't understand is if I
wanted to implement a component-based transaction processing backend, what should I do. Well, guess what: there's
no examples, no documentation, no place to ask, no nothing on how to do it. You gotta investigate on your own.
Well I investigated and found out that RMI is non-transactional (so much for that technology), neither is Visibroker,
nor EJB. Although I was aware of things like OTS, Session Beans and Entity Beans for EJB (for transaction
support), these stuff were just specs whose implementations remained to be seen. Now, I gotta ask myself, I need
solutions today - not specs that I don't even know if my preferred vendor has plans to implement or not. Even so, if
my preferred vendor implements a spec, when will it be done and will it behave the way the spec says? Or do I have
to spend more time working with the vendor to understand idiosyncracies in their implementation?
Now think about this, in order to get to a solution like I mention above, you gotta be all on your own, invest on your
own, investigate on your own, etc. etc. When youre done with all this, time will have passed and opportunities may
have been missed.
On the other hand, if I did this stuff in the MS world, I would have less problems than what I described above. The
one greatest strengths in using MS solutions is you have a community and definitive implementation information.
You don't know how to implement something, just do a little research on the MSDN website, ask around, and you'll
quickly understand how people are doing it. Not only that, if you run into problems, the chances that somebody has
run into the same problem is very high and the chances that the problem is documented with known workarounds is
very high. Heck, you can even download fully-functional implementations of applications developed using MS
tools.
I don't know if this is still true of the Java world today, but if it is, then I don't see any point in going that direction.
Then again - it's only my opinion.
have fun

BinhLy
http://www.techvanguards.com

"pnichols"<[email protected]>wroteinmessage
news:39dea7f4$1_2@dnews...
>ThereisanotherrouteforasecondlanguageanditisJava.Javalet's
you
>continuetousethebest(Borlandtools),withafamiliarIDEandcode
>developmentstyle.PlusitismoreindemandthananyMStool,period!
//////////////
> What is the best way to call EJBs from Delphi?
Kyle Cordes:
Ideas:

1) Use an EJB server (or adaptor layer) that lets you call EJBs using SOAP, then a Delphi SOAP client (does one
exist at this time?) to call it.
2) A COM-EJB adapter (J-Integra)
3) WebLogic offers an ActiveX control that can call EJBs, I think
4) Java client code, called from a DLL using JNI, called from Delphi
5) The same thing, on the server, using some Delphi middleware to "remote it", such as ASTA.
there are many others; none of them are particularly "native", and will most likely not get you the full semantics that
are possible between Java clients and Java servers.
Take a look at J-Integra. There's even a Delphi sample there.

DanMiser
http://www.distribucon.com
"Dan Miser (TeamB)" wrote:
> Take a look at J-Integra. There's even a Delphi sample there.
Seeing as Dan didnt supply the link <g>:
http://www.linar.com/jintegra/doc/
Follow the Delphi to Java (late bound) link (I think).
/////////////////////////////
From Alessandro Federici:
Joe,
> For a more detailed idea of what we want to do, you can look
www.checksbynet.com
> for a similar type of web-based application. We really want the
over-hyped
> secured transactions as well, at least my boss does.
Why don't you guys go the same way checksbynet went? ASP/ActiveX? That is definitely, IMHO the best
alternative, except maybe for the ActiveX part.
Here are reasons you chould consider:
1) If you want to develop in Delphi (which is a good thing) and have a set of business objects that work on for web
AND eventually desktop
applications, use it to build a set of COM objects for the business tier
2) Use ASP, from which you have native and immediate access to them, without the need to build/rebuild and debug
ISAPI dlls that in addition are not exatly an example of how you want to develop (at least in the Delphi world in
which you interpret HTML tags with the THTMLProducer components)
3) Benefit of the possibility to scale largely without having to invest millions in powerful hardware UNTIL it is
really necessary and it pays by itself. Clustering is a nice solution to scale, much better financially speaking that
buying big boxes with a lot of horse power that may never get used or can kill your budget since the 1st day
4) You can benefit of a incredible set of components, libraries, examples and documentation to do the coolest thing
in this DHTML.

www.msdn.microsoft.com/workshop
4) You will be already on your way for the upcoming .net solution
Consider 2 facts also in judging my solution: Andersen is in the process of moving all their web stuff on Windows
2000 servers from the original Solaris they had. They have something like 1 hits a day (and they expect more in the
future) since they host a huge number of websites.
We are developing a web portal and we expect hits similar to that and we spent something like 2 months proving this
choice and debating about a Java or M$ solution. At the end the M$ solution won by far, and altought having a
budget of 4 millions gives us a pretty decent margin, the cost of the technologies required to do this in Java would
have killed us.
When you have something like the site you want to do, performance and scalability begin to have a HUGE
relevance and althought you have a LOT of money to spend, the Java way is not feasible and, at the end, even if it
were, it doesn't really offer that much more.
There are a large number of factors that can kill your project anyways, regardless of the direction you will go to.
Designing performant distributed systems is NOT as easy as they want you to belive. Limits in today's technology
make it really hard...
Now, for the individual questions:
> We will then group the data, create reports using our Delphi program that
is
> connected to the same database. We will then send the processed data back
to our
> clients. Our potential traffic can be up to about 1000 simultaneous
connections
> at a time.
Clustering. Consider a layer of Win2k Advanced servers and invest more in the database server first.
Once again, you don't need 25k or 50k machines to start. You can switch easily later.
> Granting that I can buy all the best third party tools for Delphi, what
are the
> best tools to help us do this job quicker? Are there any other
development
> tools that is more suited for this project? If there are, what do you
recommend?
For web UI, I always used Frontpage but this is just because that is not my real job. There are better tools around
(dreamweaver). Check out www.aspfree.com , http://www.treegen.com/ , www.componentsource.com for ASP
components
> What do we need for the web-server, both hardware and software.
Invest in bandwidth first. T1 or T3 rather than the server. Until you get big hits, it's money wasted.
Save that money for something more useful at the beginning, like a good database server (hardware speaking). What
is really gonna kill you is how you develop server side objects (doesn't matter which technology, there is a precise
design you have to stick to in order to make it scalable) and a poorly designed/tested database rather than the web
server.
> We currently have D5 Enterprise, MS-SQL (2000 is coming), InterBase and
> Advantage Database Server.
Good for the first 2, unfortunately forget the other. IB is too slow with lots of data, doesn't have an OLE/DB
provider and Advantage is the solution that can kill you. Go with the industry standards. Better support and bigger
teams behind them.

> We also have Web-Hub


No comment.
> Any insights are welcome, perhaps a consultant's contract should be in
order.
> Thanks for your time.
You are welcome. Feel free to contact me directly via email if you need more info (you do, you do) :-)
//////////////////////////
10/28/00 from deja.com
Lu,
You have to translate the JNI C++ headers to Delphi (or get a copy of the headers already translated). Rudy Velthius
from the JEDI team provided me with a copy of these translations and they worked excellent. I was able to call
functions in my Delphi DLL from Java. It was actually pretty easy. Below is the text of an e-mail reply that I made
to Rudy.
Rudy,
Thanks. The JNI header class was very helpful and allowed me to accomplish my task (without having to use C/C+
+). In order to get started, I referenced the following URL which provide a "C" demo in how to use JNI:
http://java.sun.com/docs/books/tutorial/native1.1/stepbystep/index.html.
The only problem that I encountered was working with java string parameters. The JNIWrapper module contained
some conversion routines that are supposed to handle this, but I could not use them successfully. I ended up
copying / modifying those routines to get them to work for my purposes. Those modified routines are at the
beginning of the attached project.
The attached ZIP file contains:
Filename Description
-------- ----------ConvertCSVtoExcel.java Java source file
ConvertCSVtoExcel.class Java class file
ConvertCSVtoExcel.h C/C++ header file generated by "javah" command Onestop.DPR Delphi Project File
Test.csv Test data file
The basic steps I followed were:
1. Generate Java class. (javac ConvertCSVtoExcel.java)
2. Generate C/C++ header file. (javah -jni ConvertCSVtoExcel)
3. Take C/C++ header file and translate into Delphi function/procedure calls.
4. Compile Delphi code.
5. Run java application. (java ConvertCSVtoExcel)
Once I figured out the convention that "javah" was using to create the header files, I no longer had to generate the
C/C++ header file.
TKJ
PS. I also found this link to be helpful:
http://java.sun.com/docs/books/tutorial/native1.1/implementing/string.html

You might also like