Peter Storch

Hi have you read about this pattern / practice?:

Redirect Aft Post

Originally posted by Stan James:
... Web services - XML over HTTP ...

Yes we thought about it, but it feels a little bit strange for company internal java only services.

Originally posted by Stan James:
... re-inventing the remote procedure call...

yes, that is where you end up. So what's ejb good for if not for distributed common services?

Hi there,

we are looking for best practices to design public services with EJBs.
With public service we meen one enterprise application is useing one or more EJBs from other enterprise applications. In the same container or another.

The biggest problems we face are:
1) loose coupling (how to get as few dependencies as possible?)
2) backward compatibility (how to keep the clients stable if the service is updated?)

Is there a (good) way to call an EJB of another enterprise application without the need to have .class files of the other app?
If it is necessary, how can these classes be build that you don't run into class loader issues? Especially if you want to upgrade the public service without updating its clients.
We thought of designing a public service EJB with just an execute() method with a HashMap (with basic data types and java.lang.* Objects only) as input and output. But is this really a good design? Does it really solve the dependency problems we have?

We first tried it the "normal" way. Just define your stateless session bean. Build a .jar file for your service users and deploy your and the other enterprise applications in the same appserver. Then we got more and more applications using more and more services between each other (dependencies!).
Then it comes the time that one service or some utility classes which where used by the service needs to be upgraded (e.g. for bug fixing or further improvement).
Then we face the need to upgrade "all" other applications to solve class loading issues even if the service interface didn't change.
And if the different enterprise applications were built by different projects with separate budgets it's even more difficult to say: hey you have to update your app because we updated our app. Even if they don't get more features they have to update, regression test, redeploy there applications. That means spend money for nothing.


Are there solutions to these problems? Can you point me to resources to get more information?

Thanks!

Originally posted by Eduardo Rodrigues:
If I put the VO�s showing the dependendy then my component diagram will be a confusion!

That's the point. UML diagrams should help to communicate a design or a solution and not make it more incomprehensible.

The same goes for utility classes, like logger classes and so on. Every other class needs it and has a dependency on it. But that's obvious and doesn't need to be communicated via a dependency in a class diagram.

Hi Dev,

all you need is avalialbe in this forum:

SCEA FAQ

SCEA Links

The ClassLoading mechanism is definately Thread safe (synchronized).

But be carefull, if you have more than one ClassLoader. You can have the same class loaded twice in different ClassLoaders with different static Object references.
A class is unique by its full name and its ClassLoader.

Yes, that's ONE answer (the one with keeping the session data in the web tier).

One other answer could be (with keeping the session data in the ejb tier):

Get data:
web client -> business delegate -> SFSB -> DAO -> Value Object

Set data:
web client -> business delegate -> SFSB -> Value Object

To persist data:
web client -> business delegate -> SSB -> DAO -> Value Object



You should have some arguments why you chose the one over the other solution. Not just say here it is, eat it.

Hi,

I don't think it's usefull to model the dependencies to the TOs. As you said it clutters the diagrams and make them less readable and understandable.

But you can show e.g. in one Sequence Diagram the flow through your layers: the Servlet calls the Business Delegate and that calls the Session EJB and DAO ... and the arguments as well as the return values are always TOs.

Originally posted by Mark Spritzler:
Nope, not taken from books, but from all of my experience with them.

Yes, experience is good. And it should be your own and not someone elses. This can be different sometimes in somecases

Thanks Roy for this information.
This feature must be supported by the webcontainer. As one stated in the other thread is that not all webcontainer have this feature.
And cookies and URL rewriting works always regardless of http/https.

Hi Roy,

Originally posted by roy siju:
Now if from the same browser If I jump to another URL will it be able to read the my https url(referring url) and can break into the server "some.server.domain".

No, this is kind of browser policy. They never send a https URL as refferrer to another webserver. If they do, it's a security bug.

Originally posted by roy siju:
From Cade's Guide:
-----------------
"SSL connection also provides a maintenance of state between one request and the next. Using the state in the SSL connection at application level avoids the security problems associated with cookies or URL rewriting"

Yes, HTTPS (SSL) avoids the security problems, because with http the cookies and URLs are submitted in plain text over the network. But this doesn't affect the session handling of the web container.

Originally posted by roy siju:

Regarding point 5 ...
In my project we have 1 web server ( SunOne WebServer ) where we have kept the static contents ( like html, javascripts, images , css etc) and the dynamic request gets forwarded to Application Server ( WAS 4.0 Which has both WebContainer and EJB container..So, Servlet , JSP, EJBs are all in AppServer ). Here I was thinking that if we would have 2 SunOne WebServer and a hardware load balancer in front of it...what will happen?

So the SunOne WebServers have the WAS Plugins installed, but there is a load balancer (extra machine) in front of it?
Ok, then the Load balancer has to handle the session affinity otherwise the AppServers have to share their session information (synchronizing, uh oh complex topic).

Does every WebServer (PlugIn) also know every AppServer? That would make it even more complex. Then you have a two stage load balancing here?
I give up.

Originally posted by Mark Spritzler:
... my philosophy is to not use Stateful Session beans. There are always other alternatives.

If you need to hold state, and not store in a database, then EJB's really probably won't be your best bet. Also, this is true if you are using the Web. i.e. Servlets and JSP, they have a better mechanism for session, either URL re-writing or Session contexts.

...

I wouldn't generalize this rule. I think the EJB container has the same posibilities to handle the resources occupied by session state as the web container can.
There are some perfomance results out there which proofe Statefull Session Beans better performance than Stateless Session Beans (because of e.g. no bean pool operations). Or at least no significant differents. It depends on the usage.

You shouldn't abandon Statefull Session Beans just because someone said (or some books state) that they are bad. It really depends on the usage and on your alternatives (http-session, temptable, etc.). You should always (ALWAYS) make your own performance analysis.

It really depends on where you need the session data (webcontainer and/or ejb container), how much data it is (serialization issues), how long a session lasts approximately and how many parallel session you might have.
You should also consider appserver clusters and failover issues. That can have an impact on your design desicion.

Hi Roy,

that's really a long post. I give it a try.


1)
If the user disables cookies it depends on the webserver (feature / configuration) if it is able to switch to URL rewriting.
If URL rewriting is in use you can see the session ID appended at all URLs. Have you seen http://some.server.domain/some/webapp?JSESSIONID=blahblah ?

2)
I don't think https makes cookies and URL rewriting unnecessary. Your webapp still needs one of it to manage its session.

3)
I think it must be the plug in. Because it only knows the other machines and their connection. But this is an implementation detail of the webserver -> appserver combination. I'm not really sure.

4)
I'm not really sure here either. But I guess it's also the plug in. Because the client can't know that there are other servers behind. The fact that there are more than one appservers is hidden to the client (it's transparent).

5)
What exactly do you mean by webserver here? A simple webserver for static content or the webcontainer of an appserver?
The connection to your statefull session bean is your remote object reference. You have to keep this remote object reference in your http session to associate it with your client requests. So if you answer your question about the affinity of the http session then the affinity to your SSB is solved.

6)
See answer 2). I don't think https session management is different to http. You still need a cookie or URL rewriting. The fact that https is statefull doesn't change the implementation of the session management in your webcontainer.


I hope I could help you with my answers. I'm not quite sure with all of it but it's my best guess.

Both A) JSP and E) Servlets can be used to serve dynamic and static content.

As you know all JSPs are compiled into a servlet, so technically there's no different.