DEV381 .NET and J2EE: Strategies for Interoperability

1
DEV381.NET and J2EE Strategies for
Interoperability

• When you just know you're gonna need it

2
Credentials

• Who is this guy?
• Independent consultant (Sacramento, California)
• Editor-in-Chief, TheServerSide.NET
  (www.theserverside.net)
• Author
• Server-Based Java Programming (Manning, 2000)
• Effective Enterprise Java (Addison-Wesley, 2Q
  2004)
• C in a Nutshell (with Drayton, Albahari
  OReilly, 2001)
• SSCLI Essentials (with Stutz, Shilling OReilly,
  2003)
• Microsoft Valued Professional (MVP)
• BEA Technical Director
• Member, JSR 175 Expert Group
• Instructor, Course Author, DevelopMentor (.NET
  Java)
• ".NET and J2EE Interoperability"
• Website at www.neward.net/ted

3
Why interoperability?

• A (purely fictitious) story
• Our hero you
• Our villian your boss
• The setting an otherwise uneventful staff
  meeting
• The hook "Oh, by the way, we need to meet with
  the HR department we've been tasked with
  building some code to integrate our purchasing
  system with their employee system to streamline
  expense reports."
• The plot twist Their system is J2EE-based, yours
  .NET (or vice versa, take your pick)
• The tragedy "Oh, and we got the assignment a few
  months ago, I just forgot to tell you. We ship
  two weeks from now."

4
Why interoperability?

• Making two systems on different platforms work
  together
• 3 basic approaches one can take
• Migration
• Rewrite everything from one system in the other
  platform
• Takes a lot of time, effort and money
• ROI of doing so is dubious
• Portability
• Take the existing source code and cross-compile
  (C/C)
• Keeps a single source base
• The only Java/.NET way to do this is through
  J.NET/JLCA
• Severe limitations on the portable code

5
Why interoperability?

• Interoperability seeks to reuse existing code w/o
  change
• "Interoperability enables communication, data
  exchange, or program execution among various
  systems in a way that requires the user to have
  little or no awareness of the underlying
  operations of those systems." (ISO Information
  Technology Vocabulary)
• "If it ain't broke, don't fix it"
• in the case of Java and .NET, it means
• Java calling .NET code
• .NET calling Java code
• all while minimizing the pain of doing so

6
Why interoperability?

• Reuse of existing systems
• legacy systems have their place
• Delivery based on technical merit
• there's things that J2EE does better than .NET,
  and vice versa
• not all technology makes it to both places
• Pilot for adoption
• zero-to-widespread-use usually requires trials
  and pilots
• Migration isn't atomic
• can't "flip the switch" overnight and go from one
  to the other

7
Return to basics

• Go back to first principles "n-tier design"
• 3 tiers (physical hardware points) client,
  middleware, resource
• 3 layers (logical separation) presentation,
  logic, data storage
• Mental note don't confuse the two!

8
3 Tiers

• Client tier
• machine/device in front of the user
• PC, Blackberry, PocketPC, Palm, etc.
• Middleware tier
• most often an off-resource processing tier
• "gather point" for centralization of resource
  usage by clients
• server to which client devices connect (usually
  through firewall)
• Resource tier
• some resource (data repository, most often) of
  interest to us
• database, legacy mainframe, hardware control
  device, etc.

9
3 Layers

• Presentation layer
• responsible for the elements used to display data
• in thin-client apps, generates and sends back the
  HTML
• or, could be a Java WebStart- or
  Click-Once-deployed GUI
• Business layer
• represents the business processing that's
  UI-independent
• what most people are referring to when they say
  "middle tier"
• where most domain-specific programming goes
• Data access layer
• code used to access the resource tiers (database)
• often deployed with business layer code not
  always (sprocs)

10
3 Tiers, 3 Layers

• Layers don't map to Tiers 11
• in traditional thin-client system, presentation
  layer is split across client tier (browser) and
  middle tier (web server)
