J-Interop Open Source Java COM Bridge. Contents What is it ? Comparison with Java Native interface Comparison with J-Integra® for COM Benefits of using.

Slides:



Advertisements
Similar presentations
MapuSoft Technologies Presentation OS Abstractor, OS Changer, OS PAL and MapuSoft are registered trademarks of MapuSoft Technologies Inc. All other trademarks.
Advertisements

What is RMI? Remote Method Invocation –A true distributed computing application interface for Java, written to provide easy access to objects existing.
COM vs. CORBA.
NHibernate Object/Relational Persistence for.NET.
Microsoft COM Component Object Model Microsoft Corporation ™
The road to reliable, autonomous distributed systems
Understand Virtualized Clients Windows Operating System Fundamentals LESSON 2.4.
Component Patterns – Architecture and Applications with EJB copyright © 2001, MATHEMA AG Component Patterns Architecture and Applications with EJB JavaForum.
Java: History and Introduction (Lecture # 1). History… Java – Based on C and C++ – Developed in 1991 for intelligent consumer electronic devices – Green.
Sapana Mehta (CS-6V81) Overview Of J2EE & JBoss Sapana Mehta.
Contiki A Lightweight and Flexible Operating System for Tiny Networked Sensors Presented by: Jeremy Schiff.
Distributed Object Computing Weilie Yi Dec 4, 2001.
CS490T Advanced Tablet Platform Applications Network Programming Evolution.
1. Introducing Java Computing  What is Java Computing?  Why Java Computing?  Enterprise Java Computing  Java and Internet Web Server.
For more Lectures and Notes Visit
INTRODUCTION TO CLOUD COMPUTING Cs 595 Lecture 5 2/11/2015.
Object Oriented Databases by Adam Stevenson. Object Databases Became commercially popular in mid 1990’s Became commercially popular in mid 1990’s You.
VAP What is a Virtual Application ? A virtual application is an application that has been optimized to run on virtual infrastructure. The application software.
Getting connected.  Java application calls the JDBC library.  JDBC loads a driver which talks to the database.  We can change database engines without.
1 The SpaceWire Internet Tunnel and the Advantages It Provides For Spacecraft Integration Stuart Mills, Steve Parkes Space Technology Centre University.
Visual Basic: An Object Oriented Approach 12 – Creating and using ActiveX objects.
CSCI 224 Introduction to Java Programming. Course Objectives  Learn the Java programming language: Syntax, Idioms Patterns, Styles  Become comfortable.
Beyond DHTML So far we have seen and used: CGI programs (using Perl ) and SSI on server side Java Script, VB Script, CSS and DOM on client side. For some.
Quality Assurance for Component- Based Software Development Cai Xia (Mphil Term1) Supervisor: Prof. Michael R. Lyu 5 May, 2000.
Oracle8 JDBC Drivers Section 2. Common Features of Oracle JDBC Drivers The server-side and client-side Oracle JDBC drivers provide the same basic functionality.
Virtualization Lab 3 – Virtualization Fall 2012 CSCI 6303 Principles of I.T.
Understanding the CORBA Model. What is CORBA?  The Common Object Request Broker Architecture (CORBA) allows distributed applications to interoperate.
COM vs. CORBA Computer Science at Azusa Pacific University September 19, 2015 Azusa Pacific University, Azusa, CA 91702, Tel: (800) Department.
Chapter 3: Objects, Components, and the Web Textbook IT Architectures and Middleware, Second Edition Chris Britton and Peter Bye AIT 600 Jeff Schmitt September.
FALL 2005CSI 4118 – UNIVERSITY OF OTTAWA1 Part 4 Other Topics RPC & Middleware.
1 Chapter 38 RPC and Middleware. 2 Middleware  Tools to help programmers  Makes client-server programming  Easier  Faster  Makes resulting software.
Instant Messaging for the Workplace A pure collaborative communication tool that does not distract users from their normal activities.
Why Java? A brief introduction to Java and its features Prepared by Mithat Konar.
WEB SERVICES Mahmoud Rabie – EGJUG W EB SERVICES The world before Situation Problems Solutions Motiv. for Web Services Probs. with Curr. sols. Web.
Enterprise Java Beans Java for the Enterprise Server-based platform for Enterprise Applications Designed for “medium-to-large scale business, enterprise-wide.
SAMANVITHA RAMAYANAM 18 TH FEBRUARY 2010 CPE 691 LAYERED APPLICATION.
DCOM (Overview) by- Jeevan Varma Anga.
Distributed Component Object Model (DCOM)
Google Web Toolkit An Overview By Shauvik Roy Choudhary.
Presentation: SOAP/WS in a distributed object framework, Application Servers & AXIS SOAP.
Computer Emergency Notification System (CENS)
Component Technology. Challenges Facing the Software Industry Today’s applications are large & complex – time consuming to develop, difficult and costly.
Middleware for FIs Apeego House 4B, Tardeo Rd. Mumbai Tel: Fax:
Distributed Information Systems. Motivation ● To understand the problems that Web services try to solve it is helpful to understand how distributed information.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
Getting started with Programming using IDE. JAVA JAVA IS A PROGRAMMING LANGUAGE AND A PLATFORM. IT CAN BE USED TO DELIVER AND RUN HIGHLY INTERACTIVE DYNAMIC.
S imple O bject A ccess P rotocol Karthikeyan Chandrasekaran & Nandakumar Padmanabhan.
PRIOR TO WEB SERVICES THE OTHER TECHNOLOGIES ARE:.
An Introduction to JavaServer™ Pages Prepared by Nicole Swan.
What is virtualization? virtualization is a broad term that refers to the abstraction of computer resources in order to work with the computer’s complexity.
S O A P ‘the protocol formerly known as Simple Object Access Protocol’ Team Pluto Bonnie, Brandon, George, Hojun.
CSI 3125, Preliminaries, page 1 SERVLET. CSI 3125, Preliminaries, page 2 SERVLET A servlet is a server-side software program, written in Java code, that.
1 Chapter 38 RPC and Middleware. 2 Middleware  Tools to help programmers  Makes client-server programming  Easier  Faster  Makes resulting software.
0 What Does SIP Bring to Your Customer Experience ? Extend VoIP and IP Contact Center values through support of SIP o Media and location independent support.
Java State Explorer by: Richard Sherman Stephanie Taylor.
Visual Programming Borland Delphi. Developing Applications Borland Delphi is an object-oriented, visual programming environment to develop 32-bit applications.
Computer System Structures
Object Oriented Programming in
Chapter 1 Introduction to Computers, Programs, and Java
What is RMI? Remote Method Invocation
CMPE419 Mobile Application Development
Enterprise Application Architecture
Component-Based Software Engineering: Technologies, Development Frameworks, and Quality Assurance Schemes X. Cai, M. R. Lyu, K.F. Wong, R. Ko.
WEB SERVICES Mr. P. VASANTH SENA.
WEB SERVICES Mahmoud Rabie – EGJUG 2006.
Java History, Editions, Version Features
Quality Assurance for Component-Based Software Development
CMPE419 Mobile Application Development
C++/Java/COM Interoperability
Presentation transcript:

j-Interop Open Source Java COM Bridge

Contents What is it ? Comparison with Java Native interface Comparison with J-Integra® for COM Benefits of using j-Interop Support What is it ? Comparison with Java Native interface Comparison with J-Integra® for COM Benefits of using j-Interop Support

j-Interop What is j-Interop ? Pure Java implementation of DCOM protocol requiring no native code (i.e. no DLLs). Runs on any platform that supports a Java (including Linux, Solaris, Unix Variants). Zero server installation (i.e. no JVM or additional software required on the COM platform). Easy to use API. This allows the Java developer full control and flexibility to model calls to the COM server. Providing out-of-box implementation of Automation specific interfaces (like IDispatch etc.) Open source library (LGPL). Matured code base (2 years of active development,1 year of Beta) and excellent support. What is j-Interop ? Pure Java implementation of DCOM protocol requiring no native code (i.e. no DLLs). Runs on any platform that supports a Java (including Linux, Solaris, Unix Variants). Zero server installation (i.e. no JVM or additional software required on the COM platform). Easy to use API. This allows the Java developer full control and flexibility to model calls to the COM server. Providing out-of-box implementation of Automation specific interfaces (like IDispatch etc.) Open source library (LGPL). Matured code base (2 years of active development,1 year of Beta) and excellent support.

Compared to: Java Native Interface Though JNI is Java, you still need to know a lot more about the native component and the target architecture before accessing its services. Developer has to be proficient in Java and in the native programming language as well. With increasing demands to deliver on time - before time, and the delivery having quality, it's usually hard to find such cross-platform resources. JNI takes away one of the most powerful features of the language itself, "platform independence" (write once, run anywhere). It binds the application to the host platform. Normally, under such cross platform scenarios a “Proxy\Stub” way is taken, Proxy sits on the host platform and Stub sits on the COM server platform. But this is an “invasive” procedure and may be disallowed by the Administrator as a potential security or integrity risk. Another inherent risk when linking with native code is the instability it may bring with it. A poorly written DLL (speaking of Windows) will bring down an entire JVM, taking with it some vital applications. Another aspect hard to put in is Bi-Directional access and Event based operations. It is precarious to do this via JNI. Though JNI is Java, you still need to know a lot more about the native component and the target architecture before accessing its services. Developer has to be proficient in Java and in the native programming language as well. With increasing demands to deliver on time - before time, and the delivery having quality, it's usually hard to find such cross-platform resources. JNI takes away one of the most powerful features of the language itself, "platform independence" (write once, run anywhere). It binds the application to the host platform. Normally, under such cross platform scenarios a “Proxy\Stub” way is taken, Proxy sits on the host platform and Stub sits on the COM server platform. But this is an “invasive” procedure and may be disallowed by the Administrator as a potential security or integrity risk. Another inherent risk when linking with native code is the instability it may bring with it. A poorly written DLL (speaking of Windows) will bring down an entire JVM, taking with it some vital applications. Another aspect hard to put in is Bi-Directional access and Event based operations. It is precarious to do this via JNI.

Compared to: Java Native Interface JNI based solutions look more or less like figure 1. Figure 1 Java Application using “native” APIs i.e. via JNI (Windows Platform) Java Application using a “proxy”. This may be RMI. (UNIX Platform) Java Proxy Java Stub JNI DLL “MSWord” or “MSExcel” COM Server Windows Platform continued

Compared to: Java Native Interface Since j-Interop is purely in Java, existing Java developers can be leveraged without the need to hire additional resources. Pure Java also makes sure that the code written once will run on any platform such as Linux or Solaris etc. (Platforms supporting Java) There is no security risk involved as j-Interop based solutions are completely non-invasive, they behave like standard COM clients and do not require any special treatment. For that matter the COM server will never know the difference. Since there is no native code involved the question of instability does not arise. j-Interop provides easy APIs to register for Events and even lets you “replace” a COM pointer with it’s Java implementation. This polymorphism allows you to dynamically modify behavior of COM servers from across domains. Since j-Interop is purely in Java, existing Java developers can be leveraged without the need to hire additional resources. Pure Java also makes sure that the code written once will run on any platform such as Linux or Solaris etc. (Platforms supporting Java) There is no security risk involved as j-Interop based solutions are completely non-invasive, they behave like standard COM clients and do not require any special treatment. For that matter the COM server will never know the difference. Since there is no native code involved the question of instability does not arise. j-Interop provides easy APIs to register for Events and even lets you “replace” a COM pointer with it’s Java implementation. This polymorphism allows you to dynamically modify behavior of COM servers from across domains.

MSRPC(DCOM) Figure 2 “MSWord” or “MSExcel” COM Server. Windows Platform UNIX Platform Java virtual Machine j-Interop based Java Application Windows Platform Java virtual Machine j-Interop based Java Application continued j-Interop based solutions look like figure 2. Compared to: Java Native Interface MSRPC(DCOM)

Compared to: J-Integra® for COM J-Integra® for COM is also a pure Java implementation of DCOM protocol. Almost all features provided by this commercial library are provided by j-Interop as well including callbacks and support for all COM data types. Under lab conditions (I have no other source or setup) j-Interop has performed comparably with a Windows COM client and better than J- Integra (in the DCOM mode). The areas where J-Integra scores over j-Interop are:- Commercial Compiler to generate wrapper classes. This feature will be shortly available in j-Interop. Claims Full Bi-Directional access. J-Interop is partial (only an existing COM reference can be replaced by a Java implementation, but a Java Server cannot be morphed as a COM server. This feature is under review for lack of use cases and demand. If someone sees a need, please ping me. J-Integra® for COM is also a pure Java implementation of DCOM protocol. Almost all features provided by this commercial library are provided by j-Interop as well including callbacks and support for all COM data types. Under lab conditions (I have no other source or setup) j-Interop has performed comparably with a Windows COM client and better than J- Integra (in the DCOM mode). The areas where J-Integra scores over j-Interop are:- Commercial Compiler to generate wrapper classes. This feature will be shortly available in j-Interop. Claims Full Bi-Directional access. J-Interop is partial (only an existing COM reference can be replaced by a Java implementation, but a Java Server cannot be morphed as a COM server. This feature is under review for lack of use cases and demand. If someone sees a need, please ping me.

j-Interop - Component stack 7Applicationj-Interop (Implementing DCOM) 6PresentationNDR (Network Data Representation) 5SessionDCE 1.1 RPC (Jarapac) 4TransportTCP, UDP 3NetworkIP

j-Interop - Benefits Clean integration of two of the leading technologies without writing any custom code: j-Interop will produce all the Java classes necessary to interoperate with the COM component, thus eliminating any need to write native (JNI) DLLs. (coming soon) This decreases development time and also shortens the entire software lifecycle for the products (based on j-Interop). Such products are also saved from any kind of instability in function resulting from poorly written native code (DLLs). Accessing COM components from any type of Java client, including Applets, EJBs, Servlets, JSPs, and standalone applications Maximizing reuse of existing Java and COM components: Since all the plumbing on interoperating with COM servers is done by j-Interop, it makes reusing same components again instead of porting back and forth between domains, a more lucrative and viable option. Clean integration of two of the leading technologies without writing any custom code: j-Interop will produce all the Java classes necessary to interoperate with the COM component, thus eliminating any need to write native (JNI) DLLs. (coming soon) This decreases development time and also shortens the entire software lifecycle for the products (based on j-Interop). Such products are also saved from any kind of instability in function resulting from poorly written native code (DLLs). Accessing COM components from any type of Java client, including Applets, EJBs, Servlets, JSPs, and standalone applications Maximizing reuse of existing Java and COM components: Since all the plumbing on interoperating with COM servers is done by j-Interop, it makes reusing same components again instead of porting back and forth between domains, a more lucrative and viable option.

No longer a dependency on cross platform resources, minimizing cost and improving quality: The same resources for Java can be utilized without any additional training\competency building and the turn around time can be bought down substantially. Not having to deal with native code also removes the complexity associated with maintaining the same. The code is now much cleaner and has a distinct line of difference between what is from one domain and what is from another. Debugging the projects based on j-Interop is substantially easier than debugging JNI based DLL projects. Easier deployment, there is no custom code at the server: This is a big advantage in terms of administering the machines where the COM servers are deployed. The administrator does not have to care about security or the instability of the native components bringing the server down (Denial of Service). Increasing marketability of products across domains: Choice of low turn around time, easier deployment, no requirement of cross platform resources, less maintainability all scale up the availability and marketability of products (based on j-Interop) across domains. No longer a dependency on cross platform resources, minimizing cost and improving quality: The same resources for Java can be utilized without any additional training\competency building and the turn around time can be bought down substantially. Not having to deal with native code also removes the complexity associated with maintaining the same. The code is now much cleaner and has a distinct line of difference between what is from one domain and what is from another. Debugging the projects based on j-Interop is substantially easier than debugging JNI based DLL projects. Easier deployment, there is no custom code at the server: This is a big advantage in terms of administering the machines where the COM servers are deployed. The administrator does not have to care about security or the instability of the native components bringing the server down (Denial of Service). Increasing marketability of products across domains: Choice of low turn around time, easier deployment, no requirement of cross platform resources, less maintainability all scale up the availability and marketability of products (based on j-Interop) across domains. j-Interop - Benefits continued

Support Please use the Support guidelines on the SourceForge home of j-Interop. For Professional services, please contact Please use the Support guidelines on the SourceForge home of j-Interop. For Professional services, please contact

Thank you for your time and patience. That’s it…