Borland Janeva

1
Borland Janeva

• .NET and COM Interoperability

Anders Ohlsson Sr Manager Developer Relations
2
What is Janeva?
3
.NET COM interoperability to J2EE and CORBA

• Integrated Solution
• Tight Integration with .NET IDEs
• Support for Native environments
• Cost Effective Implementation
• Leverages existing infrastructure
• Additional development not needed
• Based on Proven Foundations
• Nothing New and Nothing Proprietary!
• Based on .NET, J2EE, and CORBA
• High Performance
• Leverages IIOP
• Based on Borland Enterprise Servera proven
  Technology
• Reliable, Scalable, and Secured
• Leverage existing Load Balancing,Clustering,
  Failover, etc
• Security provided
• Transactions Supported

4
Why .NET?
5
Whose is considering .NET?

• Organizations who
• Need to add new skin to their existing
  applications
• Have existing J2EE or CORBA infrastructures
• Require seamless and secured interoperability
  between the platforms
• Encountered issues with Web Services and Bridging
  solutions
• Performance, Scalability, and Reliability
• Implementing additional infrastructures
• Adopting proprietary (vs. standards) based
  solutions

6
Why are organizations considering .NET?

• Improved Productivity
• Faster-time-to-Market on front-end development
• Lower development costs
• Better UI Experience
• Customer Satisfaction
• Improved product marketability
• Improved general use and adoption of application
• Lower costs associated with
• Deployments
• Migrations
• Training
• Documentation
• Support
• So then why J2EE and CORBA?!
• Scalability
• Reliability and Security
• Platform Diversity
• Lower Total Cost of Ownership

7
Where do technologies play well?
8
What needs to be solved?
9
Connecting the environments
Chasm
Getting .NET, J2EE and CORBA to work together -
Seamlessly - Securely - Reliably - with High
Performance
10
Solutions available for Interoperability

• Web Services
• Centralized Bridging
• Distributed Bridging
• Messaging
• On-The-Wire
• Lets examine each of these

11
Web Services
12
Web Services

• Advantage
• Can interoperate with most technical
  infrastructures
• Communicate across Firewalls
• Coarse-grained solution
• Development tools are generally available and
  tightly integrated
• Disadvantage
• Additional Hardware and Software resources may be
  needed
• Additional development may be needed
• Changes may be required to the back-end
• More components added to the mix
• More working parts
• More parts to Manage, Maintain, and Support
• Poor Performance
• Web Services must act as translator between .NET
  and J2EE CORBA environments
• Could be a single point of failure
• Security, Transactions, and Qualities of Service
  (QoS) features may not be supported
• Interoperability is not seamless
• Standards have yet to be agreed upon

13
Centralized Bridge
14
Central Bridging

• Advantage
• Customization may be easier to address specific
  requirements
• Disadvantage
• Additional Hardware and Software resources are
  needed
• Additional Development will be needed
• Changes may be required to the back-end
• Poor Performance
• Bridge must act as translator between .NET and
  J2EE CORBA environments
• Single-point of failure
• Security, Transactions, and Qualities of Service
  (QoS) features may not be supported
• Interoperability is not seamless
• Proprietary Solution
• No integrated development tools

15
Distributed Bridge
16
Distributed Bridging

• Advantage
• Customization may be easier to address specific
  requirements
• Disadvantage
• Intrusive to the back-end
• Additional Development will be needed
• Poor Performance
• Bridge must act as translator between .NET and
  J2EE CORBA environments
• Security, Transactions, and Qualities of Service
  (QoS) features may not be supported
• Interoperability is not seamless
• Proprietary Solution
• No integrated development tools

17
Messaging
JMS Message Queue
CORBA Message Queue
18
Messaging

• Advantage
• Coarse-grained solution
• Support for Security, Transactions and Qualities
  of Service (QoS) features
• Disadvantage
• Performance
• Synchronous only solution
• Message Latency
• Communications across Firewalls
• Translations need to take place in the Messaging
  engine

