• Post Reply Bookmark Topic Watch Topic
  • New Topic

Session beans and configuration properties  RSS feed

 
Rutger Dahlstr?m
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi there,
I'm experimenting with a J2EE application, where I have a session EJB that
calls a Web Service. This has worked fine so far, but now I would like to
be able to set a few properties for the EJB in runtime, before making the
call to the Web Service.

The situation, in principle, is the following:

I have a Web Service called MyWS with a Web Service method that has the
following signature:

String myMethod(String a, String b);

The session EJB is currently stateless and is called MySLSB. It has a
method whose purpose is to expose the Web Service method to a J2EE client
(like a servlet or a JSP). Therefore I would like the signature of the
MySLSB method to be the same as the Web Service method.

Hence, MySLSB (the bean class) looks something like this:

public class MySLSB
implements javax.ejb.SessionBean {

// ...

// Business method
public String myMethod(String a, String b) {
String myString;

// ... some work ...

return myString;
}
}
The MySLSB.myMethod() method will have to call the corresponding Web
Service method. But what if I want to let the client of the EJB decide some
configuration parameters for the Web Service, such as username, password,
hostname (where the Web Service is located), etc., before calling the EJB
method? With a stateless session bean I cannot set any state in advance
before calling a business method. I could use properties in the deployment
descriptor for the EJB, but that isn't good enough, because that would mean
configuration at deploy time, and I want to be able to make the
configuration at runtime.

I could use a property file where I put the configuration details at runtime, and then I let the EJB business method read from that file, but according to the EJB 2.0 specification, you are not supposed to have EJBs read/write from/to the file system. Although the application server doesn't prevent me from interacting with the file system, I would like to avoid it.

Another alternative is to first write the configuration information to a database, and then have the EJB business method to read it from the database, before calling the Web Service method. But in this case I would need some sort of unique ID for each set of configuration information that is written to the database, so that the EJB business method will know what configuration it should read.

Yet another option would be to use a stateful session bean, which can hold state between business method calls. But then there is the issue of performance. I would like to build this application so that it can handle a very big load of simultaneous client access, and I suppose that stateful session beans aren't made for this kind of load. Does anyone know how sensitive stateful session beans are to high performance load? Can a regular J2EE application server such as Weblogic, WebSphere or Sun ONE AS handle stateful session beans that have hundreds, perhaps thousands of instances in the pool? (Each stateful session bean can handle only one client at a time, and the app has to be able to handle many clients.)

So, what to do? Do you have any suggestions? Have I misunderstood something about EJBs or is my reasoning correct?

I'd be grateful for all input that I can get.

Best regards,
Rutger Dahlstr�m
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Would it be acceptable to overload the business method like this:

where the Config class would contain the properties and if missing, the defaults would be used.
 
Rutger Dahlstr?m
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello again,
I have already thought about the idea of overloading the business method, but it is not optimal. I really would like the method signatures to match exactly.
However, if I don't find a better alternative, it is quite possible that I'll settle for the overloading strategy.
/Rutger Dahlstr�m

Originally posted by Lasse Koskela:
Would it be acceptable to overload the business method like this:

where the Config class would contain the properties and if missing, the defaults would be used.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!