How to expose a C++ program as a Web Service?
Or is it a better idea to invoke C++ from Java and expose the resultant Java as a Web Service.
In any case, the C++ program should not undergo any changes.
Consume C++ program in Java WebService end point and expose java webservice
Use JNI to consume C++ program
Nice article from JavaWorld
Interestingly, webservices work on http protocol, which means that you can't "host" a webservice written in C++ without having an http server. Since each web server will have it's own mechanism of writing "hooks" or extensions, the next obvious question is which web server would you like to chose.
Let's say you want IIS on Windows. It's possible to use ISAPI extensions; so you need to know how to write one, which complies with web services standards. Or, alternatively, it's better to learn how to do it in C++ with Visual Studio, which will have lots of built-in stuff to help you get started.
In short, there is no "standard" way of exposing a web service in C++ and you have to be "platform" specific. Windows with IIS has one way of doing it. Apache Axis C++ has another.
You can try c-sevice-interface https://github.com/Taymindis/c-service-interface.
It create a C/C++ program as a service port and listening to NGINX fcgi.
This is a small bridge engine which can handle high load of request, any segfault will not break the engine, it will catch and free the thread, it is built on top NGINX, FCGI. You can setup the proxy, load balance, authentication via NGINX before reach to your interface.
The link shown as below is a wiki to Guide you how to startup from scratch.
https://github.com/Taymindis/backcurl/wiki/How-to-build-BackCurl-for-cpp-Android-development
Related
I am currently tasked to build some kind of healthcheck-application, which is later to be included in a jboss environment. But first things first. I need to access 3 different types of databases: MS SQL relational, TM1 and MS SQL Analysis Servies. While the first two seem to be manageable, I have encountered a problem trying to access Analysis Services through java. Most commonly, the olap4j library seems to be used, but this is based on the msmdpump.dll, tunneling the response through the IIS. We cannot use this approach, since the IIS is not in use and we do not have system access to the Analysis Services Server.
In short words: How to access Analysis Services in Java without using msmdpump.dll? We need to send simple querys in either MDX or XMLA. Both client and server are using Windows Server 2008 R2. The Analysis Services version is 2008 R2 as well. Analysis Services is provided to us as a service, we do not have access to the system itself.
It seems to be an option to use a powershell script to access Analysis Services and to call this script through java. But I would rather avoid this approach if there is a better option.
Thanks for any help!
I do not think you can avoid the msmdpump.dll in IIS if you want to call Analysis Services from Java.
The Analysis Services server itself uses SOAP structurally but a Microsoft specific binary SOAP format (see http://sqlblog.com/blogs/mosha/archive/2005/12/02/analysis-services-2005-protocol-xmla-over-tcp-ip.aspx for some details). This communication protocol is understood by the ADOMD.NET client driver and msmdpump.dll and nothing else. Thus you can can use write your application in .net or any language capable of interfacing with .net - or you can use any environment on the client that can send and receive http requests via msmdpump.dll hosted in IIS. Actually, msmdpump.dll does nothing else but a translation between TCP using binary compressed XML and http using uncompressed standard XML (and translating between the http authentication mechanisms and integrated security which also can be difficult to implement in Java).
As far as I am aware, Microsoft claims some rights on their binary protocol, so you may even violate their rights in case you would try to develop a tool yourself that directly talks to AS from Java.
Thus the only way to not use msmdpump.dll in IIS as a proxy between you Java application and the AS server would be to develop your own proxy in .net that would more or less implement what msmdpump.dll does already: translate between TCP using binary compressed XML and some other protocol that you define between your .net component and your Java component, probably just exchanging the XMLA request and the XML answer. Or you could implement a more high-level API between ADOMD.NET and your Java application. But there would be no way around some .net development in this case, which I would not think to be worth the effort and complexity.
2 month ago i started to develop an android application which needs to call remote methods and receive complex objects (custom objects with custom feilds in it) from a server.
My friend and I splitted the work so he worked on the android client and i on the server.
Before we started, we built the base interfaces which provide the functions that the client needs from the server, so my friend can program easly the application (by using fake classes as implementation for the interfaces), and after i finish the implemntations of the interfaces in the server-side he will make the connection and call the functions from the server and not from the fake classes.
Now the problem is that we can't find a way to pass those interfaces from the server to the client.
We tried to use java RMI, but we faild because android doesn't support java RMI,
then we tried to use JAX-WS (with tomcat 7) and we also faild because JAXB can't handle intefaces. (-you can see more details here about jaxb issue-)
My friend and I feel really lost.. we don't have any idea how to pass those interfaces between the server and the android client.
Is it possible what we're trying to do? if not,
what other options avaible for us to call remote methods and receive complex objects from the server?
Thanks!
You can expose webservices on the Server, so the client can interact with the server whenever its needed that might be quickest solution.
Or you can write a kind of servlet programming to get the json request from the client, process it and send the json respoonse back to the client. If the application is data intensive, the JSON helps you a lot
Not sure if this is too late now (after 2 months of development), but there are frameworks that should make RPC easier for you (take care of linking both ends). Two I know of are Apache Thrift (definitely usable with Android - there are apps that use it) or Apache Etch (possibly).
Apache Thrift:
http://thrift.apache.org/
Apache Etch:
http://incubator.apache.org/etch/
Blog about Evernote choice of Thrift:
http://blog.evernote.com/tech/2011/05/26/evernote-and-thrift/
If your application is limited to communication between Java on the server and Android (no other clients e.g. IOS) then an easier RPC path compared with IDL based solutions is to use jsonrpc. This solution provides both server and Android client components. It is extremely easy to implement on both client and server. One limitation is that byte arrays have to be encoded because the JSON transport does not support binary.
I don't think this is quite possible or if it is recommended to do... but is there a way to connect or comunicate or deploy Java and .NET application for method beside Web Services. I mean I understand there are Messaging server that allows Java application communicate to each other but I dont know if this can cross development environment, any suggestion about it or thoughts about this?
I'm limited to web and desktop environments.
Apache Thrift is a way to go. You will need to write a service definition like this:
serivce helloworld{
string sayHello(1:string name)
}
Thrift then will generate RPC interface with network layer already implemented, It support many others language such as Java, C#, PHP, Python. Thrift support binary protocol over TCP/IP, so it's very fast.
for more, go to its wiki page http://wiki.apache.org/thrift/
You can use something like Apache ActiveMQ which uses JMS on the Java side and the .NET Messaging API on the .NET side.
We ended up writing our own implementation of Java-.Net communication protocol based on Hessian (later added JSON as well), but Thrift is a valid option.
The virtual machines (JVM vs CLR) are not going to talk to each other except through some OS level open standard. Shared Files (yuck), Sockets and Web Services come to mind. There is nothing that would allow you to call a .net subroutine from java or vice-versa.
I need to connect my .Net application to somebody else's JMX agent. I've read that this is simply not the done thing and I should use soap or practically anything else. As this is just not going to happen, are there any libraries or interop techniques out there that can help me? I'm only interested in the simple things like invoking a remote operation or returning a string result.
.NET is really not the technology to use to talk to JMX. JMX is a builtin standard that is part of Java but is pretty specific to running in Java. I would assume that you cannot control the application you are trying to consume since you indicate you are trying to use someone else's JMX agent.
In that case, you might want to consider writing your application or part of it in Java. That is the best way to get access to the JMX. If that is not an option you do have a few things you could look into:
1) Check to see if the application you are connecting to can expose the data as something other than JMX. It is usually not hard to allow access via web services to the same data.
2) Write a small Java wrapper that talks to the JMX server and exposes web services. This allows you to query the web services which in turn go over JMX.
3) There are other agents that JMX has to allow it to talk with different technologies. You could use something like the SNMP agent and use SNMP traps from .NET. More information on that can be found here: http://java.sun.com/javase/6/docs/technotes/guides/management/snmp.html
If you start up an HtmlAdaptorServer - you could just use the URLs to invoke JMX methods using standard HTTP calls.
I've done this in the past from Perl as part of a system administration task. Its not pretty and its unmaintainable if the JMX interfaces are changing a lot. But.. if you need a quick and dirty hack - this is it!
The Web Services Connector for Java Management Extensions (JMX) Agents and the reference implementation ws-jmx-connector would be my choice. JSR 262 will provide a new opportunity for cross-platform/cross-language enterprise integration projects, but development unfortunately has slowed down.
It would only require some SOAP calls to invoke all operations of the JMX management interface, IIRC even including callbacks/notifications.
You can do this with IKVM. It is a Java Byte Code to .Net CLR compiler and works just fine with JMX.
Besides using Web Services, or POX (or custom HTTP), are there some other techniques that I could utilize for calling services exposed from WCF via ___________ to the Java world? These requests will be in the same machine. Maybe RAW TCP/IP?
I'm just inquiring for a project that we need to possible provide some method of calling synchronous code in the .NET world and return results to our Java world.
Thanks for suggestions.
To talk with a Java client you'll have to use one of the interoperable protocols which limits you to going across HTTP or HTTPS. TCP can only be used between clients running Windows on an intranet. Even on the same machine you won't be able to use Named Pipes either for the same reason.
The interoperable protocols are covered in Chapter 1 of "Programming WCF Services" by Juval Lowy.
You can try following project http://iiop-net.sourceforge.net/