Skip to main content

EJB Connectivity

13 replies [Last post]
frdbr
Offline
Joined: 2004-08-03

Hi,

I (and some others as I have discovered) have quite some difficulty connecting a standalone (SWING) client to an EJB backend.

It turns out that this connection to an EJB is very much vendor dependent and often ill-documented. It looks like the main focus of EJB is to develop a web client.

I was wondering if this is the correct forum to ask for help on this?

An interesting discussion on this topic you can see at:
http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-3121.html

I had a quick browse through your website and from this I get the impression that typical backends for JDNC is JDBC and HTTP, but not EJB/RMI/CORBA. Is this correct?
If not, how is the connection to EJB solved? Or is this not within the scope of this project?

Thanks in advance,
Franck

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
luke_f
Offline
Joined: 2005-07-27

I think EJB connectivity is an important aspect. Although, I can sympathise in regards to setting priority around this issue. It does seem that for most applications a direct JDBC connection is more likely.

I guess if you are looking for real world setups, the reason I raised the issue in the myeclipse forum (see first post) was laregly due to the fact that our organisation has generally developed/deployed applications around the principle that the DB logic should be decoupled from the application. Of course this principle is well documented nor is it all that new. Im not being facetious here so please dont get the wrong impression :)

The reasons we use for this approach, apart from good design in my opinion, are due to the fact that as a global organisation with distinctly different networks / sites with different needs, it is often handy to be able to have mutiple end-user deployment options at the ready. Typically, we has used COM+ technologies in the past (for the backend), we now use EJB, and it is handy to be able to re-use the logic contained in said components for both web and rich clients, eliminating the amount of code to be rewritten.

It also seems that EJB->client connectivity is a fairly vendor specific thing. So I dont know how you could exactly provide a generic out of the box solution to EJB connectivity. I think there is a discussion on java.net at the moment which in part addresses this.

Having said this, being able to bind both applications to the same code base easily would be great. I will look into the loader concepts Rich mentioned.

Oh well .. thats my 2 cents.

-luke

frdbr
Offline
Joined: 2004-08-03

In my company, we are replacing a SilverStream (Novell Extend) based application (which is basically a 2-tier architecture, sometimes 3-tier) with a J2EE based architecture in which the business logic is offered in a EJB session layer.

We are now in the decision process whether to choose SWING based standalone front-ends or web-based front-ends. In this discussion, independence of the vendor is a main requirement (since we do not want to have the SilverStream debacle all over again, i.e. rewriting the entire application). It turns out that with a SWING based standalone front-end it is not possible to prevent vendor lock-in. It will probably prove impossible to convince my management to opt for the standalone solution just for this reason.

I don't believe it should be the scope of this project to solve the EJB-connectivity issue. The root cause of the problem lies in the J2EE standards themselves (they do not address the standalone client connection to a J2EE layer properly). There the problem should be solved. I also don't see if the problem is really solvable.

With respect to the prioritization (probably not good English :)) for the JDNC project another way to get a feeling of which technologies are used is to analyse the job market. Here in Holland I can see that 90% of the JAVA programming jobs require J2EE knowledge. Hardly ever do they ask for JDBC knowledge directly. This is maybe an indication that J2EE based applications is getting the standard way ... (but Holland is a small country :)). On the other hand, you might think that all these jobs are related to web-based GUIs ...

By the way, luke, could you provide us a link to java.net discussion you referred to? Thanks.

Cheers,
Franck

Patrick Wright

> In my company, we are replacing a SilverStream (Novell Extend) based
> application (which is basically a 2-tier architecture, sometimes 3-tier)
> with a J2EE based architecture in which the business logic is offered in a
> EJB session layer.
>
> We are now in the decision process whether to choose SWING based
> standalone front-ends or web-based front-ends. In this discussion,
> independence of the vendor is a main requirement (since we do not want to
> have the SilverStream debacle all over again, i.e. rewriting the entire
> application). It turns out that with a SWING based standalone front-end it
> is not possible to prevent vendor lock-in. It will probably prove
> impossible to convince my management to opt for the standalone solution
> just for this reason.

Franck

I have been following this thread on Swing/EJB connectivity...wondering if
you (or perhaps someone else) could list high-level goals for this
feature-set? The only one that is coming across clearly is
'(EJB-container) vendor independence'...I think a bulleted list of what
you are trying to achieve would be useful (for me, at least) to understand
what, at least conceptually, you are trying to achieve.