• data access layer often lives on middle tier (app
  or web server)
• business layer can straddle all tiers
  (validation)
• This distinction is important to understand
• interoperability within layers is going to feel
  very different from interoperability across
  layers
• interoperability across tiers is almost always
  going to be cross-proc, where across layers it's
  not so clear

11
Interoperability points

• Interoperability can occur in several ways
• across layers presentation calling business
  logic, business logic calling data access, and so
  forth
• within layers presentation calling other
  presentation code, business logic calling other
  business logic
• classic examples
• .NET WinForms app calling J2EE app server
• Outlook plugin calling J2EE app server
• J2EE calling COM/EnterpriseServices
• J2EE servlets, ASP.NET sharing session state

12
Interoperability points

• Interoperability essentially comes in three forms
• in-process both platform code running
  side-by-side in-proc
• out-of-process communicating across the network
• resource tier simple data exchange through
  resources

13
Interoperability points

• XML and Web services
• obviously Web services and XML play a role here
• XML is the ubiquitous data-exchange format
• Web services leverage XML to enable interop
• but not all interoperability uses Web services
• example servlets/JSP ASP.NET sharing session
  state
• example GUI apps that must host
  components/controls (Swing app hosting native web
  browser)
• example single security token across sites

14
Interoperability points

• XML and Web services
• problem Web services specs and/or
  implementations not ready for prime-time use yet
• WS-Security
• WS-Transactions
• WS-ReliableMessaging
• problem XML is hierarchical data, not objects
• cyclic graphs of objects will throw fits
• not all Web service platforms use objects!
• problem all Web services assume cross-process
  semantics
• expensive to move across the network
• usually implies multithreaded/reentrant access

15
Interoperability points

• XML Web services are "tomorrow's interop"
• it's clear the future belongs to the
  angle-bracket crowd
• but a lot of that infrastructure just doesn't
  exist
• XML Web services are "n-platform interop"
• where n is a large number ( 2), there's no other
  way to go
• where n 2 (Java and .NET), other options are
  possible

16
J2EE/.NET Interoperability

• In-process interoperability
• Java and the CLR coexisting in the same process
• "JNI meets Managed C"
• Data exchange
• using XML as the data-exchange format
• .NET XSD.exe and XmlSerializer
• Java Java API for XML Binding (JAXB)
• RPC and WSDL
• binary RPC toolkits like JaNET, JNBridge, Janeva,
  IIOP.NET
• WSDL is often used as IDL-with-angle-brackets
• Messaging
• JMS, MSMQ, Simple messaging

17
Data Exchange

• We start from this
• And we want to send it from one system to another
• from client to resource (database)
• from resource to client
• from processing layer (transaction server) to
  resource
• from resource to processing layer
• and so on

public class Stock public String name
public String tickerSymbol public float
closePrice public int sharesOwned Stock s
new Stock()
18
Data Exchange

• Challenges
• data elements in .NET/Java fall into three
  categories
• primitive data types
• strings, 32-bit unsigned integers, IEEE-standard
  floats, etc.
• some are isomorphic (32-bit int is a 32-bit int)
• some aren't java.lang.String's layout
  System.String's?
• complex data types
• data types made up of a composition of other data
  types, including other complex data types
• heart of the object-oriented practice
• incompatible types
• some platform types have no equivalent in the
  other space
• System.TimeSpan, java.util.TreeSet

19
Data Exchange

• Challenges
• Three basic "formats" we can store data to
• text human-consumable ASCII 7-bit "clean" values
• binary anything not textual in nature
• resource database, legacy storage, etc

Stock s new Stock("MSFT", "Microsoft", 52.5,
100)
MSFT, Microsoft, 52.5, 100
AE56757478FF00EAE356738125...
20
Data Exchange

• Challenges
• which do we support binary or text?
• text is human-readable, easy for diagnostics and
  debugging
• text is easier to parse by systems foreign to our
  own
• binary is native to the machine, easy for machine
  to emit/consume
