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 1:1 • 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.Serialize(fs, s); XmlSerializer ser = new XmlSerializer(typeof(Stock)); FileStream fs = new FileStream("stock.xml", FileMode.Open); Stock s = (Stock)ser.Deserialize(fs);

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"); Marshaller m = ctx.createMarshaller(); FileOutputStream fs = new FileOutputStream("stocks.xml"); m.marshal(s, fs); JAXBContext ctx = JAXBContext.newInstance("com.test.Package"); Unmarshaller m = ctx.createUnmarshaller(); FileInputStream fs = new FileInputStream("stocks.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: <?xml version="1.0" encoding="utf-8" ?> <xs:schema targetNamespace="http://tempuri.org/XMLSchema.xsd" elementFormDefault="qualified" xmlns="http://tempuri.org/XMLSchema.xsd" xmlns:mstns="http://tempuri.org/XMLSchema.xsd" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:complexType name="Stock"> <xs:sequence> <xs:element name="Ticker" type="xs:string" /> <xs:element name="Name" type="xs:string"/> <xs:element name="Price" type="xs:float"/> <xs:element name="Shares" type="xs:int"/> </xs:sequence> </xs:complexType> <xs:element name="Stock" type="mstns:Stock" /> </xs:schema>

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 don’t 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 recommended—servlet 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