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.
Related
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
We are developing a service for our portal / web client developed using JSF . My advice was to expose the service as REST but another team member said to go with RMI implementation since its easier to deal in java object from development and testing point of view.
My argument was development and testing efforts with be pretty much the same but we will get all the goodness of REST web services.
FYI : We already have REST setup so there is no extra cost in framework support. This services are exposed for our smartphone client who uses REST api.
At the end our Manager decided to go with RMI way but I still think REST would be smarter way.
What would be your choice REST or RMI?
Note : Nothing against my team member or Manager just trying to learn here.
If there are firewalls between your client and server, it is likely that RMI traffic might be blocked. HTTP traffic is open on most firewalls and REST should have no problem getting through.
The biggest argument against RMI and for REST/SOAP etc is that the client does not have to be Java.
If your front-end could change down the road from JSF to ASP, then you'll be in some trouble.
Other than that, RMI is the way to go. An even better way to go is EJB ( which is a layer on top of RMI ) with additional advantages -- lots of vendors already implement the EJB spec, you get the advantages of object pooling, transaction management etc.
Is the client in Java, use RMI. But that is to simple thought. As it is only a point to point protocol.
REST as a paradigm is interesting if you have e.g. many reads and like to use HTTP technologies for caching etc. The next thing is you likely can easy implement "paging cursors" so you send data as a small page and add info how to retrieve the next page.
Your question basically is formulated as if it is a technology question. Which is the wrong approach. You should not bother about technology but about system architecture. The whole software system, its abilities, its performance, its scaling, its configuration and its maintenance is completely different depending on your usage of RMI or REST.
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
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'm in the process of writing a client/server application which should work message based. I would like re-use as much as possible instead of writing another implementation and curious what others are using.
Features the library should offer:
client and server side functionality
should work message based
support multi-threading
should work behind load balancer / firewalls
I did several tests with HTTPCore, but the bottom line is that one has to implement both client and server, only the transport layer would be covered. RMI is not an option either due to the network related requirements.
Any ideas are highly appreciated.
Details
My idea is to implement a client/server wrapper which handles the client communication (including user/password validation) and writes incoming requests to a JMS queue:
#1 User --> Wrapper (Check for user/password) --> JMS --> "Server"
#2 User polls Wrapper which polls JMS
Separate processes will handle the requests and can reply via wrapper to the clients. I'd like to use JMS because:
it handles persistence quite well
load balancing - it's easy to handle peaks by adding additional servers as consumer
JMSTimeToLive comes in handy too
Unfortunately I don't see a way to use JMS on it's own, because clients should only have access to their messages and the setup of different users on JMS side doesn't sound feasible either.
Well, HTTP is probably the best supported in terms of client and server code implementing it - but it may well be completely inappropriate based on your requirements. We'll need to actually see some requirements (or at least a vague idea of what the application is like) before we can really advise you properly.
RMI works nicely for us. There are limitations, such as not being able to call back to the client unless you can connect directly to that computer (does not work if client is behind a firewall). You can also easily wrap your communication in SSL or tunnel it over HTTP which can be wrapped in SSL.
If you do end up using this remember to always set the serial version of a class that is distributed to the client. You can set it to 1L when you create it, or if the client already has the class use serialver.exe to discover the existing class's serial. Otherwise as soon as you change or add a public method or variable compatibility with existing clients will break.
static final long serialVersionUID = 1L
EDIT: Each RMI request that comes into the server gets its own thread. You don't have to handle this yourself.
EDIT: I think some details were added later in the question. You can tunnel RMI over HTTP, then you could use a load balancer with it.
I've recently started playing with Hessian and it shows a lot of promise. It natively uses HTTP which makes it simpler than RMI over HTTP and it's a binary protocol which means it's faster than all the XML-based protocols. It's very easy to get Hessian going. I recently did this by embedding Jetty in our app, configuring the Hessian Servlet and making it implement our API interface. The great thing about Hessian is it's simplicity... nothing like JMS or RMI over HTTP. There are also libraries for Hessian in other languages.
I'd say the best-supported, if not best-implemented, client/server communications package for Java is Sun's RMI (Remote Method Invocation). It's included with the standard Java class library, and gets the job done, even if it's not the fastest option out there. And, of course, it's supported by Sun. I implemented a turn-based gaming framework with it several years ago, and it was quite stable.
It is difficult to make a suggestion based on the information given but possibly the use of TemporaryQueues e.g. dynamically created PTP destinations on a per client basis might fit the problem?
Here is a reasonable overview.
Did you tried RMI or CORBA? With both of them you can distribute your logic and create Sessions
Use Spring....Then pick and choose the protocol.
We're standardizing on Adobe's AMF as we're using Adobe Flex/AIR in the client-tier and Java6/Tomcat6/BlazeDS/Spring-Framework2.5/iBATIS2.3.4/ActiveMQ-JMS5.2 in our middle-tier stack (Oracle 10g back-end).
Because we're standardizing on Flex client-side development, AMF and BlazeDS (now better coupled to Spring thanks to Adobe and SpringSource cooperating on the integration), are the most efficient and convenient means we can employ to interact with the server-side.
We also heavily build on JMS messaging in the data center - BlazeDS enables us to bridge our Flex clients as JMS topic subscribers. That is extremely powerful and effective.
Our Flex .swf and Java .class code is bundled into the same .jar file for deployment. That way the correct version of the client code will be deployed to interact with the corresponding middle-tier java code that will process client service calls (or messaging operations). That has always been a bane of client-server computing - making sure the correct versions of the respective tiers are hooked up to each other. We've effectively solved that age-old problem with our particular approach to packaging and deployment.
All of our client-server interactions work over HTTP/HTTPS ports 80 and 443. Even the server-side messaging push we do with BlazeDS bridged to our ActiveMQ JMS message broker.