19
On-The-Wire (IIOP) Janeva!
Janeva is inherently part of the .NET application
itself
20
On-The-Wire (IIOP) Janeva!
JMS Message Queue
CORBA Message Queue
21
On-The-Wire (IIOP)

• Advantage
• Fine-grained solution
• Performance
• Support for Security, Transactions and Qualities
  of Service (QoS) features
• Integrated developed tools are available
• Support for both synchronous and asynchronous
  communications
• Makes .NET applications Trilingual to talk to
  J2EE and CORBA
• Disadvantage
• Clients and Servers must support the wire
  protocol
• Affected by changes to the version of the
  protocol

22
What are some other solutions?
23
Janeva Easy for .NET Developers
24
Developing Web Services in .NET
Deploy
25
Developing with Janeva in .NET
Deploy
26
Whats In Janeva?
27
Inside Janeva

• Supported Platforms
• DiamondBack (Delphi for .NET and CBuilder)
• Borland Enterprise Server 6.0
• Borland Enterprise Server 5.x
• WebLogic 7.0
• WebLogic 8.1
• WebSphere 5.0
• Oracle9iAS
• Visual Studio for .NET 2002 and 2003
• Client Activated Object (CAO) Abstraction over
  EJB Factory Design patterns
• Portable Interceptors (PI) based on OMG
  specification

28
More Inside Janeva

• .NET style configuration using configuration
  files
• Comprehensive Data Type and Exception support
  (over 250)
• Native Java data type mapping
• CORBA IDL data type mapping
• Effective and Efficient Data Marshalling and
  Demarshalling
• Based on Borland Enterprise Server Technology
• Full Server side (Callback) support
• Portable Object Adaptor (POA) based servers
• .NET Remoting style Servers
• .NET Remoting style Transient Objects
• Security
• Full CSIv2 support for interoperability
• Support for SSL client and server
• Client authentication using username/password
• Client authentication using certificates
• Server authentication using certificates

29
Why Janeva?
30
What does Janeva provide you with?

• Seamless interoperability
• No changes to the back-end
• No additional development needed for connectivity
• Transparent and non-invasive implementation
• Lower Total Cost of Ownership
• Leverage existing platform investments
• No additional technical infrastructures needed
• No additional training required
• Low Impact and Low Risk
• High levels of performance with existing
  infrastructures
• Lowest cost for front-end maintenance shorter
  development lifecycle
• Adheres to existing technical standards
• Ease of Use
• Leverage existing development skill sets
• .NET developers not required to know other
  technologies
• Tight integration with .NET IDEs

31
Borland Janeva

• Thank You

32
Janeva compared to Bridging

• J.P. Morgan on Bridging solution (Ja.NET)
• Ja.NET has 3 significant failings
• 1) Its not a pure Java solution in that it
  requires that an MS machine equipped with .NET
  is available at system build time. This is
  problematic for controlled batch and Unix
  builds.
• 2) Its not dynamic/transparent. You can't
  connect to servers 'adhoc from the desktop.
• 3) Its using the .NET Remoting protocol - not
  IIOP. Remoting lacks security (important), fail
  over (important) and transaction context (less
  important) information. IIOP would be better,
  since its the open standard.

33
Janeva compared to Web Services?

• Eric Newcomer, Chief Technology Officer, IONA
  Technologies
• Web services standards themselves are lacking
  in features compared to .NET and J2EE.
  Therefore, you can use Web Services for basic
  interoperability, but not for building
  applications with a combination of .NET and J2EE
  components yet, at least, not without sacrificing
  significant functionality.
• Jim Farley, author of Java Distributed Computing,
  coauthor of Java Enterprise in a Nutshell
• The SOAP specification contains no mention of
  security facilities. This is not a good thing.
  One of the advantages of SOAP is that it runs
  over HTTP, which eliminates firewall problems.
  Well, firewalls are there for a reason. No
  enterprise will want to open up a channel to make
  direct, unprotected method calls on their Web
  services.