We Keep Coding

How do I communicate between/connect two tomcat servers

I am working on a project where I have two servers (tomcat), Server A gives initial snapshot of information from DB(MySQL) to the frontend. Server B to serve updates to server A, both servers need to communicate. How do I connect them? Thank you very much for your help.

There are many ways two Tomcat instances running on the same host could be set up to communicate with each other. It's quite common to implement a REST service in the "server" Tomcat instance and have the "client" Tomcat instance send the REST request to the other instance. It's common to use either the Jersey or CXF framework to implement a JAX-RS REST service, or you could use the Spring framework to implement a more general web request handler.

Tomcat typically accepts HTTP/S requests. So you could program your own servlets in Tomcat A (and publish them as URIs) to accept data which shall be updated to the DB. Then, Server B must act as a client to server A, initiating communication whenever it wants, and sending the data to Server A as HTTP requests.
Taking security into account, I'd also suggest that Server A should forbid any requests to the updating URIs which do not come from Server B. For instance, securizing the updating URIs through standard JEE security.

AngularJS: Server Side Architecture

Within our corporate intranet, we have a few end-point service platforms like BPM, document management system, etc. These end-point services expose REST API. We develop web applications using AngularJS as front end.
There are two options on how we can make calls from AngualJS to these end-point services.
Option 1: Given these end-point services expose REST, call these REST API directly from AngualrJS.
Option 2: Introduce a middle layer (on an application server like WebLogic or Tomcat). Build a Java application layer that calls into the end-point REST API; and host it on this millde layer. The AngularJS calls into REST provided by this middle layer; this middle layer inturn calls into the end-point REST.
I personally prefer the Option 1; however I invite your openion on this matter. I have listed the pros and cons of Option 1 as I see them.
Pros of Option 1:
Better performance (throughput) given one less hop for HTTP requests.
Lesser development/deployment efforts due to one less component.
Lesser number of points of failure. If there is an issue, we know its either in AngualrJs or the end service.
Cons of Option 1:
Security issues? Not sure of this - would like expert comments on this.
CORS: the end services will need to enable Access-Control-Allow-Origin to appropriate domains.
Poor logging? If something goes wrong, the logs will be available only on user machines (IE/Chrome development tool) or on the end service.
Too much processing in AngualJS layer? This processing is mainly parsing the result from end service. This also depends on the kind of end service that is being used.

option 2 in my opinion is a better option in long run. There are few reasons for that.
Security is first and foremost, If you have a middleware in between, you can have inherent security, which means you can expose only those REST APIs which your angular webapp needs. You can also include a security mechanism like oAuth since you control the middleware.
Logging is another one. for sure any application nowadays do need some sort of auditing. both security and logging are layers before your actual REST calls.
You would be able to add some aspects on any key REST API, such that in case if that API is called trigger a mail, it's always handy to have those flexibility even we don't need at the moment.
You can include response transformation and error handling efficiently. Once you get the response from service, in your middleware you can transform the response, remove unnecessary or critical fields, conjure some values etc. This all can be done with angular also but then the real response or error is exposed to the client.
On the downside you rightly mentioned performance is one but imo keeping your REST middlware in sync with services REST is more bane. any new API added by services, needs to be included in middleware, recompiled and redeployed. But it also depends what are the likelihood and frequency of those changes? for any those changes you anyhow might need to change in angular webapp to include it.