• binary requires less "translation"
• short answer "gee, we kinda want both"
• and do you really want to write the code to
  emit/parse both?

21
Data Exchange

• In essence, we want transparent transformation of
  objects to some kind of out-of-memory format
  Serialization
• supported by both .NET and Java
• requires minimal support from programmer to
  "opt-in"
• Java type must implement marker interface
  (Serializable)
• .NET type must annotate custom attribute
  (Serializable)
• from there, libraries and runtime can handle the
  rest
• understands primitive data types intrinsically
• walks the complete graph of object references
• handles circular references transparently
• makes using Serialization (deceptively) easy

22
Serialization

• Challenges
• Java and .NET binary serialization formats are
  incompatible
• shouldn't come as a major surprise -)
• Java big-endian, .NET little-endian (just for
  starters)
• thus, binary serialization data exchange doesn't
  work
• well, not exactly true both platforms support
  custom serialization "hooks" that could be used
  to make it work
• this is a formidable amount of code to have to
  write
• we hate to give up on the ease of the
  serialization approach
• so let's just change target formats XML
• XML is the Great Interop Format, so we're done,
  right?

23
Serialization

• XML Serialization .NET
• System.Xml.Serialization.XmlSerializer

public class Stock // . . . details
unimportant
Stock s new Stock() XmlSerializer ser new
XmlSerializer(typeof(Stock)) FileStream fs new
FileStream("stock.xml", FileMode.Create) ser.Seri
alize(fs, s)
XmlSerializer ser new XmlSerializer(typeof(Stock
)) FileStream fs new FileStream("stock.xml",
FileMode.Open) Stock s (Stock)ser.Deserialize(f
s)
24
Serialization

• XML Serialization Java API for XML Binding
  (JAXB)
• javax.bind.

public class Stock // . . . details
unimportant
Stock s new Stock() JAXBContext ctx
JAXBContext.newInstance("com.test.Package") Marsh
aller m ctx.createMarshaller() FileOutputStream
fs new FileOutputStream("stocks.xml") m.marsha
l(s, fs)
JAXBContext ctx JAXBContext.newInstance("com.tes
t.Package") Unmarshaller m ctx.createUnmarshall
er() FileInputStream fs new FileInputStream("st
ocks.xml") Stock s m.unmarshal(fs)
25
Serialization

• Challenges
• unfortunately, the story doesn't stop here
• too easy to serialize incompatible types
• .NET XmlSerializer only serializes public
  properties
• JAXB has similar problem
• XmlSerializer provides attributes to control
  serialization
• to use effectively, you have to know
  XmlSerializer behavior
• JAXB uses package descriptors to control
  serialization
• to use effectively, you have to know JAXB's
  behavior
• In short, you have to know both sides' behavior
  well in order to customize the XML output
  appropriately for all types
• this is a lot of work!
• would be easier if we could start with something
  "neutral"

26
Schema

• Schema provides metadata (data about data)
• in relational databases, schema defines
  relational tables and relationships between the
  tables
• in XML, schema (XSD) defines XML types and their
  contents
• XML parsers can verify documents against schema
• XML tools can ensure proper format and content
• tools can generate producer/consumer code

27
Schema

• Example schema

? XMLSchema.xsd" elementFormDefault"qua
lified" xmlns"http//tempuri.org/XMLSc
hema.xsd" xmlnsmstns"http//tempuri.
org/XMLSchema.xsd" xmlnsxs"http//www
.w3.org/2001/XMLSchema" name"Stock"

type"xsstring"/ name"Price" type"xsfloat"/


/
28
Schema

• Schema-based data exchange .NET XSD.exe
• xsd.exe generates classes from schema (/c option)
• annotates classes with XmlSerializer attributes
  as necessary
• supports most schema types

XmlSerializer sz new XmlSerializer(typeof(Stock)
) // Stock generated by "xsd.exe /c
stock.xsd" Stock s new Stock() s.Ticker
"ACME" s.Name "Acme Corp" s.Price
5.25 FileStream fs File.Open("acme.xml",
FileMode.Create) sz.Serialize(fs, s)
29
Schema

• Schema-based data exchange JAXB
• tool usually provided to generate code from
  schema
• JAXB originally (0.7 and earlier) used custom
  format, had no schema support
• JAXB 1.0 supports schema
• important note JAXB is specification, not
  implementation
• other vendors may use differing tools
• all should conform to APIs described by JAXB
• JAXB Reference Implementation available from Sun

30
So are we done?

• Not quite
• data exchange is useful for simple scenarios
• but more complications arise as we get more
  sophisticated
• shared session state across ASP.NET
  servlets/JSP
• in-process execution between WinForms Swing
• and so on
• "So how do I know when to use which?"

31
The Ten Myths of Enterprise Computing

• "Essentially everyone, when they first build an
  enterprise application, makes the following 10
  assumptions. All turn out to be false in the long
  run and all cause big trouble and painful
  learning experiences."
• 1) The network is reliable
• 2) Latency is zero
• 3) Bandwidth is infinite
• 4) The network is secure
• 5) Topology doesn't change
• 6) There is one administrator
• 7) Transport cost is zero
• 8) The network is homogeneous
• 9) The system is monolithic
• 10) The system is finished

