We Keep Coding

How can I identify the client or caller of an EJB within the request?

I have a system where several (20 or so) web app servers (hosting a website) talk to the same 2 - 4 EJB servers (through a VIP). I'd like to know if it is possible to identify which one of those app servers generated a specific request.
For example: Website example.com works by sending HTTP requests to any of 20 app servers to handle the request. These servers are named (internally) app01 through app20. It is ensured that all requests with the same session ID will be routed to the same app server, thus enabling us to logically track all requests from a single user. Some requests will need some extra data not available directly, for which there is an EJB (2.1) application on another cluster of 3 servers, named ejb01 to ejb03. Connections to the EJB servers are made through a VIP (ejb00), which routes the requests round-robin style to the three EJB serves.
Within the logging (we use Apache Log4J) of the EJB servers, it would be really nice if I could identify which of the 20 app servers a request originated from. The alternative is checking the logs on each server separately - but I don't have a good way to grep through the logs on 20 different boxes.
My question is: is this possible within Standard EJB? I'd be willing to do something non-standard, if there was nothing else, but it's gotta be reliable and work on my system. We use Weblogic 11g, both for the web-app and the EJB servers.
I've seen suggestions to pass the identity of the caller as a parameter, but that would mean an extra parameter for each of 20+ EJB methods, and that's rather unwieldy.
Any solutions, anyone?

There is no standard solution. There was a proposal in JSR 149, but it was withdrawn. Adding an extra parameter to the remote methods is probably your best option. If you're using RMI remote, you might be able to write an ORB interceptor to add a custom context on the client side, receive it on the server side, and set a thread local around the method invocation on the server.
WebSphere Application Server has a non-standard solution called work areas, which does work for remote EJB.
I am not familiar with WebLogic, so I don't know if they have a similar solution. Searching for similar terms finds a WorkContextMap that looks similar, but I don't know if it works for remote EJB since all the examples I can find are for webservices.

How to send message to JMS server from one machine and receive that from another machine in JBoss 7

I am trying to send message(TextMessage) to JMS server from my laptop, then I am trying to receive that message from another laptop. I am using JBoss AS 7.1. My both laptops are connected in same network.
When I am doing that I am getting exception. I searched for this in google and some is saying that in JBoss 7.1 JNDI will not get connections from remote IP's and they are saying that we have to use HornetQ.
Can any one please help in this issue.

Looks like you have two queues, one on each machine. They only have the same name, but are not connected in any way. You could make the sender machine use the remote queue directly, but it's advisable to use (like you have) two queues instead, one on each node, and then configure a bridge to move the messages from one to the other. In this way, sending as well as receiving messages will work within your local transactions, which is what you'll normally want.
In order to configure the bridge, HornetQ offers two options: A generic JMS bridge, and a core bridge. The former is generic, as it can bridge between JMS queues of any JMS provider. But the HornetQ docs recommend core bridges when using HornetQ on both sides, as they are faster and more robust.
The JBoss docs (the section "JMS Bridge"), describes the setup for a JMS-Bridge using the CLI. The HornetQ docs for core bridges describes the stand alone setup (outside of the JBoss server); converting that to CLI, you'll get (replace the parts in curly brackets with your values):
/subsystem=messaging/hornetq-server=default/bridge={bridge-name}:add(queue-name="{queue-name}", forwarding-address="{remote-hostname}", static-connectors=["http-acceptor"])
To see a brief description of all parameters, use this command:
/subsystem=messaging/hornetq-server=default/bridge=x:read-resource-description

cloud ready software

I have my own application server ( like oracle weblogic ) which handles HTTP request.
Now what changes required in my software to make it cloud ready.I was searching on the net and got one multi tenency documents.
what are other aspects in which i need to look into.

None, EC2 should act like any other web server. You still have the added overhead of maintaining the open ports and the like through Amazon's interface as well as on the server itself, but in terms of actually running a web server, it should be exactly the same.
In terms of multi-tenancy, again this is just down to your database architecture which RDS should take care of (if you have a tenancy key).

how to design a web application that developers can use to retrieve the crashdump/Logs from customer environment

Hi I am c++ developer and my knowledge to web technologies is minimum. Right now i am trying to design a web application which the development team can use to connect to specific customer and collect any crash dumps or log files.
With my research i realized it could be the following way.
1) develop an agent with build it http server and listing for request in specific port and install it in a machine with internet access and public ip address in all customer sites environment.
2) The agent is capable of collecting the required information from the customer environment based on the request it receives.
3) Develop an application with browser interface, and installed it centrally on the development data center. This application must have capability to connect to a specific customer environment and send http request over the internet to listening agent in that customer site and collect crash dump or logs or some statistics on the customer environment based on the request.
I am not sure this is the right way of doing, but I am sure there is a better way to do it.
Any help or pointers on what is the right approach and what kind of infrastructure is require to implement this kind of a service is highly appreciated.
Regards,
Prakash R

