Please visit our article on Linked in . Click Here
Working at Javonet, every day I experience the fact that the software development market today is all about the cloud, services and integrations. Many companies compose the software stack out of many different products and solutions running in the cloud and on-premise, often supplemented with a bunch of legacy solutions. The complexity of this heterogeneous environment grows and scales up with the development of the business it is supporting.
With more and more data stored in those systems we are becoming increasingly dependent on those solutions. Whatever the systems we have there are, there is an inevitable need for integrating their data. The integration can be done using other cloud-based integration service, many workflow based platforms or event based enterprise application integration platforms, data warehouses or custom developed solutions.
Java and .NET is everywhere
Following the Gartner research, 80% of corporations have an evenly distributed amount of .NET and Java based solutions in their environment. These are not only the whole systems, but also modules, user interface controls, reporting controls, authentication and encryption libraries, back-end services or SDKs and drivers to other systems and devices.
When it comes to integration we often use many out-of-the-box solutions delivered from the vendors of our integration platforms, but one of their common features is the very flexible possibility of adding a custom developed module. It can be a step in the workflow that interacts with our specific system, user control on UI, a data source from our legacy platform or the endpoint for interaction with custom devices and many other points of connection to somewhere else.
Depending on our platform, these kind of custom modules / plugins need to be, between others, very often written in a .NET or Java development environment.
The need for a connection between Java and .NET
Due to the mentioned fact of diversified environments with Java and .NET that is a standard in 80% of corporations, when we have a Java integration or workflow platform it easily integrates with all databases, web services and Java based modules. However, it faces big challenge when it comes to connecting .NET modules, SDKs, libraries and systems without exposed generic APIs or Web Services, and the other way when we use a .NET based platform.
Additionally, it might be a custom web or desktop applications that serves as a management dashboard, reporting engine or any other custom solution where there is a need to either use some data or logic residing in the .NET side of a business or user controls prepared for .NET systems familiar for your end-users and specially designed for particular company needs.
For enterprises that deliver software products as a main service or as a supplement to their other core solutions, it also reveals the huge demand for the possibility to integrate that product with .NET or Java systems in their end-customer environments.
How to connect
When speaking about situations where there is no generic API or Web Service that can be consumed, in a diversified world of different languages, it usually comes down to custom development. Regardless of easy access to internal Java and .NET development departments, it is always important to choose solutions that will provide the highest reliability, performance, flexibility and the lowest cost and effort demand.
The costs of wrong solutions
For integrations like for any other software based solution, it is not only the cost and effort during development, but future extensions and maintenance through the whole lifecycle of the underlying integrated systems.
The most common solution is to wrap the .NET module in some universal API like Web Services, REST services or custom client-server infrastructure with TCP/IP or another communication channel. However, all of these mean that we are required to build a man-in-the-middle solution that must be maintained, hosted and updated. Additionally, it must in fact rewrite the whole API of the module that it is exposing and route the queries to that module when invoked from other system. This not only requires a lot of effort, which grows rapidly with the size of exposed modules and functionalities, but in addition it is usually not fast, secure and reliable enough for many cases.
The simplest example might be the usage of a highly resource-consuming dynamic chart or 3D models rendering user control of healthcare equipmentwritten in .NET that we need to embed in the Java user interface and fill it with data from the Java system. This can never be achieved with Web Services or another mentioned method.
The same might apply if we need to quickly and frequently utilize a .NET module from EAI or workflow platform that is capable of loading Java modules as steps but not .NET.
Correct solution, lower costs and risk mitigation
From that introduction we come to the valid reasoning for businesses’ justified situation of deciding to choose a native bridge.
A native bridge means that .NET runtime is loaded in the memory within the Java process and co-existing side by side with the running Java systems. A native bridge comes as a Java module and can be loaded by any Java integration platform, web or desktop application and Java service. From the Java perspective it is a regular Java module, and interaction is achieved in a standard way. Internally, such a bridge loads a .NET engine in the Java process and handles a whole complexity of communication with each other, providing the space to easily load and utilize .NET modules.
From a developer’s perspective it is a simple Java module that gives them access to anything that exists in the .NET world without any interference in their source code. This is done without building a man-in-the-middle solution, without replicating their API, and without maintaining client-server infrastructure. Finally, it is without the risk of project delays, complex challenges and non-achievable goals.
A native bridge also provides even more benefits. The connection between .NET and Java happens in the same process in computer memory going through direct references between logic in those two languages. It means that no data is sent via network or any other communication channel that can be easily intercepted giving extremely high safety of the data and clean closed solution.
Moreover, the usage of a direct in-process connection provides performance of the integration that is incomparably higher than any other solution. Our customers find it feasible in most critical solutions including high-frequency trading, banking, healthcare, mining machines or oil and gas extraction.
The maintenance costs are fixed and flat, depending only on the native bridge support fee which includes full access to updates, bug fixes, compatibility with the latest Java and .NET runtimes, and features and development support with training, documentation and materials for developers.
The amount of development efforts required is equal to building a solution purely based on a Java or .NET platform, as the whole integration complexity is completely taken out of the picture by a module that gives free access to anything in the .NET world like it was written in Java.
The costs of the licenses on the other hand are a fraction of the development costs of custom solution for a single module, and it gives us full interoperability for any amount of modules we will need in the future.
Additional savings come from risk mitigation as integration can be easily tested and verified in proof of concept projects without purchasing the licenses, only going with the free trial.
Other business benefits
The savings come not only from lower development costs, faster delivery, flexibility, safety and effortless maintenance, but also from new possibilities:
- Access to any .NET code in Java – re-using the work of .NET developers in Java departments might cut project costs by more than half and lead to high cost optimization
- Higher products value – for companies that deliver software products, embedding a native bridge might significantly increase the value of the solution by providing new integration possibilities
- More customers – utilizing a native bridge might double the target market by exposing the solution written in .NET not only to .NET developers, but also to Java ones.
- Access to .NET third-party components – with the possibility of easy and fearless usage of .NET in Java we can re-use the purchased modules, user interface components, SDKs and products available so far only for .NET developers in JAVA projects too.
Having the native bridge in enterprise software architecture toolsetopens up completely new frontiers, gives new possibilities and unleashes the benefits of easy integration and work reuse between Java and .NET. It ultimately leads to high cost savings, shorter delivery times, improved performance and lower risk.
In today’s highly diversified software world it is a must to not only consider, but also apply this approach.
I would like to highly encourage you to perform the research and evaluation of that technology in your projects and find all the possible benefits that you might be missing.
Przemysław Ładyński is CTO at Javonet, a native Java to .NET bridge vendor that solves interoperability issue in the most seamless, effortless and flexible way. The great API gives access to any modules with a development effort equal by almost 1:1 to the same project written purely in single technology. The incredible single-file light technology makes it very easy to embed in any product and deployment scenario.
The benefits of Javonet have already been proven around the world on five continents in 95+ countries, tested by more than 1000 companies and trusted by many reputable universitiesincluding SIAT@SFU, University of Maryland, Phillips Universitat Marburg, Washington University, University of Waterloo and others. Javonet integrates systems in car manufacturers, integration platforms, logistics, banking, the energy sector and many others. Javonet Website: http://www.javonet.com
Edited by AlexanderPashkovski, 06 September 2015 - 02:59 AM.