Custom Integration vs. Runtime Bridging Costs

Tags

As the authors of the book “Java EE and .NET Interoperability” put this, the systems in the companies tend to grow exponentially which is caused by the mergers, acquisitions, the development groups, purchasing the other components or systems, etc.

There might be many different reasons for the companies to integrate the systems they work with, however the one most clear is the competitive edge which can be achieved by coordination of the business processes to a single platform. The most common landscape in the companies is rather disordered. There are many different separate entities that would produce way better outcome if they were integrated.

There are many ways of integrating systems like Web services, rest services and other remote communication protocols but not so many options to integrate particular components and pieces that build those systems into single solution with the high performance. Below is the list of possible options to accomplish the integration of Java and .NET:

  • to rewrite required logic, algorithm, or code to the other technology
  • to use Web services and expose the component as separate application that can be consumed remotely
  • to develop the custom native wrapper (i.e. using JNI)
  • to use the ready runtime bridging solution available on the market

Here are the cases where the tight system integration would be required:

  • external devices SDKs and drivers (POS, payment devices, sensors, healthcare equipment, measuring equipment etc.)
  • back-end components and modules (IVR systems, database drivers, SCADA systems data sources, security algorithms, speech recognition, AI, BI etc..)
  • UI components (charting UI controls, 3D rendering UI controls, voice to text UI controls, document browsing UI controls etc.)

Above we have listed the possible approaches that can be implemented to integrate Java and .NET, now let’s look at the costs that each of the approaches generates. We have based the estimations on the USA off-shore rates:

Rewriting the code

This would depend heavily on the size of the system to be rewritten. However if any of the more serious modules would be considered we could easily accept that at least a year of the work would be required to reflect the functionality from .NET in Java application. We could assume that that this work would require 2 developers the costs could be estimated as follows:

1 Senior Java Developer Off-Shore Rate – $40 / hour
1 Professional Java Developer Off-shore Rate – $30 / hour

Average monthly hours worked: 160h

Development:
(160h x 12 months x $40) + (160h x 12 months x $30) = $76 800 + $57 600 = $134 400

Maintenance:  $0
This might be accepted that this scenario would not generate the additional maintenance costs related to the integration itself.

Creating the Web service

This approach would assume that the required piece of the system that comes from the other technology will be exposed to the original system through the Web service. Let’s put aside the security and performance concerns and focus on the cost part solely. Let’s assume that having one part ready and exposing it only through Web service, consuming that Web services and preparing deployment procedure would take 30% of the time of rewriting the whole code based on the regular development time and the customer reports:

1 Senior Java Developer Off-shore Rate – $40 / hour

Development: 160h x 4 months x $40 = $25 600

Yearly Maintenance:  $14 400

Developing the custom native wrapper

There are a lot of differences between the platforms, datatypes, syntaxes and also it requires highly experience native C or C++ developers. Assuming our module is complex and uses different data structure and has elaborated API we can assume that the cost could be around half of rewriting costs and will include both Java, .NET and C++ developers.

Fixed custom native wrapper is also hard to maintain and creates high dependency in case of any changes on the API. Let’s have a look at potential cost structure:

1 Senior Java/.NET Developer Off-shore Rate – $40 / hour
1 Senior C++ Developer Off-shore Rate – $50 / hour

Development: (160h x 4 months x $40) + (160h x 6 months x $50) = $73 600

Yearly Maintenance
(assuming 20% availability of .NET/Java and C++ developer):  $34 560

Use the ready bridging solution

The COTS (Commercial Of The Shelf) runtime bridging solution would allow to use any library that comes from the other technology as if it was created in the original system’s technology. Such bridges are generic and do not imply any additional costs in case of changes of our module or integration APIs. This means that based on the provided documentation the developer would be able to immediately and directly call anything from the provided library. This could significantly shorten the time of the development by up to 90% decrease risks and result in lower costs.

The maintenance costs of such solution is purely the cost of the product license. The market price could average around $468 per machine per year.

1 Senior Java Developer Off-shore Rate – $40 / hour

Development:  160h x (12*0,1) months x $40 = $7 680
Maintenance:  $468 / year

Comparison

Rewrite Web service Custom wrapper Ready bridging solution
Development $134 400 $25 600 $73 600 $7 680
Maintenance $0 $14 400 /year $34 560 /year bridge costs $468 /year
Total cost $134 400 $40 000 $108 160 $8 148

Interested in implementing the runtime bridging solution in your project?

Give Javonet a try and see for yourself how simple, easy to adopt, fast to implement it is! Experience and enjoy the super high performance thanks to built-in just in time native routes compilation and robust optimization algorithms. We have gathered and deeply analyzed our customers’ business requirements and expectations to deliver the most cost effective and seamless solution with licensing scaling with the size of their integrations. Enjoy fully functional free trial to conduct proof of concept within your projects with Javonet.

Learn how your business can benefit from Javonet by scheduling a demo call with our team.