I’ve realized one thing – there are so many technologies, using which developers can build applications and solve real world problems. These technologies include Microsoft’s .NET, Sun’s J2EE, Adobe’s Action Script based technologies like Flash, Director and even there are some age-old technologies like C++, COBOL, Pascal, etc…
But frequently, in this day and age applications are developed using .NET and J2EE. Rather, there are already so many applications in the market – which are developed using these technologies. And for sure – these technologies are going to be there to solve many problems like – platform independency, language interoperability, data consistency and what not.
Unfortunately this situation makes developers life frenzied. Because, some applications like Payroll Management are written in J2EE and are working fine whilst Leave Management application, which is working superb was developed using .NET Framework. Now both, J2EE and .NET have different features set, different data-types and to make it more complicated – different working runtime with totally different internals. So, how these applications could ever interact with each other?
Well, there are some methods, using which these applications can talk to each other. And these methods have their own pros and cons as well. So, let’s see these methods one by one.
1. Using common storage methodology:
This is the easiest way to communicate between J2EE & .NET. Both technologies can talk to database using JDBC and ADO.NET technology. So, let’s have one database, which will store data, which is common to both of these technologies. So, whenever there will be any changes to this data, J2EE and .NET will work accordingly. But there are disadvantages as well. Every now and then, J2EE/.NET application will need to check the database for changes, making both applications sluggish. Plus, it will involve writing large number of lines of code – just to manipulate that data, rather than working on core business logic.
2. Using Inter Process (In-Proc) Communication methodology:
This is the most complicated method ever to communicate between two applications written in J2EE & .NET. In this case, one can ‘host’ the JVM and CLR into one common process. But it’s not that simple as it seems. By this way, one will have to load JVM.dll and mscoree.dll into a single process – which is a complex task to do. This can be achieved by C++ functions like CreateProcess() and LoadLibrary(). But, once it is done, developers can use Java Native Interfaces and .NET Interop for communication and for allowing code access from each other.
So, far it looks pretty challenging, but interesting scenario to bridge the communication channel between these technologies. However, both of these technologies have different standards and set of libraries.
But luckily, one more way is there to interop between these technologies, which has been standardized by many vendors – to save life of developers XML Web Services.
Both J2EE and .NET have their own implementations of Web Services. But ultimately, these web services use SOAP standards and XML to communicate with each other. XML being open (as in not a proprietary of any vendor), text based and easy to cross firewalls – is most preferred. Here, it’s not about XML being used as user defined tags OR to store data. But it’s about transferring data from one part of the world to another, i.e. from J2EE to .NET and vice versa.
To this point, these methods are here to solve the problems being faced by developers to communicate within different frameworks. And developers will be able to write applications in these frameworks.
But once you understand that, at the end of the day – this is just a matter of 0s and 1s, every technology and interop will look easy. :)
Namaste | Mayur Tendulkar
tendulkar-uvāca 