32
Myths in detail

• 8 The network is homogeneous
• you're in this class because you realize this
  already
• again, most of the time, interop means J2EE/.NET
• do you know that anything else will be used?
• more importantly, are you going to willingly
  accept the overhead and implicit cost of adopting
  a Web service base?
• Web services interop for n plaforms, where n
  2

33
Myths in detail

• 9 The system is monolithic
• might have been true in the days of C/C (static
  linking)
• impossible in the days of dynamically linked
  runtimes
• the platforms can and will change
• the components you use can and will change
• the containers you run can and will change
• even more irrelevant when you dont own or
  administer both (or all) ends of the pipe
• enterprise systems imply lots of players
• lots of players imply lots of different voices
  decisions
• it's always ideal if a company can select a
  baseline platform
• but recognize that Web services is just another
  platform
• (so was CORBA, or DCOM, or Java, for that matter)

34
Myths in detail

• 10 The system is finished
• projects that reach production never die
• for some reason, users keep wanting new features
• something about "raising productivity" or some
  nonsense
• hey, more work means you're still getting paid,
  right?
• part of what's never finished is the technology
  platform
• .NET and J2EE will continue to grow and evolve
• this means infrastructure is constantly changing
  (see 9)
• this in turn means interoperability will always
  be there

35
Basics

• Realize that the platforms create component
  boundaries
• loose coupling is the order of the day
• don't try to share object definitions across both
  platforms
• instead, prefer to exchange data
• keep boundary-crossings to a minimum

36
Basics

• Recognize the additional complexity you're facing
• easily an order of magnitude more complex than an
  all-Java/J2EE or all-.NET system
• factor in the necessary
• debugging troubleshooting time
• diagnostics support
• cost (if you look to commercial toolkits)
• topology and support (particularly security
  concerns)

37
Basics

• Understand that interoperability does not perform
  well
• sometimes you can get lucky and make it run fast
• but don't assume this will be the case
• cross-platform marshaling takes time
• low-endian to high-endian translations
• string representations
• and so on
• for this reason, try to take interop scenarios
  off critical-path performance scenarios

38
Basics

• Where possible, try to avoid interop within
  layers
• prefer presentation-to-logic or logic-to-resource
  interop
• presentation-to-presentation is a royal pain
• stateless presentation can be done with straight
  HTTP
• shared session state almost demands in-proc
  interop, or
• storing session state externally is usually
  cross-tier (ouch)
• logic-to-logic interop has curious semantics
• EJB calls COM do you expect 2PC transaction
  support?
• COM calls EJB do you expect call context
  causality?

39
Basics

