.NET Java Interoperability
Sam Gill
sgill@sfsu.edu
http://online.sfsu.edu/~sgill
Overview
Background
Interoperability choices
Interoperability best practices
Migration vs. Interoperability
Q&A
Why Interop?
Meeting Customer Demand
Heterogeneity is a reality
– Total central control is impractical
– Most large companies have a mix
– Partnering and M&A activity contribute
Businesses Require Interop
– CIO's rate Integration as their #1 IT concern
Misconceptions
– Lock in vs. Open
– Cross platform vs. Interoperable
Windows .NET And Interop
From the Windows Server perspective,
Interop (via Web services, XML, many other
approaches) is the primary focus of .NET
.NET enables the use of Windows for
building loosely-coupled solutions that span
autonomous systems
– Part of the solution may run locally
– Part is available as services running elsewhere
– Services may, in turn, use other services
Interoperability Goals
Preserve existing investments
Seamlessly integrate new modules
Get to business logic on any platform
Get to data tier via standard APIs
Leverage platform strengths
Technology Stack Mapping
J2EE and .NET
– Both platforms provide equivalent services
– Choose the more “appropriate” option
Technology Stack Mapping
Service or Feature .NET (Product) J2EE (API)
GUI WinForms (AWT on J#) SWING / AWT
Web GUI ASP/ASP.NET JSP
Web Scripting ISAPI, HttpHandler, HttpModule Servlet, Filter
Server Side Serviced Component (COM+) EJB Session Beans
BL Component
Server Side Serviced Component (COM+) EJB BMP Entity Beans
Data Component with DB Logic
Server Side ADO.NET EJB CMP Entity Beans
Data Component
Naming ADSI JNDI
Remote Invocation .NET Remoting RMI / RMI-IIOP
Data Access ADO.NET (JDBC on J#) JDBC, SQL/J
Messaging MSMQ JMS
Transactions COM+ / MTS JTA
Application Flow
Client Web Tier Business Logic Tier Database Tier
j2ee
JSPs Servlets
DB2
Servlets EJBs
Browser
.net
Serviced
ASP.NET SQL Server
Components
Interop - Web Tier
Option 1
Leverage client capabilities to share
information across web applications
Use Client-side cookies
Not a flexible, extensible model
Web Tier Business Logic Data Tier
Web Tier Business Logic Data Tier
Interop - Web Tier
Option 2
Create an ASP.NET façade layer
Access Servlets, Controller from façade layer
XML descriptors to locate services
Façade proxies request & response
– Aka HTML Screen scraping
– Performance issues
Web Tier Business Logic Data Tier
Web Tier Business Logic Data Tier
ASP.NET Façade
Shim
ASP.NET J2EE
application
Browser
Shim J2EE
application
Interop - Web Tier
Option 3
Share session information across web
servers
Custom State management
– Custom session management module in
ASP.NET and J2EE App Server
Web Tier Business Logic Data Tier
Web Tier Business Logic Data Tier
Sharing Session State
Shim
J2EE Server
Browser
Database
Shim
IIS
Interop - Business Tier
Integrating EJBs
Integrating with App servers
Think about:
– Transactions
– Error handling
– Scalability, security, performance
Web Tier Business Logic Data Tier
Web Tier Business Logic Data Tier
Interop Options
Client Web Tier Business Logic Tier Database Tier
j2ee
JSPs Servlets
DB2
Servlets EJBs
Browser 3 Potential Options…
.net
Serviced
ASP.NET SQL Server
Components
Interop Options
Client Web Tier Business Logic Tier Database Tier
j2ee
JSPs Servlets
DB2
Servlets EJBs
Browser Option 1: RMI to .NET Remoting Bridge
.net
Serviced
ASP.NET SQL Server
Components
Interop Options
Option 1
RMI - .NET Remoting Bridge
– Advantages
Wire Level Performance
– Disadvantages
Tightly Coupled
Vendor and Version Specific
Web Tier Business Logic Data Tier
Web Tier Business Logic Data Tier
Tightly Coupled Bridges e.g.
Intrinsyc’s Ja.NET
Limited data type support
Exception propagation (limited)
.NET Application J2EE Application
.NET EJB
classes
.NET Ja.NET
Proxy .NET Remoting WAR file
CLR JVM
Interop Options
Client Web Tier Business Logic Tier Database Tier
j2ee
JSPs Servlets
DB2
Servlets EJBs
Browser Option 2: Message Queue
.net
Serviced
ASP.NET SQL Server
Components
Interop Options
Option 2
Message Queue (MSMQ, MQ Series)
– Advantages
Loosely Coupled
N – N Scenarios
Support for Transactions, Security, Reliable Messaging
– Disadvantages
No Synchronous Operation
Possible Port / Firewall Issues
Message Queues Across Internet?
Interop Options
Client Web Tier Business Logic Tier Database Tier
j2ee
JSPs Servlets
DB2
Servlets EJBs
Browser Option 3: Web Services
.net
Serviced
ASP.NET SQL Server
Components
Interop Options
Option 3
Web Services
– Advantages
Loosely Coupled
Synchronous (or Asynchronous) Operation
Firewall Friendly
Industry Momentum
Extensible
– Disadvantages
Lack of support for WS Standards in Transactions,
Reliable Messaging
What About Security?
For Web Services
– Base Stack (XML, XSD, SOAP, WSDL, UDDI)
does not specify security
– Can use point-to-point transport-based security
(e.g., HTTPS) today
– WS-Security coming in future releases
For Any Interop Mechanisms
– Roll-your own encryption, signing, etc.
Interop – Data Tier
JDBC Integration
J# support for JDBC
– Managed interfaces
Access the same data source
Map java.sql package to System.Data.OleDb
Use disconnected paradigm in converted
code
Web Tier Business Logic Data Tier
Web Tier Business Logic Data Tier
Designing For Integration
Connect-able applications
Loosely coupled
Orchestrate-able
Standards based
Platform agnostic
Performance best practices
– Less chatty
Loosely Coupled Systems
Independent systems, connected
– Independent infrastructure
– Independently managed, developed, deployed
– No mutual or implied trust between them
Goals
– Few, well-defined connection points
– No dependence on implementations
– Change on either end is tolerated gracefully
– Ad-hoc connections possible
Integrating Applications
SOAP
XML Web Services
Cross-language integration
COM+ (Enterprise Services)
BizTalk
Interop Recommendations
Use XML Web Services where possible
– Move toward a services-oriented architecture
Use XML Schema
– Implicit when using XML Web Services
– Also applies to messaging, doc exchange, others
Diverge from these only when absolutely
necessary
XML Web Services
Works in either direction: .NET Java
Various Java stacks work with .NET
– Apache AXIS
– The Mind Electric Glue
– IBM WebSphere **
– BEA WebLogic 7 (“Cajun”)
Asynchronous conversations possible
– E.g., via .NET Delegates
Issue: Platform-specific Data types
– E.g., ADO.NET DataSet
– E.g., Java Vector
– …many other examples
Integration Broker
Beyond Point-to-Point Connections
• Transformation
App • Combination
App • Tracking
• Analysis
• Business Process
Modelling
App
SOAP J2EE Server
BizTalk +
Server Web Service
implementation
.NET
Web Service
App
App
Integration Broker
Beyond Point-to-Point Connections
Can resolve schema-agreement issues via
transformation at the broker
Model business processes above application
code
Issue: added cost (capital and expense)
Passport Interoperability .NET
Passport Single Sign on
Interop at the web services tier
– Cookie sharing
Interop at the data tier
– Sharing unique User ID issued by Passport
“Brokered” implementation
Choosing the right option
Question Yes No
Does the system require very high volume Consider using common technology on Use XML Web services as your
message exchange – 1000’s of messages per both sides. This allows the use of a bridging protocol.
second at low latency? high-performance binary protocol, and a
tightly-coupled model, which better
supports high volumes of transactions.
Can the code of the existing WebSphere Wrap and expose existing code as web Use implicit bridging, based on the
system be modified? services. communications and remoting
mechanisms available in the existing
WebSphere app.
Need Store-and-forward or tolerance of Use message middleware. Use simpler transport, such as SMTP,
network failures? FTP, HTTP.
XML Web services are inappropriate or Use a shared file system, messaging Use XML Web services.
somehow not feasible? middleware, or shared database.
Is there any of the following: a complex Use BizTalk Server to deliver these Direct peer-to-peer XML Web
process flow? multiple inputs and outputs? capabilities. services.
message transformation or protocol
transformation required? Must messages be
tracked, audited, and/or analyzed?
Distributed Transactions required across the Re-architect your system to avoid tight-
bridge? coupling across fiefdoms. Or, use
common technology to allow distributed
transactions.
Summary
Bridging between .NET and J2EE is possible
and appropriate
– Building these connections makes business
sense
Use XML Web services where possible,
other techniques where necessary
Establish conventions, be mindful of tradeoffs
Migration vs. Interoperability