I have had lots of trobule trying to get my head around how to solve this scenario:
We have an integration application that uses Camel for integration. This application also has a REST Api that exposes some services providing information about the application, for instance listing the active routes etc.
I have created a user interface for this using AngularJS that connects to these rest services. My main problem is how can I package this application as a self contained jar-file that provides the user interface and all the camel integration.
My working theory: Use a separate Jetty server to serve the Angular JS files and let Camel expose the REST services. The problem with this is CORS since the REST services reside on another port than the jetty server serving the Web UI.
Some requirements for the solution:
Must be a single self contained jar-file.
The camel integration is the main purpose, the Web UI is secondary
and only used for trouble shooting. No need for a high performance
web container since the Web ui is used by only a handful of users.
I have been struggling with this for a couple of days now and it feels like I am over complicating the solution. Help on how to solve this is greatly appreciated.
You could take a look at hawtio
http://hawt.io/
as that is how we do that, hawtio is a web console for java, and has plugins for Camel. Its built using angularjs, and uses REST to communicate with the local or remote Java JVMs. To make the REST calls easier we use Jolokia.
Jolokia requires an agent to be embedded in the JVM, eg where Camel runs. Then that helps with CORS et all. http://jolokia.org/reference/html/security.html#d0e2490
Related
I have an existing Java application (Spring based) that currently does NOT have a web interface, nor does it run in a web container. It packages up nicely with a start program and just works.
What I need to do is add an administrative web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs to give the users a warm fuzzy feeling knowing that everything is working. As we are a Spring shop, and some of our web applications already use Spring MVC it only makes sense to us, however, I'm not happy with the suggestions I've had from our internal Spring folks on how I should procede.
What would be the ideal way to bolt on this web interface?
Convert my application to a web application and have a web container launch the application. I not too keen on this approach is the web tier is really secondary to the primary application.
Create a separate project that packages as a war, embed Jetty in my existing app and have it load the war. I think I can use the context loader listener to make the root context of my application the parent to the web application spring context. This would involve breaking up my Maven project into 2 projects I believe. I can't use an existing web technology for communication between the web tier and the primary application as my primary application is not web enabled.
Embed Jetty and put the Spring MVC stuff directly in my app. While I've done this approach before, it does involve some ugliness - for instance exploding the JSP tag libs into my jar.
Any thoughts on some clean separation here?
Also of note, my current jar contains some utility applications which some shell scripts launch. Going a pure WAR route would make this not so easy, since I can't juse point java at my war file and choose a class to execute.
Thanks.
If it's true that web is just a minor addition the application, migrating it to WAR and deploying in servlet container might be an overkill. Embedding web server/servlet container looks much simpler, although it doesn't have to be Jetty or Tomcat. You can use web server built into JDK or write one on top of netty or even raw sockets. But that's a hell to maintain.
Yet another solution to springs to mymind when reading:
web interface for some administrative type things, retrieving real time metrics, and perhaps some graphs
Maybe you don't need an interface, but monitoring infrastructure instead? Check out JMX (Spring has great support for JMX) - and write a second web application that simply connects to your standalone Java app via JMX and displays the metrics in fancy way. Another approach is to expose JMX via Jolokia, which translates JMX to REST services.
This approach has several advantages:
monitoring API is universal, and you get it for free
you don't have to use web client, monitoring application is completely decoupled,
finally changes to your original application are minimal. Check out this proof of concept: 1, 2.
It really depends on the structure of your existing Java/Spring app and how much of an API it provides. I've done something similar to this and I approached it by creating a separate Spring MVC project and then specified the existing Java app as a JAR dependency.
This is easy with Maven (or Ivy, etc) and provides nice decoupling. The trick is to be able to write service classes in the Spring MVC app which then access data via your dependent Spring app via a simple DAO class. That's why I stated at the beginning, that it depends on the structure of your original Java app. It has to be able to provide an API for data access that you can then plug your DAO (impl) into.
If this is not easily done, then the next option I'd suggest is simply converting your Spring app to a Spring MVC app. I've worked on another app where we did this. Using Maven, its possible to specify that the build can create either a war file or a jar file (or both). So it can be deployed as either a webapp (via war) or a normal app (via jar). Yes, the jar version has a bit of bloat but its a worthwhile compromise.
The question of embedding Jetty or using Tomcat via a war file is a completely separate issue that has its pros and cons. It shouldn't affect the approach you take in architecting the web app in the first place.
I want to run a standalone java application on a remote server. It would not be accessible to clients, but would do background calculations and interact with a database and Secure Socket connection to a third party site. It would also interact with a php site.
Do I have to deploy this with JSP, or can I write a standalone application? If so, how would I deploy a standalone java application (jar file) on a remote server? I understand that I must have them install a jvm on the server (not a problem) but then how would I deploy it (if possible). Would I start it with a command line?
I know I have much to learn, but I am not sure how I would access the command line on a remote server. Through the cPanel?
Thanks.
First of all, you'll want to set up some firewall rules to allow access to that server. I'm hoping that you don't expose that server naked to the Internet.
If all you need is database access exposed on the Internet, I don't see why it can't be a secured web app deployed on a servlet/JSP engine and accessed via a web server. You can leverage basic auth for security, JDBC access to the database from the server, and servlets as controllers to accept requests in a nice REST API.
It'll save you the complications of sockets and inventing your own protocol (use HTTP), starting and stopping the application (now it's just a web server/servlet engine), and deployment (send a WAR file).
Does it really must be a 'standalone' application? I think that in your case the best match would be to use Spring container to load your application within some server (tomcat?) and expose services via standard controllers - with Spring you only have to add some annotations on services methods actually.
Then, your php site can interact with these controllers using for example ajax requests.
If your application is written already, you can easily transform it to run within Spring container. It's very non-invasive and promotes usage of POJOs.
We have a java server application which runs certain batch jobs. It's core function is not as a web application and there's no reason for it to be that. But we would like to add an option to check what the app is doing from a web page. And we thought this could be nicely done with the Google Web Toolkit.
In any previous experiences we have with GWT we have deployed it on Tomcat. But in this case it seems like overkill. The web part is more of a side function to what the application is actually doing.
I'm thinking of a solution where the web server is integrated into the jar file - perhaps Jetty? So that the full java application can be deployed to a single jar file together with the web/GWT part.
There may be performance aspects to this but the web side of things will have very few users. Are there any other reasons not to do it this way?
And, can you give some advice on how to configure Eclipse / Ant / Jetty / GWT for this?
we had the similar experience at our previous project. There was an eclipse-rcp application, with embedded Jetty server (it was started programmatically when application was starting). GWT application was deployed into the Jetty as usually. Also there was a OSGI-service as a controller to provide communication between GWT-server and other parts of application. GWT server was usual RCP server, which is described in the most of examples. It had a reference to the controller. Moreover, it was an event listener, to support bot-side communication.
The main problem for us I think, was synchronization problem. Since there were a lot of messages between eclipse-rcp application an GWT-part (every let say 100 ms the message was received) and GWT had an asynchronous way of communication between client part and its server part, then some mechanism had to be created to synchronize those messages. Otherwise there were no performance problems (except IE 6. which had to be supported:S :D).
Hope this will somehow help.
Upd: As far as I remember, the controller was registered as OSGI service only to be able to communicate with other services of Eclipse-RCP part. In order to communicate with GWT controller was implementing special interface, which was known to the GWT-server (Controller was registered as an implementer through instantiation and the server was regsitered in the controller as IMessageListener). This interface was lying in separate project, which could was also built into the .war file. This project also contained number of event to support backward communication from controller to GWT-server through IMessageListener interface.
It's kind of confusing probably, sorry. May be I should draw a diagram..
I have set up a CXF web service which works well. My service primarily loads data from an ftp to a db.
I would like to create a web interface through which the invoker can view the progress of their package. I thought it would be easy to integrate Spring MVC with CXF but there doesn't seem to be any good solution. I searched all over the net and could not find any thing simpler than this http://ayax79.wordpress.com/2009/02/19/making-spring-mvc-and-cxf-play-well-together/
The reason I would like to integrate Spring MVC with CXF and not create a stand alone web interface is because I have some custom Spring beans with in the CXF service which I can make use off to start and stop the process.
Is it that difficult to build an interface on CXF? Or am I just not thinking in the right direction?
The article you linked to has more to do with handling 1) web requests and 2) CXF requests within the same webapp, i.e. building a web application which can accept traditional http requests for MVC pages and also accept web service requests.
The author of that article seems to be pretty confused about Spring and how ApplicationContexts work, as the commenter Felix provides a good and simple solution for what the original author wants to accomplish (reuse the same bean definitions and instances within two contexts, having some URLs mapped to DispatcherServlet and other URLs mapped to a CXF dispatcher).
If you simply want your Spring MVC web application to be able to interact with and make requests to a CXF service, this is simple - you write code to consume the services as you would in any other type of application that interacted with a CXF/Soap/etc web service.
I'd recommend taking a look at the following sections in the Spring manual about access JAXRPC or JAXWS web services:
Accessing web services using JAX-RPC
Accessing web services using JAX-WS
Another option that you have is to simply generate client proxies for your CXF service using a tool like wsdl2java. Note that the next two options on this page I linked to, "JAX-WS Proxy" and "JAX-WS Dipatch APIs" do the same thing functionally as the Spring option above (creating a dynamic proxy at runtime).
For my web application, I am thinking about using the Spring framework. Initially, I was thinking of having different actions like create user or login, but now I have to expose some functionality to other applications. Should I create a web service that I call from my application and others do as well, or create an action from Spring and then just have others call the web service? It seems like I should minimize the different ways to call something, but does it make sense to call a web service that is running on the same application server as my main app? Would this be a bad idea from a performance stand point?
Update
I was concerned that Tomcat wouldn't be able to serve both the static or dynamic pages on port 80 (so users could go to www.example.com/welcome.jsp instead of www.example.com:8080/welcome.jsp), as well as a web service but I guess it doesn't matter as both are just served as requests from Tomcat. I'm guessing this means I'll have to change Tomcat to run on port 80 and other applications will have access the web service via this port. Or I could leave Tomcat running on port 8080 and put Apache in front on Tomcat on port 80 and Apache will serve the requests to Tomcat. Is that correct?
I'd put the common business logic in a "business service" and :
call it from an action in your web app
expose it as a web service for other applications
To me, there is nothing bad with this approach and it's pretty easy and clean to implement it with Spring. Actually, I would find ugly to expose this business service as web service only and to call it from the web app (and I'm pretty sure that this will be more complicated to implement on the web app side). You have different "usage contexts", just expose the adequate interface for them.
(EDIT: I'm answering a question of the OP posted as comment below)
You can deploy the web application and the web service in the same WAR (but this is just a deployment choice, you could package the business logic in a JAR and use it in several WARs). Regarding the port, I'm not sure to understand your question. Traditionally, you'll use a web server (e.g. apache) in front of your application server. If you don't, you can always choose to run you app server on port 80. Actually, in both case you are free to use whatever port you want. Using port 80 is just convenient.
Yes, your update is correct.