We have an application written in C language which interacts with Oracle database. This application is an executable and runs on unix platform. We need to expose this application over http as web service for others to consume.
I thought of using JNI and CXF for webservice and run the application in tomcat.
Is this a right solution or there are other possibilities?
I found Axis2 supporting C language to write webservice. I have no experience of C language. Is Axis2 in C is good? What http server I can use to deploy the app? Would Apache webserver siffice in this case?
EDIT: The command line is not an option as though I mentioned its an exe but the part which I have to expose don't have any command line available and its bit hard as it needs complicated data structure as input.
It depends on a few factors. Vinko's method requires the app has a good clean command-line interface. Further, creating a new process for every webservice request will limit the number of requests that can be serviced. This may or may not be okay depending on how big the audience is expected to be.
If there's not that great a command-line interface and you want to maximize the number of requests you can serve, that then leaves you two main choices. Write the web service in Java, and call out to C with JNI or JNA. Or, write it in pure C or C++. The last is probably not advisable if the responsible developers don't know any C.
EDIT: Given that command-line is not an option, I recommend Java with JNI or JNA.
Consider using the Apache Foundation package Axis2/C. It is a pretty solid interface, though it still has slightly limited portability (works out of the box on Linux, but not on Solaris, for example - needs some tweaks).
However, since you say you don't have the experience in C, that may make it too daunting for you. On the other hand, you say the code you're trying to convert to a web service is in C (plus perhaps Oracle OCI); that means that you are going to find it hard to avoid learning some C to get things working.
After using Axis2/C on the server-side for more than two years, I strongly NOT recommend using Axis2/C for any server-side code for the following reasons:
It is full of memory leaks. Namely, service code generated from WSDL leaks, simple HTTP server leaks, CGI module leaks (which is not a problem if you use it as a basic CGI, but a major problem if you use it from FastCGI or similar, or reuse the code). The only part of the HTTP-server code in Axis2/C I didn't check so far is mod_axis2 module for Apache2. Maybe it's better.
Axis2/C doesn't have any HTTP server implementation that you could embed easily in your C app: the "simple HTTP server" leaks and it doesn't support HTTP keep-alives (closes connection after every request). I had to implement a server myself based on boost::asio HTTP server examples and Axis2/C CGI module. Spent 1 day on implementation and 4 days to remove all the memory leaks. This proportion seems standard for any Axis2/C-related work. Do you want to spend days and nights with valgrind, debugging memory leaks and double-free's?
Most important, the project is NOT actively maintained: there are a lot of issues with patches in their JIRA, but it takes months and years to review and apply the patches. I doubt if any serious project uses it for server-side. My plan in a long-term is to clone it into GIT and maintain the patched version on github (I have to support the code already implemented with Axis2/C for years).
P.S. in my next web-services related subproject I will use JNI to embed Jetty + CXF.
Related
We would be in near future implementing a solution to modernize our iSeries applications
written as RPG programs with some stored procedures, and our preferred way is leveraging the latest and greatest of what Java has to offer in this space.
From googling and checking other questions here on STOVFlow, JTOpen seems to be the defacto
library/toolset which has worked for most and I was encouraged to see that Tomcat runs on an I-series box with out any issues.
With this as the background, I am thinking of the following as the high level sol arch
Install IBM JRE and use JTOpen's capabilities to invoke RPG Programs and in some cases directly call the stored procedures running on DB2
Have Tomcat host a modern web application built using Grails and other frameworks (Camel, Smooks) to provide an application logic layer which would fill any mediations, transformations required for the old functionality to be offered to the user from a browser
Questions-
If any one of you has been involved in such an exercise, please share the pitfalls with this approach
Is there a significant performance drop with respect to response times for the end user?
Would it be better to some how expose the JT400 code as web services and run the web app on a different machine altogether consuming these web services?
Be very careful with calling RPG from Java because RPG is not threadsafe without some changes.
When I was at COMMON, the best product I felt on the market was Profound UI. There are several others from a variety of vendors. Most of these products do not use Java. Java on the i tends to be slow. (There are things that can be done to make it faster, but native is always faster.) You'll pay the price for these products, but just imagine how much time it would take you to do this yourself. For the above, I was quoted in the $20+ thousand range. But like all i products prices vary greatly based on system.
To directly answer your questions:
I have been doing research on modernization as time allows, the products weren't quite there yet (at the time I looked) to use it for what we wanted to use it for (before COMMON 2011). Now it looks like it might work.
This really depends on your system. A newer system will have less problems than an older system. Web will always be slower than the green-screen. Hands-down entry people won't like it. Executives and younger people will love it.
Your slow point is running the business logic. It wouldn't matter which server the HTML is coming from.
I've found that for all practical purposes an AS/400 behaves like an AIX box seen from Java code, and you must use jt400 (jtOpen) to communicate with the AS/400 specific features like data queues, files etc. This works pretty well, but the slowness of invoking the JVM pressures Java based solutions to be long running.
Note also that QTEMP is generally unavailable as a mechanism to keep state due to the nature of prestarted jobs.
Under V6R1 Java 6 is available and runs pretty well in the "new technology" edition. You can then run almost all Java based solutions, including web servers like Jetty in it. Note that Java defaults to code page 819 when accessing IFS files directly. Windows clients using AS/400 as a network drive uses a compatible code page.
I created a command line interface on a small java application I created for personal use.
For the moment the cli is resided in the same project as the original application but I'm planning to extract it into it's own project, effectively building 2 separate executable jars enabling me to start the cli as needed and query the other running program for information.
I'm trying to figure out the easiest and most lightweight solution to call a remote service, on the same machine.
I looked at spring remoting but many of the provided solutions such as HttpInvoker, Hessian/Burlap, JAX RPC web services are based on HTTP or SOAP and therefore not suited for the job.
JMS also seems like overkill.
This leaves me with RMI, which looks rather heavyweight, and possibly JMX?
Suggestions?
JMX would use RMI underneath for remote access. JMX is meant for exposing admin apis (monitoring / management) - not intended as a general purpose remoting api.
RMI with the spring remoting support is fairly lightweight from a development point of view. Even runtime it is the option that adds least overhead compared to the other options you have listed.
Also with spring remoting support you can easily switch over to a different option if required later.
Take a look at this artcile, that compares / benchmarks performance of the above options.
I'd say it depends very much on where the project/functionality is heading. JMX is easy enough to set up, and you can make use of existing clients/guis to query and set parameters - this may save you a lot of work. It may also allow you system to integrate with monitoring tools out there.
If, on the other hand, the functionality has little to do with managment/monitoring, and more along the lines of pumping data in and out, one option may be Apache MINA. I've used it in the past with great results. But you'll effectively be creating your own protocol ! I doubt that MINA will end up being "less heavyweight" than simple RMI though.
In an app for personal use, I'd go with JMX because it should be the path of least resistance. I've had great experiences with this in the past. You'll be able to get it up and running in minutes, and you won't have to think about what message format to move data in (as long as your beans are Serializable, that is).
Put an interface in front of the remote call, so that later you can drop in another implementation later if JMX turns out to be inadequate.
I am getting into an existing project which implies lots of remote objects communicating together to compute and transfer data.
My goal is to create a web application allowing enduser to input some data and get the results after treatment through the existing distributed application.
Regarding that, I looked for a way to make calls to existing Java objects with PHP, but in most of cases it was about how to create a JVM and instanciate objects directly in PHP, but not accessing to an existing and running JVM.
So, what could be the better way to do that ? I also heard about creating a servlet, but I have no real knowledge about this for the moment, so I am sending a S.O.S in a bottle to the StackOverflow community, hoping someone (and I am sure there is) would have a good answer to that problem :-)
Thank you for your time !
You need to modify the java application. You have to add some kind of remote interface to that app, which can then be used by PHP. If you are inexperienced in java, you're out of luck.
One of the options described above is the servlet, which basically means exposing your java app through a REST or SOAP interface. That may or may not be the simplest solution, depending on your java app. If it is a webapp, you're in luck. You can try using JAX-WS to do that. The downside is that such communication comes with an overhead. If your java app is a command line program, you could use an embedded servlet container such as Jetty or try using WSpublish (built into java 6).
You can give Hessian a try. It is a binary web service protocol that supports both PHP and java. I have used it extensively on java-only environments, but it may work in php-java scenario as well. http://hessian.caucho.com/
As you can see, there are plenty of options, but all of them require knowledge and experience in JAVA and cannot be described in one sentence or two.
The easiest java WS example I have seen can be found here:
http://java.dzone.com/articles/jax-ws-hello-world?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+javalobby/frontpage+(Javalobby+/+Java+Zone)
maybe you could try the PHP/Java Bridge project : http://php-java-bridge.sourceforge.net/pjb/
There's one door into a running java virtual machine: the java management extensions. The door has to be unlocked from the inside, so the application has to offer some managed beans and the jvm has to be started with some parameters.
But once this is setup up properly, then you have an open port where you can read and set data from/on instances or execute methods.
I can't tell exactly how difficult it is to use this connection to the jvm from "other languages", maybe you just have to be able to emulate javas object serialization with php. But it might be offer a solution for your actual problem.
I'm trying to write a program in Scala, that will accept SOAP-requests, get the response from the real server (or read it from the local disc) and return the data to the original client.
I'm new to the java/scala ecosystem, so I have no clue, what libraries to choose.
I heard Scala's XML-handling is quite nice, so I don't know, whether I should use some enterprisey soap-library/framework like jax-ws, jboss-ws, axis, cxf, xmlbeans, etc.
Basically, I just need
a library, that accepts the requests (currently, I'm looking at jetty, but I'd prefer something that natively supports actors. scala-http seems to cover that, but isn't production-ready or maintained, for that matter)
some library to request the data from the other server (something like curl, libwww-perl for java/scala)
a build system (ant? sbt?)
an IDE (I'm used to eclipse, but IntelliJ's scala support is supposed to be better)
a tool to test it (currently, I'm using SoapUI)
SOAP is truly a hideous specification, with lots of potential for unusual fringe behaviour. While it's true that XML support in Scala would help you write such a library from scratch, it would still be a major effort (depending on how much of the spec you need).
Likewise, Jetty has years of development behind it; dealing with performance demands and other unexpected behaviour that you probably haven't considered... Even Scala's best-known web framework, Lift, runs atop a Java web server for these very reasons. It still works very happily with actors.
So, at this moment in time, you're almost certainly better off using a tried and tested solution with a Java web server and an off-the-shelf Java SOAP Library. The effort to add a thin Scala wrapper around these will be far less than the effort to build these things from scratch.
For the build system, sbt is the most powerful tool presently available for Scala, but you may need to fall back to Maven if this is needed for code generation by your chosen SOAP library.
Finally, for the choice of editor. If you're happy using Emacs, then the Ensime plugin is just amazing. If a more conventional Java IDE is to your liking, then IntelliJ currently seems to be the most stable option, though be aware that this could change very quickly.
Just a partial answer.
Look at:
HttpClient for making HTTP requests
Build system, if you have no prior experience with ant I would recommend sbt
For the IDE, I had good success with IntelliJ a few months ago. I believe Eclipse has improved but I don't know how much.
SoapUI would still work perfectly
Proxy servers are a classic use case for asynchronous/non-blocking IO. If I were embarking on this project, I'd start by taking a long look at Netty's HTTP support and build a simple reverse proxy (i.e. forwards front-end requests to backend servers, and backend responses to frontend clients) first before moving on to protocol translation.
When it comes time to work on protocol translation, you'll incur the wrath of XML parsers. Unfortunately, to my knowledge there isn't a good, high-performance, low-footprint parser that natively handles asynchronous IO; quite a few of them probably exist but are embedded in commercial products. See this thread for more information.
However, you can "cheat", at the cost of additional thread use, by using a SAX parser, which typically relies on blocking IO, to consume the output of a "push-me-pull-you" pipeline. Since the HTTP parts of your server are non-blocking, you can probably afford to use a few dozen threads just for shoveling bytes around.
As it happens, I've been there, and done that. :)
We're come across a problem here at my company and I'm trying to find the best solution.
Software was recently purchased that utilizes a Java program to get the tax for a certain shipment. The site that needs this was written in PHP4. How can I communicate between the two?
It was suggested to use files to communicate but that was horribly slow since the Java program needed to be recompiled every time. So, what is the best solutions to this:
Create a mutli-threaded Java server and use PHP to send/receive the info.
Some other type of file-writing method
Something cool that I dont even know about.
Thanks in advance!
Edit:
I understand the importance of web services but why would this be more efficient that using a mutli-threaded socket-based java server? The only thing connecting to this web services will be my PHP program, no one else. It seems like it might be overkill for my simple task. Am I mistaken? If so, why? Thanks.
Wrap the Java program in a Web Service, and invoke it from PHP. You can even use caching in the Web Service, to optimize performance.
Why not dump the info into a database and have some sort of schedualed job read from it once and a while?
You can always use Quercus which allows you to run PHP in a Tomcat Servlet container.
Web Services is the elegant solution. But in many cases I found much practical to go for a quick-and-dirty solution: start a Java server that communicates using a lightweight communication protocol (none of the heavyweight stuff like XML from Web Services) - example: Apache Thrift. The write a very light client, that takes parameters from command line and writes the output to the console. The client can be in Java or even in other languages, like C++ (Apache Thrift supports that). Then you call the client with system() or with exec() from PHP.
This is not a solution I would ever recommend for production, but it's great for prototyping. Quick and dirty and flexible and extremely modest learning curve (if you already use light-weight communication between your Java processes).
Since you are using PHP4, you may want to just set up a tomcat server that is on a closed network, or just local on the machine of interest, and have it communicate with a servlet, that way you don't have to write a multi-threaded server and deal with creating a communication interface.
If you can upgrade, this page has two other options that may of interest:
http://us3.php.net/manual/en/intro.java.php
Give a look at Quercus
Quercus is Caucho Technology's fast, open-source, 100% Java implementation of the PHP language
I never used it though,
Web Services is the answer. Here's a nice intro link. Your problem is the very reason web services came to the forefront - communication between systems that couldn't ordinarily communicate.
What a web service is essentially going to do is send XML between the PHP and the Java systems. You're going to have to establish an interface for the two, which might be more difficult at the upstart, but you'll reap the benefits later on. In either case, it will be much faster than reading and writing files on the server. Disk I/O are the major bottlenecks on any server.
I may miss something, but if your java program output the needed values, can't you just start the java program from php using exec (http://dk.php.net/manual/en/function.exec.php)
Use the PHP/Java Bridge from sourceforge.net. It is mature, fast and easy to install.