You mention "Within our corporate intranet". Depending on how the end-points are secured, option 1 could be challenging.
Angular will run in a web-browser so if those services are only accessible via VPN / intranet, the web-app will only work if your computer is connected to that intranet (i.e. it won't work if you run it from home).
Another security challenge with option 1 is that if the end-points require special authentication "secrets" (API tokens, passwords, certificates, etc.), those secrets will be exposed and visible to anyone who uses the web-app since anyone can see the traffic between their browser and the server. With option 2, those secrets can stay hidden behind your middle layer.
Lastly, even if Angular talks to those end-points directly, you will still need to have the HTML / JS / CSS hosted on some web-server. You may not need a full blown application server but you'll need something to point your web browser at.
If those concerns don't apply to your case, then it's really up to you to pick whichever option you and your team are the most comfortable with.

Thanks for such a nice article.
If you are concern with security and your project requirement is focused on Security. One must go with Option 2.
If Security is not a big concern. Options 2 is better.

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.

rmi and webservice

currently i have an web app build with Strus2 and Spring (IoC, Transactions), and i want to split this into 2 apps; one client which will contain only the web part and one core services that will be accessed via webservices and/or rmi.
I have a dilemma in what technology should i use for "glue", because i like the fact that webservices can be accessed by any clients (php,.net,...,mobile), but as i understand java rmi is faster then webservices.
I was thinking to expose the functionality via webservices and rmi in the same time... but i do not know how to do that.
Also in my current app i have a ajax action that is executed each second from the client to the server, and in this new configuration i think that there will be some performance penalties due to this.
How should i "attack" this situation ?
Thanks,

but as i understand java rmi is faster then webservices.
Why do you think this? Do you have a citation to bolster this claim?
Both RMI and webservices are using TCP/IP; both incur similar network latency. The former uses Java or CORBA serialization to send messages over the wire; the latter uses either HTTP (for REST) or XML over HTTP (for SOAP or RPC-XML).
The relative speed is far more dependent on what those services are doing and how you code them.
I would prefer a web service because simple and open win. You are restricted to RMI/CORBA clients if you use RMI.

Nice. You are running Spring and you already have all you need. Just throw in a few jars (spring webservices and related jars) and you should be good to go.
Please refer :
http://static.springsource.org/spring/docs/2.5.4/reference/ejb.html
http://static.springsource.org/spring/docs/2.5.4/reference/remoting.html

Web Service vs TCP/IP Sockets (Java) + SQL Connections

We are currently are at a stage in our product lifecycle where we are thinking about moving to Web Services. Our system is written in Java which consists of a number of client and server applications which talk to one another over TCP Sockets and also has in-line SQL to perform data retrieval and updates (yuk! I know) which uses our own SQL Connection class which then uses the java.sql.Connection to connect to a SQL Server database using the Microsoft JDBC driver.
The applications bind to one another using TCP sockets. They request data from and push data to one another. Which works perfectly fine.
Thought
So we are looking at converting all data access and TCP communication to a web service.
The web service would be designed to run on a companies secure internet site. The idea would be that users could connect their clients to the web service from home - when they are not on the company network - or at work, when they are.
The client applications would send/recieve the messages to/from the server side applications using the web service.
The client applications would retrieve and update data in the database using the web service.
Question
I would just like to know what peoples experience is of doing anything with 2 way communication (request and push) over a web service (if possible) and what the thoughts are about doing this.
Converting the data access to a web service seems straight forward enough - I can forsee some issues with performance where large data sets are retrieved in some parts of the system.
I am looking through various reading materials on the matter as it is a while since I have touched web services (using C# and ASP.NET). Currently reading "Building Web Services with Java™: Making Sense of XML, SOAP, WSDL, and UDDI". I must admit I thought web services were always stateless but have just read that they are not!
Thanks,
Andez

It helps to think of WebServices as being the same as any other web application on the transport layer. It uses HTTP/HTTPS protocols in the same way, it's just that instead of sending HTML, it sends XML according to a predefined format (SOAP). As such:
It's Request/response oriented
Can be stateful in the same way as a web-page can be stateful, using sessions (assuming you have a web-service client that supports maintaining session cookies across requests)
All requests eventually boil down to good old-fashioned servlet endpoints in the server
Keeping these limitations and features in mind, think about your requirements and how they map against each other. If you need true two-way communication (push), then web services are not ideal. They are client/server, request/response oriented. The achieve push, you would have to poll from the client. A possible alternative could be to let both the "server" and the "client" act as web service "servers". That would mean bundling some light-weight servlet engine with the client (like jetty) so the "server" could make web service calls TO the "client". Another way is to look at two-way RMI/IOOP.
Yet another way would be to keep the communication layer as you have it today. There is no inherent gain in refactoring to Web Services just for the sake of using web services. If they don't add any benefit, it's just waste. As you already mentioned yourself, Web Service comes with a load of additional overhead (verbose protocol, servlet engine etc), so it really needs to balance the extra cost and development time with a clear benefit. As the saying goes "if it's not broken, don't fix it". As you say the current solution "works perfectly fine", I would probably not change it. That's just me though.