Dev381.Pp

DEV381 .NET and J2EE: Strategies for Interoperability When you just know you're gonna need it

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

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

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

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

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

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!

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.

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)

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

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

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

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

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

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

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

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();

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

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

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?

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

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?

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);

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);

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"

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

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>

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);

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

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?"

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

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

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)

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

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

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)

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

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?

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

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

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

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

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

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

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"

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

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

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

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

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

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

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

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)

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

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)

Dev381.Pp

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to Dev381.Pp (20)

More from Severus Prime (20)

Recently uploaded (20)

Dev381.Pp