.NET Java Interoperability

1
.NET Java Interoperability

• Sam Gill
• sgill_at_sfsu.edu
• http//online.sfsu.edu/sgill

2
Overview

• Background
• Interoperability choices
• Interoperability best practices
• Migration vs. Interoperability
• QA

3
Why Interop? Meeting Customer Demand

• Heterogeneity is a reality
• Total central control is impractical
• Most large companies have a mix
• Partnering and MA activity contribute
• Businesses Require Interop
• CIO's rate Integration as their 1 IT concern
• Misconceptions
• Lock in vs. Open
• Cross platform vs. Interoperable

4
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

5
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

6
Technology Stack Mapping

• J2EE and .NET
• Both platforms provide equivalent services
• Choose the more appropriate option

7
Technology Stack Mapping
8
Application Flow
9
Interop - Web TierOption 1

• Leverage client capabilities to share information
  across web applications
• Use Client-side cookies
• Not a flexible, extensible model

10
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

11
ASP.NET Façade
J2EE application
Shim
ASP.NET
Shim
Browser
J2EE application
J2EE application
12
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

13
Sharing Session State
J2EE Server
Shim
Browser
Database
IIS
Shim
14
Interop - Business Tier

• Integrating EJBs
• Integrating with App servers
• Think about
• Transactions
• Error handling
• Scalability, security, performance

15
Interop Options
Database Tier
Client
Web Tier
Business Logic Tier
j2ee
Servlets EJBs
DB2
JSPs Servlets
Browser
3 Potential Options
.net
SQL Server
Serviced Components
ASP.NET
16
Interop Options
Database Tier
Client
Web Tier
Business Logic Tier
j2ee
Servlets EJBs
DB2
JSPs Servlets
Browser
Option 1 RMI to .NET Remoting Bridge
.net
SQL Server
Serviced Components
ASP.NET
17
Interop OptionsOption 1

• RMI - .NET Remoting Bridge
• Advantages
• Wire Level Performance
• Disadvantages
• Tightly Coupled
• Vendor and Version Specific

18
Tightly Coupled Bridges e.g. Intrinsycs Ja.NET

• Limited data type support
• Exception propagation (limited)

19
Interop Options
Database Tier
Client
Web Tier
Business Logic Tier
j2ee
Servlets EJBs
DB2
JSPs Servlets
Browser
Option 2 Message Queue
.net
SQL Server
Serviced Components
ASP.NET
20
Interop OptionsOption 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?

21
Interop Options
Database Tier
Client
Web Tier
Business Logic Tier
j2ee
Servlets EJBs
DB2
JSPs Servlets
Browser
Option 3 Web Services
.net
SQL Server
Serviced Components
ASP.NET
22
Interop OptionsOption 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

23
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.

24
Interop Data TierJDBC 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

25
Designing For IntegrationConnect-able
applications

• Loosely coupled
• Orchestrate-able
• Standards based
• Platform agnostic
• Performance best practices
• Less chatty

26
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

27
Integrating Applications

• SOAP
• XML Web Services
• Cross-language integration
• COM (Enterprise Services)
• BizTalk

28
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

29
XML Web Services

• Works in either direction .NET lt-gt 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

30
Integration BrokerBeyond Point-to-Point
Connections

• Transformation
• Combination
• Tracking
• Analysis
• Business ProcessModelling

BizTalkServer
31
Integration BrokerBeyond 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)

32
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

33
Choosing the right option
34
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