• Where possible, prefer resource-tier interop
• it's the easiest means for exchanging information
• each side has well-defined, well-understood
  idioms for resource access and update
• filesystem-based exchange
• relational database
• XML serialization can be of great help here
• again, start with XSD to ensure best portability
• consider J for these types to allow for
  single-source maintenance if you want to make
  them "domain objects"
• problem will come with request/response semantics

40
Presentation/Presentation interop

• Thin client options
• Servlets hosting ASP.NET via System.Web.Hosting
  invoked via MC JNI DLL
• write servlet filter to replace standard servlet
  HttpSession and ServletRequest/ServletResponse
  objects
• write ASP.NET host code to access servlet objects
• ASP.NET hosting servlet container
• not recommendedservlet containers heavierweight
• Neither hosts anything share session state via
  resource tier
• expensive session state access
• but you should minimize session state usage,
  anyway

41
Presentation/Presentation interop

• Smart/Thick/Rich client options
• Swing hosting WinForms Really Bad Idea
• Swing does all of its own painting, Z-order, etc.
  (1 HWND)
• will not play well with "heavyweight" WinForms
  widgets
• (doesn't play well with "heavyweight" AWT, for
  that matter)
• WinForms hosting Swing approachable, but
• each assumes it has its own message loop
• mixing the two is likely to cause problems over
  time
• SWT and WinForms
• SWT uses native USER32 functionality, like
  WinForms
• HWNDs, ActiveX access possible (but not easy)
• best bet is to not mix on single HWND spawn
  top-level windows, dialogs where possible

42
Presentation/Business Logic interop

• .NET Presentation to J2EE Business Logic
• most likely scenario of all interop possibilities
• J2EE back-end infrastructure currently dominates
• .NET front-end infrastructure currently dominates
• EJB follow J2EE rules
• never access entity beans directly from client
• treat beans as opaque services, not objects
• probably best to use IIOP tools to access J2EE
• no change in J2EE footprint required
• servers have had this (debugged) for some time
  now
• allows for easier diagnostics (via Java/IIOP
  clients)
• future use messaging/JMS/SOAP/Message-Driven
  Beans
• best scalability, evolution possibilities
• easy to adopt in basic forms using data exchange

43
Presentation/Business Logic interop

• Java Presentation to .NET Business Logic
• binary RPC proxies to COM servers
• requires out-of-proc call and activation modes
• in-proc MC JNI DLL calls to COM objects
• allows for either in-proc hosting or out-of-proc
• can't run on non-Windows clients
• COM SOAP Activation semantics
• security concerns
• starting-from-.NET type mismatch concerns
• Swing/SWT/AWT zero difference between them
• Servlets easier to do JNI, since it's
  server-based
• be careful of COM impersonation, or you'll be
  running with servlet container authentication
  credentials

44
Business Logic/Business Logic interop

• J2EE calling COM
• best bet is probably SOAP Activation approach
• hosting JNI DLLs in J2EE servers is tricky
• if RPC toolkit has zero native footprint, might
  be doable
• almost guarantees out-of-process connection
• or, create a front-end channel to the COM
  component
• web service or remoting target (IIOP, preferably)
• more work, more maintenance
• be careful of security concerns
• remember, don't rely on the firewall or HTTP/S
• assume insecurity

45
Business Logic/Business Logic interop

• COM calling J2EE
• best bet is probably IIOP approach
• interfaces are tightly-coupled anyway
• better reliability from IIOP than J2EE web
  services right now
• if JMS vendor has .NET bindings, use those!
• as said before, Message-Driven Beans give best
  scalability
• again, remember security
• J2EE access (almost) always out-of-proc
• J2EE has no concept of "call context"

46
Business Logic/Data Access interop

• Generally no reason for .NET business logic
  component to call Java data access (or vice
  versa)
• one exception might be legacy systems (3270
  terminals)
• J2EE has rich "Connector" API for "external
  access"
• probably best accessed through stateless session
  bean front

47
In-proc interoperability

• Due to complexity of in-process interop, avoid
  when possible