The approach looks serviceable, except you don't need to develop any applications to do that, as existing applications fit the bill nicely:
Use a web server of your choice. Apache is well known and open source (free). You might wish to configure security.
Assuming you're running under unix, you could use a link to include the log directory in the file system the apache serves.
Use your browser. (You obviously have one already). If you have many sites, you could use bookmarks, on a link list in your intranet, or ...

Java EE and application servers - What can i do?

I decided that it is time for me to dig into the whole Java EE stuff. I am using EE some techniques whithin Java SE like JPA or JMS, but i still messing around with Java SE and i believe Java EE and an application server will solve some of my problems i have.
BUT: I have still some questions after reading some articles on the web.
1st: Am i limited to request-response applications? I have an application which serves XML documents via HTTP. All delivered objects are added to a queue which will be dispatched in a different thread. Some validation is made for this objectes, including the opening of sockets to a remote machine (I heard EJ-Beans are not allowed to do this, is this true?). So, is is possible to do this within an application server?
2nd: I know there are Message driven beans, is it possible to send JMS messages to a MDB from outside of the application server? I have a service which sends JMS messages, but runs, as a legacy system, not inside the same application server.
3rd: How can the System Adminstrator or User configure my application? I know that some things like database connections are configured within the application server and my application can lookup them via JNDI or get them via DI. But what about application specific configuration?
Yeah, these are quite noobish questions, but maybe someone has the time to explain me how all this stuff is working. :)
regards,
Posix
PS:
4th: It seems EJBs are not allowed to do anything with files, so Java EE seems to be no option for a Service which receives Files, pushes them around to different systems and want them to write to a Socket (see question 1)?

I can say that Java EE can be used without any doubts in your case. Let me drill a little bit more into your specific questions:
You can open socket connection from your EJB. There is nothing that prevents you from doing that. However this kind of operation is not advised for Java EE applications. In my opinion the better option is to implement Java EE Connector (JCA) that would manage pool of socket connections to your proprietary system. This is the model way to implement such a integration as per specification.
Yes! It is perfectly possible to receive messages send from external application/system (outside the AS). This is main idea of integration using messaging :) In many cases your application being Java EE application receives messages via MDB from JMS channel, but JMS is only an API and can be implemented by any messaging system e.g. IBM MQ. In this architecture the external system puts an MQ message onto the queue and your Java EE application that listens to the very queue receives the message via JMS API!
Generally speaking Application Server gives the Administrator great tools to manage Java EE resources i.e. data sources, JMS connection factories, JMS destinations, JTA transaction manager, etc. If you require the ability to change your specific Java EE application the best options seems to be JMX. Just implement a few MBeans, export those to the JMX server embedded within your Application Server and you are done. This task is really trivial in, say, JBoss, but most of the modern Application Servers offer extensive JMX capabilities these days.
For the first glance, EJB doesn't seem to be the best for dealing with files. But remember that implementation of your EJBs is still written in pure Java, so nothing prevents you from reading/streaming files and so on. I have experience with large Java EE applications that are handling large files as input files and can assure you that Java EE is is a good technology choice :)

Here are the restrictions on EJB 1.1 spec.
Here's my take on your questions:
I believe an EJB can open a socket on a remote machine, but I would say that opening sockets is too low level an operation. I'd think about exposing whatever that socket is doing for you as another EJB.
An MDB is just a listener that's registered with a particular topic or queue. It doesn't say anything about sending. If your client knows how to get a message to the queue it's possible. They just have to know the queue URL and be able to create a connection.
The admin sets up connection pools, JNDI names, etc. - everything. They do it using the admin console for the app server.

It's a violation of the EE spec to do anything with files (to ensure that an EE app is portable and distributable). However since it's all just plain Java code, yopu can choose to do anything that you want. As long as you know how your target environment looks (eg the system is for internal use) I wouldn't hesitate modifying files just because the spec says so.

In an application server like Tomcat (others too, probably, but I've never worked with them) you can not only execute things upon receiving a request, but also do things (including starting long running threads) on server startup. Basically you can do anything that you can with "normal" Java. In fact, you could put a normal Java app in application server if you just include a piece of code which calls the appropriate main() on server startup.

I would suggest applying each technology to the appropriate points where you are currently feeling pain. Regarding your specific points,
In an EE context, you would add the messages to a JMS queue, that has MDBs which would do the actual processing. Regarding the management of the HTTP request/response lifecycle, you would manage this the same way you do now, or use an existing library to do if for you. By moving to an EE app server, you would allow the app server to manage the threading, transactions, etc. instead of having to manage it manually.
As duffymo stated, MDBs are responsible for receiving messages, they do not care where the message originated from.
The system administrator can configure the app server as duffymo stated. Additionally, you can expose JMX beans to other systems or to the end user to allow them to configure services if you so desire.