I have an external tool that is a tomcat webservice (distributed as a .war) that I would like to use from .net. I have a fairly complex environment and I would like to not have to deal with adding more moving parts (tomcat, java, etc) to the production machines. Is there a way to convert the app to a dll?
I'm afraid the only option you have is to deploy the WAR in a Java environment and then call it from your .NET environment.
I can recommend Jetty for deploying the WAR, I have had much better experiences than using Tomcat. It's simpler, starts up faster, the errors are easier to understand. (But obviously any Java web container will do.)
Then call your Java service from your .NET code. It seems like the Java code already offers a web service, so you need to build a client for that in .NET. If it uses a standard web service protocol like SOAP there should be lots of libraries available for .NET to allow you to do that.
There is no quick automatic way to convert Java into .NET alas; so this is your only option.
.dll are totally windows specific things where .war is totally jvm specific thing.
I don't think you will find tool / converter for it.
I would suggest consume web Services from your .net
Utterly impossible. Be glad that having this tool as a webservice means you only need a JVM and a servlet container to use it, rather than having to rewrite it completely. When it comes to application integration, this is a very easy case.
Related
I'm gonna be creating a fairly straightforward Java app for my company that will process a csv file nightly. It's going to be running on our existing Small Business Server 2011 box so it definitely needs to run as a service (cause it has to run whether someone is logged into the server or not). Eventually I'd like to add a web component to it so I can view the log files from this app via a browser instead of having to pull them off the server manually.
I'm looking for feedback on what would be the best approach for this project. Should I use Jave SE and use a service wrapper around the created app to turn it into a service. Or should I use Jave EE (which I assume already runs as a service)? I've never used or developed for Java EE, so I'm not sure if this would be the best approach or if it would be overkill. If Jave EE is the best approach any and all information you can share on how to get started with it would be much appreciated.
Thanks,
Harry
For the short term, are you looking for a web interface through which someone uploads (web interface) or some process pushes (web service) a csv file that you then process? If yes, then consider Java EE: servlets, RESTful web services, and such, as others have mentioned.
Otherwise, are you just going to process an existing csv file that's "out on the file system somewhere" on a scheduled basis? If yes then consider timer based Java EE service.
Your production environment's management team might have some insight on what they'd prefer. If they are oriented around a windows management scheme they might be more comfortable with the "native windows" approach to deployment, start, stop, restart, scheduling, etc (i.e. the service-wrapped java program). Another layer of "service management" for just one process may be unnecessary complexity.
Document your setup/configuration/expectations whatever you do.
Longer term, as pointed out by others, your desire for a java-based web monitoring interface will require an app server. Consider your short/longer priorities, schedules to be met, etc. What do you need, when?
Java EE is a set of APIs, including JMS, servlet, JNDI, JDBC, EJBs etc. Consequently by using any one of these APIs you can pretty much claim that you're using Java EE, for what it's worth.
As to your particular problem, I would perhaps develop your program as a simple servlet based app and run it under a small container such as Jetty. That way you have a lightweight container (Jetty) and a fairly trivial program to write that can have a simple front-end for admin/monitoring. Note that the Servlet API forms part of the Java EE spec, so you're Java EE compliant, albeit in a minor fashion.
An alternative to this is (depending on how important that web interface is) is to write the program as a standalone program, and run it as a service using the Java Service Wrapper. At a later date you can then embed Jetty into your program and write your simple servlet-based API to run under the embedded web server. I used this approach on a number of projects and it works very well.
Anything that requires enterprise-level functionality should be done using Java EE:
The Java EE platform is built on top of the Java SE platform. The Java EE platform provides an API and runtime environment for developing and running large-scale, multi-tiered, scalable, reliable, and secure network applications.
http://docs.oracle.com/javaee/6/firstcup/doc/gkhoy.html
Others have explained you what is JavaEE.
Since you say "simple", I guess JSP and Servlets can do the work. You will need a web container like tomcat and that's all(it is easier than having a ejb container + web!). Actually servlets and JSP can do stuff which are not simple too.
If you are willing to use something like sessions, which have great design than Servlet sessions, then you might want to deal with EJB and all.
Unless you're ready to implement a web server yourself from Java SE, you don't have much choice: you'll need some web application framework. It can ba a Java EE web container, or another implementation like Play, for example. But Java SE won't be sufficient.
You may use webservices for instance axis2
I need to decide between various Java technologies to install on a Linux server.
My back end (biz logic) is a Java program that must communicate with C functions using JNI. This Java program also must communicate with Oracle database (11G) using JDBC on one side, and BlazeDS residing in a Java-based Application Server on the other side (to communicate with Flash plug-in on client side). I also need an HTTP web server.
Not knowing much about Java, I wonder what the highest performance (e.g. fastest) and/or cleanest solution might be.
For example, should I install JDK on the server to provide JNI functionality, then then use Tomcat for everything else? Or, does Tomcat also include JNI? Or would something like JBoss which includes J2EE and serveletts capability be better, since it does everything in one package?
Just trying to learn any conventional wisdom about possible solutions, and pros and cons about going one way versus another.
Any Java runtime environment can do JNI - so by implication if you have any application server (e.g. Tomcat or JBoss) running then you should be able to do JNI just fine.
Tomcat would be perfectly fine for what you are describing.
It's a popular lightweight application server
It supports servlets and JSPs so works well for serving HTML
It's probably a bit simpler to get started with than a full JBoss setup
On the other hand JBoss is great as well.
More of an "Enterprisey" focus - you can optionally get excellent commercial support from Red Hat
Might make sense if you wanted to leverage some of the other products in the JBoss ecosystem
I basically think both would serve your needs. I'd probably suggest writing a simple servlet-based application and try deploying it to both Tomcat and JBoss to see which one you prefer. If you stick to standard servlet features then your app should run on both Tomcat and JBoss so you can keep your options open.
The other thing to consider early is tool support - make sure you get comfortable and happy with your Java IDE tooling for your app development. My personal choice is Eclipse, which has great support via plugins for both JBoss and Tomcat. But most of the other major Java IDEs like IntelliJ IDEA or Netbeans should serve your purposes as well.
G-WAN is an HTTP server (critera #3) which executes Java scripts that can use Jar and other Java classes (criteria #2) while at the same time run C/C++ scripts (criteria #1).
The advantage of this solution is that you will have only one program running (no intermediate layers, no wrappers).
Disclamer: I am involved in the development of this project.
is there any particular way to convert a Ruby on Rails project to a JRuby on Rails project?
There now is a need to get the Rails side to talk to a Java server via RMI so was wondering how to make the conversion. Thanks.
As #Karl says, it pretty much works but there are a number of caveats you should be aware of:
The database adapters will be different from the ones you may be used to. They're based on JDBC. For example, the MySQL adapter install is described here
You will generally deploy to Java application servers in production such as Glassfish, Tomcat or Jetty. Typically this is done using Warbler
Certain gems with native extensions may not work. See here for details on the what is required
It pretty much just works, you simply run it with JRuby instead of Ruby.
You might be interested in this though:
http://jrubyist.wordpress.com/2009/07/15/jruby-and-sqlite3-living-together/
At the moment, I have lot's of Java which does all kind of nifty stuff and I'm happy with it. The code is command line driven which have been great so far, but I recently decided I want to make the functionality available through web-services. Since my is complex and I'm happy with the way it's written , I don't want go through the pain of porting it to other languages. So I set out on a google journey to find out what web servers exist (on a Linux machine, though it's interesting to hear the answer without that limitation).
From what I could find, it seems that there are two viable options: Apache Tomcat and Sun Java Server.
What are the reason to choose one on top of the other? what are the strength of each and what are the weaknesses? Or, perhaps, there is a third one which is much easier, flexible and less cumbersome.
Anyone?
Easy, flexible and not cumbersome, that would be Jetty, but also Simpleweb might be useful. You dont say much about your software so i'm not really sure, but for a command line program, I don't think you need all the JavaEE stuff.
The mainstream servers are these.
I think the Apache Tomcat vs Glassfish (Sun Java Server) discussion is irrelevant for your needs, any would do.
There are many containers for Java web applications, they all have their own strengths and weaknesses. If you're looking for a container to support a business application, you should probably take a look at how they differ and work out which suits your business and IT drivers.
The key thing is that they all support the servlet specification - your webapps can run in any of them - which means you can change your mind easily. Some of them will also support more of the Java Enterprise Edition specs, so may be too heavy for your needs.
If you're just getting started, I'd suggest Tomcat. It's basic, but it's reliable, quick to run and start up, and it's got a really easy web-based webapp deployment interface.
Your question is actually a bit too ambiguous and wide. You can in fact run Java code at any machine you like, regardless of the language you programmed the webbased interface in. You can for example create a PHP based website which interacts with a "backend" Java application (the "command line application" as you call it). The only requirement is to have a JRE at the server machine. Then basically everything as web interface suffices: CGI, PHP, ASP, Python, etcetera, you name it. As long as it has access to the underlying commandline runtime, which is in the PHP example to be done by exec().
But Java, actually Java EE, also provides a web application programming interface: the JSP/Servlet API, the web component of the large Java EE API. This make integration with the "commandline Java application" much more seamless. You can basically just put your application in the classpath and import/access/use it in a Servlet class the real Java way:
YourApplication app = new YourApplication();
Result result = app.doStuff();
// ...
To be able to run JSP/Servlet (JSP is at end actually also a Servlet), you need a concrete implementation of the Servlet API (the whole Java EE is just an abstract specification). Apache Tomcat is good to start with, the other popular alternative being Eclipse Jetty. Those are 'simple' servletcontainers which implements the Servlet API, with Jetty being a more embedded approach of it (you can configure and run it as a "plain vanilla" Java Application). But if you need to support/cover the other aspects of the Java EE API as well, then you need an application server, such as Sun Glassfish or JBoss AS (both which by the way uses Tomcat as the servletcontainer part).
To learn more about JSP/Servlet, I can recommend the Coreservlets.com tutorials.
Apache Tomcat should do good.
The standard concept for running code inside a web server is the "Servlet API" from Sun.
Essentially it provides a few interfaces which the web server uses to invoke your code, and defines how the web server should behave. This allows you to write very generic code that can run in a variety of web containers which implement the Servlet API. See the Wikipedia article for details - http://en.wikipedia.org/wiki/Java_Servlet.
They come in all sizes too, depending on your needs. Some small enough for embedding in your own application, some very big. The servlet API allows you not to care.
For a beginner, the quickest way to get up and running, is to download the full version of Netbeans which includes full support for doing this kind of work, and has a built in servlet container.
I'm hoping to create a Java SOAP server which I can deploy in Tomcat, or in JBoss, or in Geronimo, or in XYZ, etc. etc. etc.
Bottom line, it should have the least dependencies possible. I'm trying to avoid libraries outside of what's included in a standard java distro because of licensing/packaging/reusability issues.
Can any provide a link to where I should start looking, or some example code?
Java 1.6 introduced the possibility to create standard SOAP webservices with the standard JDK.
There are many examples on the web, for example http://weblogs.java.net/blog/2006/12/12/webservices-jdk-6
IDEs like NetBeans also call the necessary tools (apt) automatically which makes it very easy to get started.
However I did not research how well this will work across all available containers.
Apache Axis2 (http://ws.apache.org/axis2/) should provide what you're looking for, or JAX-WS (https://jax-ws.dev.java.net/) if you want more lightweight.
Wow.
http://www.w3.org/TR/soap/
There's the standard. You will be spending a lot of time on this project. You'll need to also check out the HTTP and XML specs to build those components.
Ignoring XFire and Axis2 is an very very expensive choice...
I recently used Metro 1.4 for this (an open source glassfish component) which implements the standard approach for web services.
Drop in the jars in a Java 5 web container, annotate your class and method with standard #tags, and let Metro do the rest.
I have been very pleased with performance in a Jetty container.
If you use Spring web service module you don't need Axis or XFire. I think it's a good way to go if you're already using Spring.