• that said, certain scenarios will demand it
• sharing session state (ASP.NET and servlets)
• hosting controls in a GUI app
• ManagedC is probably the best route to take
• unmanaged MC code handles JNI well
• consider JACE (http//jace.sourceforge.net)
• be very careful of unmanaged threads, though
  prefer to use the managed threading APIs whenever
  possible
• for best results, build, buy or download
  "wrapper" libraries
• build JMS wrappers for messaging access
• (http//active-jms.sourceforge.net), for example
• do the same for Java access to MSMQ

48
Binary RPC

• RPC is a tightly-coupled step
• understands object references across the network
• clearly an easy way to maintain state across
  calls
• well-understood by object-oriented programmers
• due to identity, doesn't scale well
• concurrency concerns multiple clients accessing
  concurrently
• evolution concerns changing types on both ends

49
Binary RPC

• CORBA/IIOP protocol
• has advantage of native bindings to
  J2EE-compliant servers
• Janeva, IIOP.NET provide good bindings
• distinct disadvantage of being "out of favor" in
  industry
• SOAP/HTTP protocols
• a number of toolkits offer bindings over
  HTTP/SOAP
• uses WSDL-as-RPC, which is deprecated and a Bad
  Idea

50
WSDL ! Distributed Objects

• Despite its apparent similarities, don't use it
  as RPC
• remember, not all languages are O-O (for good
  reasons)
• never generate WSDL from language interfaces
• for the same reasons, never use rpc/encoded
  bindings
• use it solely to describe message-based services
• look for WSDL 1.2/2.0/v.Next to ship sometime in
  2004

51
Messaging

• Messaging represents best bet for
  interoperability
• "context complete" communication approach
• in WSDL, this begins with doc/literal
• extended by WS-Security friends
• in essence, capture everything needed in one
  logical packet
• allows for async communications
• remember, interop is expensive
• adds Quality-of-Service capabilities (Myth 1)
• reflected well in all platforms
• JMS
• MSMQ
• SOAP, WS-ReliableMessaging, WS-Eventing,
• allows for higher-order mechanisms
• WS-Routing, WS-Referral, etc

52
Messaging

• Interoperability advantages
• crossing platforms is relatively trivial
  Messaging Bridge (133)
• moving to a different channel Channel Adapter
  (127)
• easy interception-like behavior Detour (545),
  Wire Tap (547)
• better scalability due to lack of object identity
• quality-of-service assurances Guaranteed
  Delivery (122)
• evolution support Messaging Mapper (477)
• prioritization
• transactional semantics

53
Web services

• Remember, "here there be dragons"
• Web services are obviously the future direction
  of interop
• future isn't guaranteed to be pleasant, however
• vendor relations are crucial remember CORBA?
• what degree of "standardization" is necessary?
• when will the "future" "today"?
• when we get there, will it resemble what we
  predicted? (witness J2EE/EJB, for example)

54
Web services

• Remember, XML is always applicable w/o "Web
  services"
• REST is a simplistic, straightforward model
• simplistic ! "easy", though
• lots of work required on your part over time
• email as a messaging architecture, too (REST-ful
  mail?)
• be careful not to assume that XML objects
• as discussed, XML/object marshaling is not always
  easy
• use XML "at the edges" of components, not as
  objects
• XML through the resource tier
• example SQLServer Yukon Reporting Services does
  XML
• example database stored procs returning XML
• filesystem messaging

55
Summary

• Interoperability scenarios can be designed or
  refactored
• requires that you keep "channels" separate from
  "logic"
• think of "presentation" as a channel and you're
  not far off
• keep coupling loose across layers
• prefer messaging to RPC for scalability,
  evolution flexibility
• Remember, this is bleeding-edge stuff
• the moral of the story is, "Risk Management"
• lots of research
• lots of "spikes"
• lots of cynicism take no vendor at their word
• even to the point of distrusting these slides
  (until proven)

56
(No Transcript)