Just to state from another point of view, we have more-or-less RDBMS
independence because the RDBMS vendors support most of a common standard
(SQL), and because SQL is metadata-based, and there is a common standard
for reading that metadata. What would be the equivalent in EJB, what
features would it have?

Thanks
Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

frdbr
Offline
Joined: 2004-08-03

Hi Patrick,

Before I try to give a list of high-level goals, let me try to illustrate how a client should access a session EJB:

package j2ee;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.rmi.PortableRemoteObject;

public class J2eeClient
{
public void addBook(String aBook, String aUserName) throws Exception
{
Context context;
Object jndiObj;
CartHome cartHome;
Cart cart;
Object result;

// create JNDI context
context = new InitialContext();

// lookup the bean home and 'cast' it to the correct type
jndiObj = context.lookup("java:comp/env/ejb/cart");
cartHome = (CartHome) PortableRemoteObject.narrow(jndiObj, CartHome.class);

// create the stateless session bean
cart = cartHome.create();

// call the desired business logic
result = cart.addBook(aBook, aUserName);

// do something with the result if necessary
System.out.println("result=" + result);
}
}

The context is the link into the JNDI-tree of the EJB-container hosting the EJBs. A JNDI-tree is able to lookup a (remote) object (reference) based on some sort of URL. The object that is returned, can then be ‘casted’ to the actual desired server interface. The object that is obtained is called the ‘bean's home’, which has the behaviour of a factory. By calling the ‘create()’ method on the bean's the actual (stateless) session bean is obtained.

The stateless session bean is then used to actually invoke the real business logic.

The whole advantage (imho) is the statically typed way of working. There is no such thing as ‘metadata’, but the pure raw power of the Java language to work with. That's why I prefer it over JDBC, XML-based protocols, or HTTP-based communication. This is all dynamically typed, and many things can go wrong, apart from the extra work needed to extract the desired information and convert it into workable client objects (probably java beans).

The code above works perfectly for a web client (running in the same container/cluster as the EJBs). This has to do with the instantiation of the Context interface. As you can see, no arguments are given to the constructor of InitialContext. Somehow the container knows exactly how to construct the correct InitialContext and bind it to the JNDI tree of the container.

For a standalone client the code above does not work. The InitialContext() needs to be initialized with the correct parameters (in the form of a HashMap), among which a initial factory and a URL. Mainly the initial factory is a problem, since it turns out that this is a vendor specific one. Another problem is the actual invocation of the beans’ methods, since you actually need stubs to do the communication. This is also a tricky part to accomplish. Normally beans communicate through RMI, so one would need to include the stubs of the bean in a jar file or dynamically download them from a web server. The second item I have never got to work. The first item I got to work for BEA, but this is quite an achievement, namely running a BEA specific compiler on the source tree of the beans. And then there is the hard task to get it into an ANT build file ...

As you can see, this is not straight forward. I personally have spent many evening hours to get it working :(. Actually I really hope I am doing something wrong, and that someone can tell me what the magic trick is ... :)

So, if I could pose some high level goals, they would be:
* Bean lookup should be vendor independent. This means that the code that needs to be written would run against any vendor’s implementation of the J2EE container. Preferably without the inclusion of any necessary jar-files, Since the standard JRE already includes implementations for JNDI contexts.
* Bean stubs should be downloaded automatically to the ‘codebase’.

If this is technically not feasible, which I believe so, other goals could be:
* Example code, programmer guides, and maybe some util library to support standalone client developers to connect to a J2EE EJB backend.

What do you think about this?

Cheers,
Franck

Patrick Wright

Franck

Thanks for the review of connecting from client to server, EJB-style. I
can't say much about the J2EE spec-related questions. That is, not sure if
this is lack of specification detail that prevents real portability in
initializing the context, or that it is just impossible to do, or
impractical, or what.

I responded mainly to understand what the thread is about. That is, what
is there that anyone at Sun, on the JDNC project, could do, to facilitate
working with EJB in a rich client?

>From the two goals you listed, this seems like a problem to address to the
J2EE specification team at Sun, not the JDNC group. Because this may
really just be a weakness in the specification.

It seems what JDNC might be able to offer is, if you (the programmer) took
care of establishing the connection, you could then bind value objects (as
Beans) returned from the EJB server to a form, or a table, for display;
and you could have a hook to capture updates entered by the user, so that
you could issue the appropriate calls back to the server, using the
modified value objects.

I used to use PowerBuilder many years ago, and (in case you didn't use
it), they had a tabular widget/control called the DataWindow, which was
their bread and butter. It could be used as a backend to a table or a
form, supported database-independent SQL, dynamic filtering, sorting, etc.
It was about the only really good thing in PB (haha).

Point is, when you called the save() method on a DataWindow, normally this
would cause SQL to be generated for the current database, for each new,
modified, or deleted row. And you could trap that call, build your own
SQL, or do whatever you wanted, and bypass the normal mechanism.

My suggestion is, this is the best to hope for from JDNC:
1) easy binding for JavaBean/value objects to tables and forms returned
from EJB servers

2) some way to request changes input by the user be saved, and then trap
that save call for your own purposes

I guess that if you were clever, you might be able to automate some of
this code (e.g. retrieve a single value object using findByPrimaryKey(),
save a single object using a remote save(bean) call).

The downside of all of this is that networked access for a distributed
system using a rich client as a node will have hard to tune performance
characteristics over SQL, and so it may all come to naught.

My 0.02!
Patrick

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

frdbr
Offline
Joined: 2004-08-03

Ah my dearly beloved PowerBuilder!

I have worked with it for many years before I started with Java. There was not much I could not program with PB ... :) You must have been reffering to the SqlPreview event. I used it to call stored procedures instead of plain SQL.

At my previous company we used PowerBuilder to prototype the GUI. We then used JAVA to implement it. This really worked out very well. It was merely born out of necessity, since the prototyper only new PB and no JAVA, but was very experienced in usability. This way we could combine the strengths of two worlds.

At my current company they use SilverStream, which I believe is from the same authors of PowerBuilder. The SilverStream View has a lot in common with the PB DataWindow, although it has much less functionality. It was like a deja-vu.

However, I learned the true value of a 'real' language JAVA. Actually the OO-capabilities of Java give in the end much more power to the application developer, resulting in the end, if well applied, in more robust, better performing and scaling applications. So for any serious enterprise application I would not recommend 4GL languages anymore (like Visual Basic for example). 4GL languages tend themselves better for RAD. You have quicker a GUI 'up and running' to 90% of its functionality. But, of course, the last 10% costs half of the time .... And in the end you have a 'spaggethi' plate all over the place. At least this is my personal experience.

You can also see from the latest trends however that the industry is attempting to make J2EE (or Swing for that part) easier to develop. I expect PB/VB-alike applications plummet soon. Actually, if I understand the scope from JDNC correctly, this is one of things JDNC tries to achieve, isn't it?

But back to the topic :). I agree with your point that my post has more to do with a J2EE spec issue than that it should be addressed in JDNC (as I mentioned in a previous post). I do think that I am going to take this discussion there. If I have learned more I'll keep you posted.

As you can see from this post I am really searching for a solution to EJB connectivity. Personally I like standalone clients (call them rich if you like, or thick, I don't care), since in the end I believe that (heavy) end users can truely benefit from the added value of a dedicated standalone client, like Amy Fowler stated in her article on JDJ.

Besides that, and I really do not want to offend you guys/ladies, I don't think it is a good idea to issue SQL from the client tier. I am a strong believer that an EJB session layer is the ideal bridge between client and backend. This has all to do with issues like performance, seperation of concerns, scalability, extendibility, integratability, etcetera. But this is another discussion ... and let's not start a war here :).

So, if you ask me, it is really imperative to solve the issue of EJB connectivity, since only then you can leverage all the best from SWING, EJB, persistence frameworks and RDBMS.

I do presume though that the components that come out of JDNC can be leveraged to any kind of backend and not only SQL. That would really be a pity. You really should not have this tight lock-in to a protocol. It would be really limiting your potential.

If you follow the PB Datawindow approach where you can trap the call to the DB, in order to replace it with a custom backend call, that would be fine, although there are many other solutions to solve this problem. For example to send the entire list and have the middle tier sort out the updates needed.

Don't bother too much about performance yet. Remote connections to objects can be cached just as easy as database connections. I don't believe that an SQL call is more or less performant as a remote method call. Of course, there is the overhead of a middle tier, but that should not be a bottle neck if developed with skill.

Cheers,
Franck

augusto
Offline
Joined: 2003-06-11

Hi,
>
> I (and some others as I have discovered) have quite
> some difficulty connecting a standalone (SWING)
> client to an EJB backend.
>
> It turns out that this connection to an EJB is very
> much vendor dependent and often ill-documented. It
> looks like the main focus of EJB is to develop a web
> client.
>
> I was wondering if this is the correct forum to ask
> for help on this?
>
> I had a quick browse through your website and from
> this I get the impression that typical backends for
> JDNC is JDBC and HTTP, but not EJB/RMI/CORBA. Is this
> correct?
> If not, how is the connection to EJB solved? Or is
> this not within the scope of this project?

What we ended up doing is implementing a very similar thing to the "bright side framework" linked in your thread @ myeclipse.com

http://www.bs-factory.org/components/remoting.shtml

We have interfaces that describe what can be called on the server, and the client calls an instance of this interface with a pluggable implementation. Our only implementation is serialized objectes via HTTP, which are just servlets that expose the server objects that do the real work. We did this a while back before there was such a thing as EJBs, but the concept is similar.

What I like about this approach is that when we decide to use a higher performance protocol for cases where there are no firewalls, we just go ahead and implement another adapter, and we don't have to change the code on the client.

Amy Fowler

jdnc-interest@javadesktop.org wrote:

[snip]
>
> An interesting discussion on this topic you can see at:
> http://www.myeclipseide.com/PNphpBB2+file-viewtopic-t-3121.html
>
> I had a quick browse through your website and from this I get the impression that typical
backends for JDNC is JDBC and HTTP, but not EJB/RMI/CORBA. Is this correct?
> If not, how is the connection to EJB solved? Or is this not within the scope of this project?
>

We've opted to focus initially on database connectivity because
that is such a predominent requirement, however that doesn't
discount the need to eventually provide support for connecting to
more sophisticated backends such as EJB or CORBA. In many ways
we hope you as a community will help drive our priorities with
feedback (& contributions!) when such issues are raised.

Is anyone else out there looking for EJB support?

How about WebService connectivity?

Concrete application scenarios always help drive these needs home.

Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

fnimphiu
Offline
Joined: 2003-06-17

Amy,

I think we cannot ignore Webservices. All connectivity except JDBC are integration points to enterprise systems. Same for JMS integration.

Frank

Amy Fowler

jdnc-interest@javadesktop.org wrote:

> Amy,
>
> I think we cannot ignore Webservices. All connectivity except JDBC are integration points to enterprise systems. Same for JMS integration.
>
> Frank

Just to be clear, I wasn't suggesting we ignore WebServices, as its
an obvious trend for many applications. My intention was to stimulate
dialog with the community on the specific problems they are working to
solve at the moment so we can understand what's most important to
developers.

Aim

---------------------------------------------------------------------
To unsubscribe, e-mail: jdnc-unsubscribe@jdnc.dev.java.net
For additional commands, e-mail: jdnc-help@jdnc.dev.java.net

augusto
Offline
Joined: 2003-06-11

> jdnc-interest@javadesktop.org wrote:
>
> Just to be clear, I wasn't suggesting we ignore
> WebServices, as its
> an obvious trend for many applications. My intention
> was to stimulate
> dialog with the community on the specific problems
> they are working to
> solve at the moment so we can understand what's most
> important to
> developers.

Our main concerns are to get to data from all kinds of sources, it happens to be that for our application, the information in a database is the least interesting one so I'm a lot more interested in knowing how to get to non JDBC dependent data to rich clients.

Web services, EJBs, CORBA, I don't know if I understand how we get data from these sources into JDNC components. I haven't played with the API yet (just ran the demos and looked at the XML) but it seems very database driven. If possible, I'd love to see the datasources abstracted as much as possible from the get go. Maybe they already are and i need to look at the code more :-)

rbair
Offline
Joined: 2003-07-08

I don't really see why the DataModel in JDNC wouldn't work for EJB, CORBA, or some proprietary transport just as well as java beans and JDBC. The DataModel itself is just an abstract concept of tabular data where each "column" (aka field) has a name from which you can access the data.

I'm not a big EJB guy, but don't you usually transport info via value objects? JDNC works great for java beans, so it seems like that would be a natural fit.

Note also that JDNC has the concept of a "loader" which is the code that actually reads data from somewhere and loads up a DataModel.

I'd suggest taking a look in the swingx.data package -- particularly at the data loader & data model.

Rich

fnimphiu
Offline
Joined: 2003-06-17

Franck,

actually JSR 227 could make a difference. Oracle JDeveloper 10g has an implementation called ADF that already allows developers to use EJBs with Swing clients with no extra coding required.

I think that you raised a valid point in saying that the inventors of EJB had web applications in mind. It seems to be easy these days to forget about the real clients.

Frank