Databases & beans

Databases & beans

Q: Anybody does know a freeware JDBC driver for a dsn-less connection to MS SQLServer?
Would even consider a "cheapware" version.
Answer: Go to http://industry.java.sun.com/products/jdbc/drivers and search for Microsoft SQL
Server. Any Type4 (i.e. pure Java) driver should work without a DSN.
The only free one I'm aware of is at http://www.freetds.org - but it is rather limited in what it can
do. You'd need to try it out to see whether it fits your requirements.
--
Stefan
P.S. DSN - Data Source Name
Q: I just want to know which programs and virtual machines you have to have to make and
run enterprise java beans...
Answer: To compile and run Enterprise JavaBeans, you need a couple of things.
First, you need the J2EE SDK. This kit includes APIs full of packages which are considered
extensions to the standard Java language APIs, as well as other tools, which come with the
J2SE SDK, which you should already have. Install the SDK and make sure its jar file is in your
development environment's classpath.
Second, you need a container, which in this case you can also refer to as an application server,
though technically a container is just one part of the server. The container acts as a liaison
between the client object and the Enterprise JavaBean. When you talk to an Enterprise
file:///C|/330_new/330_new/database_beans.htm (1 of 5) [2003-07-22 22:07:48]
Databases & beans
JavaBean, you actually talk to a proxy (a substitute), and the proxy, which knows how to do
networking stuff, talks to the container, which in turn talks to the actual implementation object
which is what you think of when you think of an Enterprise JavaBean.
The J2EE SDK, fortunately, comes with a server/container, as well as a GUI-based tool which
allows you to deploy your Enterprise JavaBeans in the server. See java.sun.com/j2ee.
Third, you need a lot of patience. The learning curve is rather steep unless you have a lot of
experience doing network
programming. Enterprise JavaBeans are designed to abstract out networking and storage
logic, which ends up being very helpful, but is confusing at first, because so much happens
behind the scenes that is not explicitly controlled by your code. For example, when you deal
with a single Enterprise JavaBean, at least five different objects are actually being instantiated!
But it's great once you get past the initial learning stage, which can last a while. There are lots
of good books on EJB, but I found Ed Roman's "Mastering Enterprise JavaBeans" to be a great
primer.
--
Erik
Q: I'm having a hard time figuring out what are the differences between Enterprise Java
Beans and Java Beans.
Is there a definitive difference between the two?
Answer: Definitely. JavaBeans are really nothing more than classes that have no-args
constructors and follow certain naming conventions (and/or provide a BeanInfo class) to
identify properties, methods, and events. JavaBeans were designed for plugging into GUI
design tools. Technically speaking, lots of things are JavaBeans... though whether they are
intended to be used that way is another matter altogether.
Enterprise JavaBeans are not really used as JavaBeans at all. They run on a different server,
in a special EJB container that provides a bunch of restrictions on their class hierarchy, their
fields and object relationships (particularly if CMP is used), the Java language features that can
be used if you write them, etc.
They are, of course, far from a GUI design thing.
They are also, IMHO, far from a good idea and I'd avoid them if at all
possible.

--> to be continued tomorrow (end of Part 1)
Part 2.
> Please explain why to avoid them in more depth…
Basically, the problem is that Sun has started reflection "activity". I use that term to describe the
unnecessary use of reflection when a good solution with static typing would be preferable.
Examples: Standard RMI has always used interfaces to act as common types between client
file:///C|/330_new/330_new/database_beans.htm (2 of 5) [2003-07-22 22:07:48]
Databases & beans
and server. EJBs abandon this, and just say "well, define all the same methods" with no static
checking that you've done so. You then have to write a bunch of "ejbCreate" methods, with
exactly the same signature as "create" methods, but needlessly renamed. (Well, you kinda
would have to name them in order to stuff them into a class where they don't belong, which is
exactly what EJB does.) Then EJBs examine my object's fields (which are supposed to be
private), and sometimes the whole thing stops working because I have a field of a type that the
container doesn't like.
The result is something that shares basic syntax with Java, but which is really a different beast
altogether, with no well-organized bit of documentation on use (because everything is dynamic
through reflection instead of working with well-defined methods in well-defined classes for
which documentation can be written), and strange and unreasonable constraints on coding.
That said, EJB containers are the only environments that provide anything like CMP, for
example. I'm working on a better-designed replacement for EJBs' CMP that doesn't rely quite
so heavily on reflection, but I'm unaware of anything widely available.
--
C. Smith
--> to be continued tomorrow (end of Part 2)
Part 3.
It was a poor naming decision on Sun's part. There is no similarity between Java Beans and
Enterprise Java Beans except for their name.
All they managed to do was cause confusion just because they liked the cutesy name.
The confusion is reduced when you realize that "Bean" in Java is the cutesy name for that
software engineering term, aka buzz word "component", that is something intended to be reusable
as is without change, the software equivalent of the hardware engineers chip.
One note: a JavaBean is intended for use in some type of building tool, but a bean or a set of
beans may not have anything to do with the GUI of the resulting application. Most often the
intent is that the bean is _configurable_ using some GUI. The typical examples of nongraphical
beans are Database access JavaBeans which result in nothing in a GUI, but may
communicate with other Beans which are part of the application GUI.
I was annoyed a few months back when I attended a Sun training, which included coffee bean
looking icons, plus various other curious bits of graphics which to me just added clutter. I still
don't know what some of the silly figures where supposed to be :-). Some simple UML (some
boxes and arrows) would have been much clearer.
--
Comments by Tom Almy, Paul Hill
Q: I want to use MS Access databases in my java app. Where do I start and where can I get
the drivers, I am fluent in SQL with Active Server Page experience, so that isn’t a program, its
just setting up the DB connection in Java.
Answer:
file:///C|/330_new/330_new/database_beans.htm (3 of 5) [2003-07-22 22:07:48]
Databases & beans
1. From the ODBC control panel, define a system data source name for the specific MS Access
database you want to use. Make sure it's a system DSN, not a user DSN. Assume you name it
"foo".
2. In your Java application, load the JDBC driver:
try {
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
}
catch (ClassNotFoundException e) {
// Shouldn't happen - it comes with the JRE
}
3. Create the DB connection using the name of your system DSN from step 1:
Connection con = DriverManager.getConnection("jdbc:odbc:foo");
That's it. From there on, the connection behaves like a JDBC connection to any other kind of
database. See the tutorial for details.
Remember to close the connection - it's best to enclose step 3 in a try/finally block:
Connection con = null;
try {
con = DriverManager.getConnection("jdbc:odbc:foo");
// Do your stuff
}
finally {
if (con != null)
con.close();
}
--
Phil Hanna
Author of JSP: The Complete Reference
http://www.philhanna.com
Q: I used JDBC driver to connect Microsoft SQL server Database. It is no problem besides
display Chinese word...
Answer: You can try
public String fromDB(String in) {
try{
return new String(in.getBytes ("Iso8859-1"),"Big5");
}
catch(Exception e){
return "";
}
}
This is the problem at the encoding of string.

No comments: