• Post Reply Bookmark Topic Watch Topic
  • New Topic

Service/logic reuse between apps on same app server  RSS feed

 
Robert Hayes
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there a best-practice approach to allowing J2EE apps within the same app server to interface with one another (ie: one invokes logic in the other ala SOA)? I understand the J2EE spec states that apps should be self-contained. I have limited experience with Web-Services... but they seem more appropriate for apps that reside on different physical machines (?).

I was hoping to stay clear of EJB but is that possibly the answer?

Thanks.
 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 37181
515
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Robert,
It they are in the same EAR, but different EJBs you can use local interfaces. If not, you have to use remote interfaces. Note that this is still easier than calling a true remote web service because you don't involve different machines, firewalls, ...
 
Robert Hayes
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeanne,

What if they are not in the same .ear file... and what if EJBs (ie: potential for local interfaces) are not used in either? Specifically: they are web-based apps using only one EJB type (MDB), and an O/R framework.
[ January 27, 2005: Message edited by: Robert Hayes ]
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Could you give an example of what you want to do? Typically session EJBs are the solution for communicating between EAR/WAR applications.
 
Robert Hayes
Ranch Hand
Posts: 116
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi David,

Simple example would be: a Membership J2EE application is deployed to an app server by one developer. Another developer (me) wants to get some real-time information out of that system: like a) member status, b) valid purchases to date etc. The other developer has indicated that there is quite a bit of business logic surrounding those simple look-ups, so it's not a good idea to access the RDBMS tables directly. So I need to invoke that logic to get proper results, and my app resides on the same app server.

I can see the use for Stateless Session Beans here. However, there are some catches: a) the other developer doesn't know anything about EJB (although I have used SLSB in the past and could potentially write them), b) the other application was not written in a de-coupled manner, so it may be difficult to "rip out" the core pieces of code that would need to be abstracted from the system, and c) the company for which we both work doesn't understand EJB and (from what I gather) considers it "too complex".

Thanks.
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Robert Hayes:
the other application was not written in a de-coupled manner, so it may be difficult to "rip out" the core pieces of code that would need to be abstracted from the system
This definitely makes the case for a SLSB.
the other developer doesn't know anything about EJB (although I have used SLSB in the past and could potentially write them)
If you could get the other developer to provide a simple POJO interface that provides the information you need, you could probably whip up a SLSB to wrap it in short order. The tricky part, of course, is that packaging an EAR containing EJBs is vastly more complicated than one without for a team that doesn't have much experience with them. You may end up being responsible for packaging both projects.
the company for which we both work doesn't understand EJB and (from what I gather) considers it "too complex"
Yes, this is a common conception of EJBs, and not unfairly earned, I'm afraid. Your other option would be web services, as you stated. While geared towards going over the network, it's not necessary. It comes down to deciding which is more complex: WS or EJB.

I can say that if you go the EJB route, XDoclet can vastly simplify the task. I would never, ever do EJBs again without it, actually. Granted, you'd probably be able to get away with a single SLSB. If you're not familiar with XDoclet but you still remember all the tricks of deployment descriptors, it may be overkill to use it.

I can't think of any better options for your needs. I would avoid pulling out the code from that other project because you'll end up with a maintenance nightmare trying to keep up with any changes they make. You could also sell it to the other developer as a chance to advance his/her career by getting their feet wet with EJBs.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!