Interoperability without the network : JNI, .NET & DLLs
By Daniel Rubio
[Posted by J.Vaughan]
A non-networked application may seem unthinkable in this day in age, but its often designed in this manner to satisfy everything from infrastructure limitations to thwart security breaches, in the context of .NET and Java interoperability, there are a series of considerations to take into account for achieving such cross-platform communication, some of which we will explore in this last entry on interoperability without web services.
The first and obvious characteristic in this type of scenario is that communication is devoid of any common protocol between platforms such as HTTP for web apps or IIOP for CORBA which implies communication is established directly tapping Java or .NET classes that are managed by either a JVM(”Java Virtual Machine”) or CLR(”Common Language Runtime”), respectively.
The biggest hurdle in each of these cases, is that both a JVM and CLR interpret instructions in different form, in Javas case as byte-code(.class files) and in .NETs case as MSIL code(.dll files). Here once again, before proceeding I should mention there are numerous commercial offerings and other open source projects like Caffeine which offer distinct approaches to solving this particular problem, so as in the previous interoperability entries, this is just but one possibility that doesnt require third party tools, albeit one which might be considered a “long-route” by many.
Our interoperability scenario will involve invoking compiled .NET logic from a Java environment. In Javas case, the language along with its development kit is equipped with the necessary tools to execute non-Java code via JNI(Java Native Interface), however, in the particular of .NET DLLs there is a certain twist you should be aware of, from a Java standpoint compiled .NET code in either of its implementing languages C, VB.NET C++.NET is not considered native but rather managed code.
The advent of .NET has eliminated many of the issues related to native code such as memory management but this same insulation has in itself created an additional barrier to invoke this type of code from lower level interfaces available in other programming languages, and for which JNI was designed, so in other words, Java JNI cannot just call any function in any .dll, as many JNI tutorials lead to believe.
The solution to communicate with .NET DLLs from Java JNI then is to establish communication via a native DLL wrapper also known as non-managed code. So lets start with our .NET code, which is illustrated in Listing 1.1
Simple enough, now lets illustrate the non-managed C++ wrapper for this .NET class
The wrapper makes use of mscorelib.dll which is central to the .NET runtime, and JavaNetInterop.netmodule which is a compiled structure created from the .NET class similar to an assembly as would be JavaNetInterop.dll the rest is compromised by C++ wrapping.
Armed with the C++ wrapper, we would then need to create a header file C++ speak using Javas javah utility, which would later be used for creating our JNI implementation illustrated in Listing 1.3
The top most declarations are used for accessing JNIs header file, the C++ header file and non-managed C++ file, respectively, while the method is used for invoking the wrapping C++ logic. Finally, our last step would be creating a Java calling class that would look something like the following listing :
In this last snippet we make use of the native keyword to indicate we are dealing with a non-Java method, the System.loadLibrary declaration to load the JavaNet dll corresponding to the compiled non-managed C++ wrapper and a main method which creates an object instance while invoking the native method interopLogicMethod.
Though the process is somewhat elaborate, it will nevertheless allow you to call .NET logic from a Java environment. With this we come to a conclusion on our four part series dedicated to exploring non web-services technologies for Java and .NET interoperability. The next time you are faced with a project involving interoperability issues, be sure to give these alternatives a closer look, especially if your organization is still tied-up deciding when,where and if web services should be used.
June 12th, 2007 at 7:41 pm
- Java to XML mapping for a recursive structure is tricky. But this is true no matter whether you use SOAP or REST.
The problem is left unresolved.
- Using a SOAP (and potentially ) wrapper around your XML payload really doesn’t make it “un-RESTFul” and might make things easier for you when you are dealing with some of the problems being addressed by WS-* standards.
Check.
- Assuming HTTP as a transport, something that is usually done when dealing with a REST type service, can be problematic, specially when you need
feature not provided by this transport such as offline capabilities or recovery.
Check.
- It is sometimes not realistic to expect that the complete state of the conversation is always carried within the payload itself. An assumption made by a RESTful approach.
Check
The one thing the conversation does not seem to address is the way the operation, and its affected resources are specified within a request message. With a SOAP based service this is usually done through extra elements within the SOAP body. In what I have seen to be called a RESTful approach however, the operation is specified through the HTTP GET, PUT, etc… and the resource is identified as part of the URI. It is arguable that the latter approach makes things simpler on the client side. However, this approach could of course also be used with a message that is wrapped around a SOAP envelope.
June 13th, 2007 at 2:37 pm
I think that the main problem with all these discussions around SOAP/REST/POX is that they almost always mixes protocol-related issues - HTTP header vs SOAP header for example - with architecture-related issues - ROA vs SOA vs RPC (poor-man distributed objects).
This dialog was not the case, but most blogs and critics I see are.
June 17th, 2007 at 3:14 pm
From a REST point of view, this discussion is so misguided it hurts.
June 19th, 2007 at 4:37 pm
Stefan,
I’m intrigued. While I do enjoy being intrigued, I hate being misguided
Care to elaborate on your statement?
Thanks,
Ade
June 21st, 2007 at 7:41 pm
Ten points.
1. POX vs. SOAP has nothing to do with arguments in favour of REST. Sorry guys, I don’t know why people keep coming back to this. The whole point is about pervasive, consistent naming of all interesting resources through URIs.
2. Even further, REST has nothing to do with XML. How about other media types? JSON? Images? CSV? Movies?
To compare, SOAP services tend to force using the WS-I Attachments Profile, or MTOM, or Base64 embedding. Interop is problematic — I discovered bugs with WS-I attachments several months back (which, thankfully are being fixed in the spec).
3. Fielding never argued for a small number of verbs in his thesis. Yes, the REST community early on got stuck on this noun vs. verb thing, but it’s never been the real point of it.
It doesn’t matter if a uniform interface has 5 verbs or 5000, just that every component understands the semantics of them, and that the hypermedia type provides the context as to which one should be used. Naturally, fewer is more maintainable and general, but an example (in my opinion) of a parallel RESTful system to the HTTP web, with a different set of verbs for a different set of applications, is the IP multimedia subsystem (IMS) based on SIP.
It would have been more interoperable if they just extended HTTP, but it’s also politically understandable why they started with their own set of methods, and they still stuck in many ways with the spirit of a RESTful architectural style, while changing it to their perceived needs.
4. “Problem is, REST assumes that you want to carry all of the state in the payload itself”
That would be communication state. You know, like the same assumption in almost every successful scalable distributed system for the past 15+ years? COM+ was stateless, EJB stateless session beans were somewhat popular I hear, and hey, even SOAP web services are stateless.
5. “So all those people arguing REST for enterprise systems are basically arguing something they don’t understand”.
I don’t get this sort of comment. Many people in the REST community *very clearly* understand enterprise systems. And enterprise systems, going back to CICS, have very often eschewed the notion of “session” as unreliable and unscalable. This is not to say that transient data cannot be managed. It’s just that the systems-level architecture should treat it like any other data.
Cookies and Session IDs don’t break REST, by the way, they’re just something that defeats visibility, as intermediaries have no idea what a cookie implies. This can wreak havoc on HTTP proxy and gateway caching. On the other hand, some have found creative ways to balance concerns (e.g. Amazon.com’s use of session IDs).
6. “REST is a good architectural style. We just need to recognize that we’re not always exchanging hypermedia documents.”
What I don’t understand is why passing a SOAP document with lots of embedded context-dependent identifiers, like primary keys, or even WS-Addressing EPRs, is somehow looser coupled and more maintainable than passing one with URIs.
7. SOAP can be used RESTfully, the problem is that few actually use it this way.
8. Transfer protocol independence is a myth. Note I said “transfer”, not “transport”. TCP and UDP are transports. HTTP, FTP, SMTP, POP/IMAP, and even JMS are transfer protcools, with explicit or implicit application semantics in their available message exchange patterns. SOAP can’t trample over these semantics without clear bindings, and the only binding that the W3C has recommended is SOAP over HTTP.
From another angle, if transfer protocols are unnecessary, why isn’t the enterprise systems protocol of the future WS-RM over TCP?
10. Even WS-* uses the web’s semantics implicitly for service discovery every time they GET a WSDL through a “?WSDL” url query string. This continues to be way more popular than UDDI. Why?
June 25th, 2007 at 10:03 am
A good RESTful application does not consist of monolithic documents being shuffled back and forth each time state changes. The infinitely recursing person document above is idiotic, and even a first-year computer science student could probably come up with some other way to solve it (pointers, anyone?)
As near as I can tell, the big difference between RESTful people and SOAPy people is that RESTful people tend to think about data and SOAPy people tend to think about behaviors. For your consideration, here is how a well designed RESTful person service would look:
URI: www.myservice.com/people
Jay
Libby
URI: www.myservice.com/people/Jay
Jay
Libby
URI: www.myservice.com/people/Libby
Libby
Jay
The “interface” in this case is so simple, you could barely justify writing a specification for it. If you did, it would look something like:
“To find out everything you need/want/are allowed to know about person X, go to www.myservice.com/people/X.”
And since these documents would obviously be dynamically generated from a database, you can use the requesting user agent information to deliver the data in an appropriate format (HTML, XML, VCF, etc.)
So, try POX, it’s contagious! (ouch)
June 27th, 2007 at 8:53 pm
I like that last comparison. SOAPy people do think in RPC, period. Architects and Service people do think in behavior and also in functionality. The way the message is delivered should not be worth the time to develop.
Problem is to develop a Service you spend so much time in constructing the XML, parsing, communicating with the other developer to agree on the schema, not good. With REST you can construct not only services, but a myriad of other things. SOAP can be used Restfully and even WSDL may be used too to describe schema, operations and ports. They are not antagonistic. I mean, Document/Style SOAP, RPC is impossible, and unnatural, and not a service.