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
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.
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 “ProxyStub” 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
Jav
a
Stub
JNI
DLL
“MSWord” or
“MSExcel”
COM Server
Windows Platform
continued
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.
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-Interop - Component stack
7 Application j-Interop (Implementing DCOM)
6 Presentation NDR (Network Data Representation)
5 Session DCE 1.1 RPC (Jarapac)
4 Transport TCP, UDP
3 Network IP
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.
 No longer a dependency on cross platform resources, minimizing cost
and improving quality:
 The same resources for Java can be utilized without any additional
trainingcompetency 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
vikram.roopchand@j-interop.org
Thank you for your time and patience.
That’s it…

More Related Content

DOCX
PROFESSIONAL PROFILE
PPTX
Interpreted and compiled language
PPSX
PPT
Dot net
PDF
Compiler type
PDF
Compilation v. interpretation
PPTX
OMG CORBA Component Model tutorial
PROFESSIONAL PROFILE
Interpreted and compiled language
Dot net
Compiler type
Compilation v. interpretation
OMG CORBA Component Model tutorial

What's hot (19)

DOCX
WEBSITE DEVELOPMENT
PPTX
Just in-time-compiler
PDF
PPTX
Selenium Training in Phagwara
PPTX
Ss ui lecture 1
DOCX
Introduction to embedded c
PPTX
Selenium Training in Amritsar
PPTX
Selenium Training in Jalandhar
DOCX
JaiPrakashTiwari_Resume
PPTX
Command line interface “CLI”
PPTX
Selenium Training in Chandigarh
PPTX
Compilers
PDF
Harish resume
PPT
03 the c language
PDF
Java vs Python: Who is Winning the Coding Battle?
PPT
Language translator
PPTX
Compiler vs interpreter
PPTX
Compiler vs interpreter
PPT
How a Compiler Works ?
WEBSITE DEVELOPMENT
Just in-time-compiler
Selenium Training in Phagwara
Ss ui lecture 1
Introduction to embedded c
Selenium Training in Amritsar
Selenium Training in Jalandhar
JaiPrakashTiwari_Resume
Command line interface “CLI”
Selenium Training in Chandigarh
Compilers
Harish resume
03 the c language
Java vs Python: Who is Winning the Coding Battle?
Language translator
Compiler vs interpreter
Compiler vs interpreter
How a Compiler Works ?
Ad

Similar to J interop (20)

PPTX
It pro dev_birbilis_20101127_en
PDF
Integration of java ee applications on c – based implementations
PPTX
GOTO Night with Charles Nutter Slides
PDF
NASAfinalPaper
PDF
NDK Primer (AnDevCon Boston 2014)
PPT
J2EEvs.NET
PPSX
Introduction to .net framework
PPTX
Introduction to .net FrameWork by QuontraSolutions
PPS
Ajs 1 b
PDF
Java vs. C/C++
PDF
Gustavo Garnica: Evolución de la Plataforma Java y lo que Significa para Ti
PPTX
A tour of Java and the JVM
PDF
Java: Rumours of my demise are greatly exaggerated
PDF
Android and cpp
PPT
Dev381.Pp
PPT
C++ programming with jni
PDF
6. The grid-COMPUTING OGSA and WSRF
PPTX
PDF
Beyond JVM - YOW Melbourne 2013
PPTX
It pro dev_birbilis_20101127_en
Integration of java ee applications on c – based implementations
GOTO Night with Charles Nutter Slides
NASAfinalPaper
NDK Primer (AnDevCon Boston 2014)
J2EEvs.NET
Introduction to .net framework
Introduction to .net FrameWork by QuontraSolutions
Ajs 1 b
Java vs. C/C++
Gustavo Garnica: Evolución de la Plataforma Java y lo que Significa para Ti
A tour of Java and the JVM
Java: Rumours of my demise are greatly exaggerated
Android and cpp
Dev381.Pp
C++ programming with jni
6. The grid-COMPUTING OGSA and WSRF
Beyond JVM - YOW Melbourne 2013
Ad

J interop

  • 2. Contents  What is it ?  Comparison with Java Native interface  Comparison with J-Integra® for COM  Benefits of using j-Interop  Support
  • 3. 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.
  • 4. 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 “ProxyStub” 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.
  • 5. 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 Jav a Stub JNI DLL “MSWord” or “MSExcel” COM Server Windows Platform continued
  • 6. 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.
  • 7. 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)
  • 8. 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.
  • 9. j-Interop - Component stack 7 Application j-Interop (Implementing DCOM) 6 Presentation NDR (Network Data Representation) 5 Session DCE 1.1 RPC (Jarapac) 4 Transport TCP, UDP 3 Network IP
  • 10. 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.
  • 11.  No longer a dependency on cross platform resources, minimizing cost and improving quality:  The same resources for Java can be utilized without any additional trainingcompetency 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
  • 12. Support  Please use the Support guidelines on the SourceForge home of j-Interop.  For Professional services, please contact vikram.roopchand@j-interop.org
  • 13. Thank you for your time and patience. That’s it…