I am working on an existing system written using .NET 2.0 remoting to integrate a number of embedded clients to a central server. Due to a number of issues, it has become desirable to rewrite the server in Java. Updating the clients is not really viable at this point; there are many of them and they are geographically scattered, so an update would be potentially expensive. To this end, I was wondering what solutions are available to implement a Java server that would be compatible with the existing over-the-wire protocol?
I am aware of JNBridgePro, but it is unfortunately too expensive for our current budget. I also have the CD from the book Microsoft® .NET and J2EE Interoperability Toolkit (Microsoft Press), which has a copy of a piece of software called "ja.net" from Intrinsyc Software that promises to fulfill this function, but in order to use it you need to obtain a licence from Intrinsyc and their web site is not responding (perhaps they have gone out of business since the book was published?).
Are there any others I'm not aware of?
No, no such thing (except custom commercial solutions).
However, if you are up to an in-house solution, you can:
Write your own .NET remoting adapter, which sits between the .NET clients and the Java server.
The .NET adapter translates the requests to something known by the Java server (maybe a web service interface, via SOAP) and the same for the responses.
So, the .NET adapter would be something like a pass-through and mapping component, with no actual logic. This way all logic can be in the Java server (which seems to be what you want).
It could take some time to do it, but it depends directly on the number of clients you have and on the number of types of requests and responses.
Related
Why does Java RMI exist? Who uses it and for what?
My most pressing questions;
Why would you want to make calls to methods that aren't defined on your machine? Wouldn't it take much longer to execute? I don't see how this makes the world a better place. Wouldn't it just be smarter to have many machines running the complete program rather than many machines each running parts?
Doesn't the fact that you have to manually provide interfaces to all the machines (clients and servers) kill whatever benefits having remote objects provides? In other words, if a benefit of having a remote object is that the client programmer doesn't have to interact with the server programmer, then doesn't it get annoying to have manually contact eachother to update the interfaces on both sides for each little change?
How is this similar or different to a typical web app set up where a client communicates with a server? In my mind, HTTP calls are much easier to understand. Can an RMI Server require some sort of password from RMI clients?
What kind of applications are typically made using Java RMI? Any hard examples?
Why does Java RMI exist?
Err, because Sun built it? The same Sun that provided Sun RPC.
Who uses it and for what?
RMI is the basis of Jakarta EE (formerly J2EE) just to name one small example. However the concept of remote method calls dates further back to at least CORBA, and the concept of remote procedure calls to at least the 1970s. Sun provided their implementation of RPC in about 1982 and it is the basis of NFS among other things.
Why would you want to make calls to methods that aren't defined on your machine?
Err, if you wanted them to run on another machine?
Wouldn't it take much longer to execute?
Of course.
I don't see how this makes the world a better place. Wouldn't it just be smarter to have many machines running the complete program rather than many machines each running parts?
So you've never heard of distributed computing, then?
Doesn't the fact that you have to manually provide interfaces to all the machines (clients and servers) kill whatever benefits having remote objects provides?
No.
In other words, if a benefit of having a remote object is that the client programmer doesn't have to interact with the server programmer
Did somebody say that was a benefit?
then doesn't it get annoying to have manually contact each other to update the interfaces on both sides for each little change?
There don't tend to be many 'little changes', if you actually design your system before implementing it. But that isn't the only development model anyway. You could have a third person developing the interface. Or the same person developing both sides. Or have the remote interface defined by a specification. Or ...
How is this similar or different to a typical web app set up where a client communicates with a server?
It uses RMI instead of HTTP.
In my mind, HTTP calls are much easier to understand.
You can't get much easier to understand than a remote interface, but obviously your mileage varies.
Can an RMI Server require some sort of password from RMI clients?
Yes, it can use mutually-authenticated TLS for example, or arbitrary authentication protocols implemented via custom socket factories.
We have what I think is a fairly typical client/server architecture, with a frontend written in .NET, displaying data sent from a backend written in Java.
Currently, we use a custom message-based framework for transmitting data snapshots and updates down to clients. This might be upgraded; although the basic java service/.net client setup is set in stone, we want to look at replacements for the message framework, for example WPF MVVM (with an eye on Sliverlight), with databindings to java web-services, or perhaps Coherence.
I was wondering what experiences others have had with this and other approaches (obviously there's no golden bullet for all situations...).
Our requirements are that the clients can show large, frequently updating and editable datasets, primarily in grids.
Update
I've accepted that REST/SOAP is the standard way to do it, but I'd still be interested to hear any other approaches, especially from a performance point of view.
Web services is the most common choice:
RESTful service - more flexible, no strictly defined schema
SOAP service - rigid schema, less flexible
Checkout protobuf, which is a good platform agnostic protocol.
I'm currently in the research phase for a (very) small database application.
It's for a local charity which only has 3 or 4 client machines which will be running the system - however in order to move some extraneous logic away from the clients, I'm leaning toward using a three-tier architecture (there is data that is constantly read-through and updated when appropriate, that the client does not need to know about)
i.e. Client <-> Server logic <-> Database
Whilst I'm competent with Java itself and a few frameworks/libraries, I'm not particularly familiar with what frameworks could help me here. Obviously I'll be using JDBC for the database half, but the communication between client and server is the stumbling block at the moment - I don't really want to go anywhere near raw sockets, for example (overkill, or at least, another solution must exist)
I've asked a few developers I know about their opinions on what APIs to use, and whilst they've been very helpful, I'm still not too sure where to go. So far I've heard about RESTful stuff, SOAP, COBRA and a whole bunch of other technologies. SOAP is the main one that caught my attention (as there are some good examples of using it with normal applications rather than just with the web) but I'm still not sure where to go - it doesn't seem particularly appropriate for a general purpose app like this one (EJB also popped up but I heard a lot of hatred aimed at it - is this deserved?)
It feels as if in order to find out the 'best tool for the job' I actually need to learn each one in its entirety to 'get' them (which is obviously impractical)
Can anyone give me guidance as to how to choose APIs like these (when I haven't used them before) or give me information about a few common ones, or is it really just a case of experimenting with lots of them to see which fits best?
Or maybe I've totally missed the mark and there's a framework which is aimed at this exact situation with no obvious cons?
Thanks very much for any help.
EDIT:
Completely forgot to mention what it actually does: It isn't terribly complex - the charity runs a transport scheme, so it holds details of drivers, clients, driver mileage records etc. for viewing and editing The only real complexity comes with the drives, since drivers can be assigned to repeating (ongoing) drives that could foreseeably continue 'forever'. But each instance of an ongoing drive must be unique because they can be cancelled or edited individually
The main reason I'm angling for 3-tier is because being a charity (with many older volunteer computer users who aren't terribly 'savvy') I may well be updating the UI quite frequently to iron out bugs and bits that aren't very clear to novice users. So my plan is to get the backend between the server and DB absolutely 'bulletproof' first of all, and then pour all my focus onto the UI so I can continue to develop and iterate it without worrying about the backend (also since I will be developing pieces of it remotely, focusing updates on client side is slightly simpler)
All these attributes probably shout out 'do a web based system' - the snag here is that they're after all kinds of tricky integration with some applications they already run, which I'm not confident I can get done (properly) with a web app.
For the server itself, you'll need some sort of JavaEE server.
Common implementations here are GlassFish (the reference implementation) and Apache Tomcat... assuming you don't need anything more advanced than a Servlet container. Chances are you won't if you're just using web services.
For the client, I assume you're going to have a GUI application, presumably that uses Swing or SWF. You could also opt to make a web application, since you're already going to have a web server involved.
For client to server communications, you could use a JAX-WS (SOAP web services) or JAX-RS (RESTful services) implementation.
JAX-WS implementations include Sun's Metro (which ships as part of Java 6 SE) or Apache CXF.
JAX-RS implementations include Jersey and Apache CXF.
As for the database layer, JDBC isn't your only choice. Java also has the Java Persistence API (JPA, currently at version 2.0).
JPA is usually used in J2EE apps (web apps specifically) to simplify the Database layer. Common implementations are EclipseLink JPA (obsoletes Oracle TopLink) and Hibernate's Annotations.
All of these are based on various standards that make up JavaEE: Servlet 2.5, JAX-WS 2.0, JAX-RS 1.1, and JPA 2.0.
EJB also popped up but I heard a lot
of hatred aimed at it - is this
deserved?
It was fully deserved with versions 1 and 2 of the EJB spec. But EJB v3 represents a huge simplification that makes them outright pleasant to use. I can actually in good conscience recommend using entity beans instead of manual JDBC.
As for communications protocol, exposing EJBs as REST or SOAP services is absurdly simple in the newest EJB 3.1 spec - all it takes is adding a few annotations and you're set!
Does anyone have a real-world experience in building such a project? I'd like to move away questions about "is it good idea or not", but focus on possible solutions. I see one simple way - HTTP GET/POST + xml/json - and one more elegant - AJAX/DWR. As for the first one - I understand that it is possible, but needs quite a lot coding. As for second way - is it possible to use Java DWR engine with PHP front-end? Is DWR language-independent for client side (as it uses just JavaScript)?
Would it be a problem, that client page was generated by one web server (for example, apache+php) and served on server-side by another (for example, tomcat)? I suspect, that Tomcat will complain about sessions. Can this problem be fixed with allowing cross-domain AJAX?
Thank you in advance.
Denis.
If what you want to do is (as I suspect) to use PHP to assemble your web pages while the "business logic" is written in Java, I would suggest using PHP/Java Bridge (LGPL and MIT licenses)
Both Java and PHP are server-side technologies. Your "front-end" will be written using HTML, CSS, and JavaScript - although you could certainly use PHP (or JSP) templates to render portions of the front-end.
If you are using PHP as the "front-end", then you would need it to act as a proxy, passing requests back to the Java web server.
I've worked on a project that uses a Java 'backend' and a mod_perl 'frontend'. For the naysayers, this is because the Java is providing service/API facilities, it's not and shouldn't be involved in dealing with UI, be they HTML, WAP, SMTP, SOAP, etc.
For historical reasons the mod_perl talks XML-RPC. It's not a route I'd recommend at this stage. Java, Perl and PHP can quite happily handle far more JSON type transactions due to lower encoding/decoding overhead. Also, in a mod_perl (though not PHP) environment it's possible to run JSON-RPC easily over a persistent connection, reducing the overhead even further.
There are plenty of benefits to this approach, including separate upgrades to the various UIs, stability of the service layer, and distinct responsibilities for each layer.
Downsides include delays getting service improvements live, more complicated development, staging and test environments, a taller barrier to entry for new developers, more documentation and management.
For the "Java front to back" guys, this is a similar type approach to using an OSGi container, only using more domain suitable languages; Java for heavy lifting, scripts for more fluid, text based interfaces.
I have a bunch of Java code which was written using the Hibernate framework, originally destined to have a front end written using JSPs. However, the requirements for the front end have changed, and we've decided that a desktop client (which will be written in .NET) is a better match for our users.
I don't really want to waste the code that's already been written - can anybody suggest a good set of tools for writing a document-based web services interface that we will be able to access from .NET?
Thanks,
Jim
If you truly want a document based service interface (rather than an RPC style web service architecture), your best bet is going to be creating a SOAP based web service interface.
A quick glance at the Java site shows that the Metro stack might help a bit:
Java Web Services at a Glance
We're developing an application with the exact architecture you describe for a finance application. We reviewed several different options, and have finally landed on using compressed CSV over HTTP.
CSV was chosen since the vast majority of data was going to be displayed in a grid on the front end, we had very large result sets >250k rows on a regular basis, and it compresses really really well.
We also looked at using:
ICE, but declined on that due to licensing costs and the need to reinvent so much.
Google's protocol buffers via servlets, but declined on that due to lack of C# support (as of last fall).
Compressed XML using WOX, but declined on that due to lock-in to a small thesis project for support and XML being too verbose.
The industry supports a couple of different options as well:
SOAP, but that has its own well documented issues.
IIOP, J-Integra has a product called Espresso which will allow you to do RMI from a front end.
I'd personally use some lightweight RPC protocol, be it XML-RPC or a homegrown one. SOAP, IMO, is way too fat and is not as interoperable as it's supposed to be. The simpler the better.
We have a quite large application using a Java RMI server and IIOP.NET for interoperability. We have used IIOP.NET with the Sun RMI and the Bea Weblogic (now Oracle) without major issues.