Application Interoperability: Microsoft .NET and J2EE

Discussions

News: Application Interoperability: Microsoft .NET and J2EE

  1. Application Interoperability: Microsoft .NET and J2EE presents interoperability best practices, and illustrates these approaches with a functional sample application. It shows how to link Microsoft .NET and J2EE, using Web services, runtime bridges, and asynchronous techniques.

    This guide is aimed at developers who are responsible for creating and implementing enterprise level business applications based on either Microsoft .NET or on J2EE and where interoperability between the two platforms is a requirement.

    This guide is written for readers in one or more of the following categories:

    - The sections targeted at .NET developers assume an understanding of the development process for distributed applications and familiarity with the Microsoft Visual Studio® .NET programming tools. The sample applications are in C# (C Sharp), so development experience in this language is essential. Experience with the .NET Framework SDK and the MSDN® Library are also of benefit.
    - The sections targeted at Java developers assume a familiarity with Java programming methods and tools, in particular Enterprise Java Beans (EJB) and Java APIs such as Java Naming and Directory Interface (JNDI) and the Java Messaging Service (JMS).

    Read Application Interoperability: Microsoft .NET and J2EE in the Patterns and Practices area of MSDN.

    Threaded Messages (20)

  2. Not very useful[ Go to top ]

    The only thing that is of any interest for java developers here is the little bit on utilizing web services as the integration method. But all examples require the GLUE engine to reproduce. I have tried to follow the interoperability examples utilizing the apache axis engine with little success. Essentialy microsoft admits to limitations in their Web Service framework and recomends that if you want to send services to a .net client you must send only very simple objects such as a single string or integer response. As soon as you try to send a response with a complex xml schema ( i.e. anything with a heiarchy of xml nodes ) it will fail to bind the response to any .net objects. Microsoft's solution to this

    ---- quote ----
    ...rather than return the Java data types, you should return strings. The Web service therefore should convert any Java data types into strings containing XML...
    ---- quote ----

    you then must create .net objects to consume this string representation of xml and load a DataSet from it. This is ok if you have to do it like this but it does not comply with the w3c and it's messy... I hate messy stuff!
  3. Not very useful[ Go to top ]

    Well you've uncovered one dirty secret about web services, that is you get ease-of-use if you want to sacrifice interoperability.
  4. Web Services as Application interoperability mechanism is a big joke. Are you saying that bloated XML and even more bloated SOAP should be used for interoperability between applications? This is realy a good joke, :)

    Web Services communication is about order of magnitude slower when native RPC. All these XML has to be generated, then put on the wire over HTTP and finally parsed. And SOAP itself is pretty redundant, too.

    If you need true interoperability (not inter-wait-ability, :) ), you should use CORBA. There are several CORBA implementations for .NET, and countless for Java. And interoperability between different CORBA vendors had been significantly increased since the introduction of POAs and since mature ORB implementations that support POA has been released.

    So use CORBA if you can, and use WebServices when you must!
  5. Web Services communication is about order of magnitude slower when native RPC.

    Sure, but Moore's Law is on our side.

    If you need true interoperability (not inter-wait-ability, :) ), you should use CORBA.

    A couple things Xindice's architect had to say about CORBA-vs-XMLRPC:

    "...CORBA, which is to put it mildly, way too complex for most people. It also isn't well supported by a great many languages, especially scripting languages."
    -- http://xindice-xmlrpc.sourceforge.net

    "...I finally dug into the Xindice code again and converted it over to using XML-RPC for all network communications. While in the process I also yanked all the old CORBA code. ... Hopefully getting rid of CORBA will make the system much more stable. If nothing else it definitely makes it a lot easier to know what's going on. CORBA is a prime example of why complexity isn't good. It may be a binary protocol and in theory efficient, but it's so difficult to know what the ORB is doing that it's impossible to work with. Anyway, from my tests with XML-RPC vs CORBA, on identical reasonably complex test cases, there's little if any performance difference. In addition there's still tons of room to optimize what's going on with XML-RPC, whereas my attempts to optimize CORBA just led to frustration at the complexity of doing even the simplest things. Complex software standards simply are not worth it."
    -- http://radio.weblogs.com/0100213/2002/07/11.html
  6. Hi: Brain, Since XML-RPC is politically won the battle (thanks for web services buzz) there is no use to do more talks on CORBA and XML-RPC, even though in some situations one make more sense over other, but I never understand what makes XML-RPC much easier than CORBA.

    RPC is RPC, it doesn’t matter (as far as complexity goes) how you serialize the data (CDR, XDR, or Holy XML) and what kind of protocol (IIOP, JRMP, SOAP) you use, because at the end of the day these information are never meant to exposed to end users. You have objects or methods that you want to expose, be exposed it as an IDL or WSDL what is the difference, generate some stub and skeleton (all taken care of by the tools in both cases) and that is it. Yes, since CORBA evolves a lot, and it is in itself much more than a regular RPC, if you want to fully utilize the CORBA component model and all it’s functionality and services, it is then become very complex. But if XML-RPC does all what CORBA offers, it will become too complex too. My 2 cents….
  7. RPC is RPC, it doesn’t matter (as far as complexity goes) how you serialize the data (CDR, XDR, or Holy XML) and what kind of protocol (IIOP, JRMP, SOAP) you use, because at the end of the day these information are never meant to exposed to end users.

    Oh, but these specifics do matter very much if you hope to apply multicasting, pipelining, relaying, or tunelling. Sometimes human readability also matters for debugging. Web service won due to technical merit.
  8. Web service won due to technical merit.


    Web Services won because Microsoft wouldn't support CORBA.


    (and I echo Rashid's comments on this. CORBA just isn't that hard)

    Now if you want to see a *really* sweet RMI implementation have a look at the Jini Extensible RMI (JERI) stuff in Jini 2.0. Everything is fully pluggable:

    - Plug in new transports: TCP, HTTP, JXTA, Kerberos, etc.
    - Plug in new funky marshalling schemes (for example, you can pass in an extra implicit argument for each method call)
    - Supports per-method security constraints (example: the "getCatalogItem" method can be unencrypted, the "sendCreditCard" method needs to be encrypted).

    One of the sample JERI plug-ins supports transport aggregation. You can configure your service with multiple transports (in memory, TCP, http, etc.) and the client will use the best available transport.

    The other neat thing is all the configuration for this stuff is taken out of your code and put in a very simple configuration file (has a Java like syntax - none of this icky XML :-) ). Changing your service from TCP to HTTP is a matter of changing one line in a config file.

    Compare the capabilites/features of JERI vs. SOAP (plus associated alphabet soup of XML standards) and you really have to question if the industry has taken a wrong turn.
  9. Brian,

    1. I would really like to know what "technical merit" you are referring to - and please just don't regurgitate the party line about avoiding firewall's or that the format is human readable - both of these arguments are facile at best.

    2. Moore's Law applies to computing power - not bandwidth (which is the primary bottleneck in remote/distributed computing). Furthermore, the marshalling overhead associated with RPC or Web-Services is trivial compared to bandwith or network latency issues so I really dont understand how Moore's Law relates to the issue at hand.

    3. As for the URL's posted on Xindice I can only think of one thing to say - Who cares? It wouldn't exactly be rocket science to troll up just as many references that say the complete opposite of those 2 sites. Was there some original comment or opinion you wanted to add to these posts or was it more of a "Ah-ha I found a web-log that says CORBA is complex !!! - better post it" moment?
  10. I would really like to know what "technical merit" you are referring to - and please just don't regurgitate the party line about avoiding firewall's or that the format is human readable - both of these arguments are facile at best.

    Web service is better than CORBA at multicasting, pipelining, relaying, tunelling, debugging, and scripting. WSDL is "a semantic superset of IDL".

    Scripting integration is interesting, because so much of the Web's transmitted logic is inlined scripting. Take for example Clarens, a CalTech project: "The Clarens Grid-Enabled Web Services Framework is a wide-area network system for collaborative analysis of data generated by the Compact Muon Solenoid (CMS) detector at the European Organization for Nuclear Research, CERN." Clarens considered CORBA but chose XML-RPC since XML-RPC could be used by an ordinary Web browser with some JavaScript.

    <1>Moore's Law applies to computing power - not bandwidth (which is the primary bottleneck in remote/distributed computing).

    Compression allows me to trade cycles for bandwidth, so Moore's Law affects networking. Also "Nielsen's Law of Internet bandwidth states that a high-end user's connection speed grows by 50% per year."

    As for the URL's posted on Xindice I can only think of one thing to say - Who cares? It wouldn't exactly be rocket science to troll up just as many references that say the complete opposite of those 2 sites. Was there some original comment or opinion you wanted to add to these posts or was it more of a "Ah-ha I found a web-log that says CORBA is complex !!! - better post it" moment?

    You're gassing. I doubt you have proof that anyone of significance in the open source community on par with an Apache project architect has touted CORBA as worth embracing today. I relayed that such a person took the time to explain why CORBA was dumped in favor of XML-RPC.
  11. 1. "WSDL is a sematic superset of IDL" - IDL and WSDL are not directly comparable. IDL is simply used as a vehicle for generating marshalling code, CORBA has an abundance of other services that are layered on top of and around this basic mechanism in order to support other real-world requirements (transactions, security etc). WSDL may be a superset of IDL but CORBA is a superset of WSDL and Web Services.

    2. Regarding technical merit:
    (a) Multicasting - largely irrelevant to service oriented applications. Client talks to server, server responds end of story. I assume you weren't talking about using web services to implement a mail relay or IRC server ? This capability is provided by TCP/IP.
    (b) Pipelining - nothing more than short lived persistent connections. Can be less efficient on unrelaible connections where endpoints close prematurely. This capability is provided by HTTP.
    (c) Relaying - too broad a term to comment on. What types of relaying are you referring to?
    (d) Tunelling - true at the moment. More and more firewalls/routers etc are getting wise to HTTP tunnleing however so it wont be too long before this is irrelevant.
    (e) Debugging - well I suppose a text file is easier to debug with notepad than a binary stream. But no difference really if you have an appropriate tool.
    (f) Scripting - I prefer not to build enterprise applications that rely on JavaScript to run.

    3. "Compression allows me to trade cycles for bandwidth, so Moore's Law affects networking". Well yes - I don't believe I said anything to imply this wasnt true. I simply stated that the amount of time spent during compression/marshalling is generally an order of magnitude smaller that the time spent in transmission which means that the effect of computing power only has a minor impact on performance.

    4. On "Nielson's Law of Internet Bandwidth..."
    (a) Most users aren't high end users
    (b) Not everyone lives in the US
    (c) Please supply me with the ISP you use - I would love to get a 50% increase per year - hell I'd settle for the service just not getting worse every year.
    (c) Please find a more up-to-date reference since your link is almost 6 years old now.
  12. IDL and WSDL are not directly comparable.

    Interface description is essential to integration. Comparison of WSDL and IDL is apt and relevant to the broader evaluation of CORBA and web service. Stubborn denial doesn't change this.

    IDL is simply used as a vehicle for generating marshalling code, CORBA has an abundance of other services that are layered on top of and around this basic mechanism in order to support other real-world requirements (transactions, security etc). WSDL may be a superset of IDL but CORBA is a superset of WSDL and Web Services.

    So you say that IDL isn't the complete system, and then you proceed to criticize WSDL in isolation. I use WSDL with other integration standards such as XML Encryption, XML Signature, HTTP, CGI, and Servlets -- and there are more available. The XML messaging ecosystem is filled with machinery at least as capable as CORBA. If CORBA were as able in practice as it originally hoped to be, then web service would never have had an opportunity to emerge and surpass it. But CORBA has always had too many warts.

    Multicasting - largely irrelevant to service oriented applications.

    The essence of autonomic computing is redundancy. Here on TheServerSide there was recently discussed a paper about using JXTA (including multicasting) to use a service oriented architecture to enable autonomic job processing. In JXTA, multicasting can occur at the IP level and/or at the framework level.

    Pipelining - nothing more than short lived persistent connections. Can be less efficient on unrelaible connections where endpoints close prematurely. This capability is provided by HTTP.

    It's irrelevant that pipeling occurs at an HTTP endpoint. The chain-of-command design pattern valuably applies to more than HTTP processing.

    Relaying - too broad a term to comment on. What types of relaying are you referring to?

    The heart of the Internet is its routed store-and-forward architecture. Routing valuably applies at higher levels, and I had a JXTA relay peer in mind when I mentioned relaying as a unique benefit of messaging.

    Tunelling - true at the moment. More and more firewalls/routers etc are getting wise to HTTP tunnleing however so it wont be too long before this is irrelevant.

    You may speculate.

    Debugging - well I suppose a text file is easier to debug with notepad than a binary stream. But no difference really if you have an appropriate tool.

    Have you ever found a tool that illuminates an IIOP stream?

    Scripting - I prefer not to build enterprise applications that rely on JavaScript to run.

    That's your choice. I also personally shun JavaScript. But XML-RPC is very easy to broker, even by a silly scripting language. Simplicity and ease-of-use are very compelling competitive advantages. I don't doubt that folks on the Clarens and Xindice projects, who chose XML-RPC after learning CORBA, are smarter than I.

    I simply stated that the amount of time spent during compression/marshalling is generally an order of magnitude smaller that the time spent in transmission which means that the effect of computing power only has a minor impact on performance.

    That's yet another reason why the shift from CORBA RPC to XML messaging is so important. RPC sadly tends to encourage fine grained communication, that is heavily penalized on a wide area network. RPC is difficult to scale beyond a LAN. On this matter coarse grained XML messaging is a step in the right evolutionary direction. The EJB community adopted the value-object design pattern as a best practice. Value objects are used to transmit passive data in bulk to avoid fine grained communication -- exactly what an XML message does well. XML messaging is a best practice, and RPC is increasingly falling from favor.

    Most users aren't high end users

    Most users of distributed programs are.

    Not everyone lives in the US

    Ie, wide area network is a fact of life.
  13. Web Services <> Corba or RPC[ Go to top ]

    RPC is RPC

    I'm sorry to mention this Rashid, but if you state that Web Services is RPC, then you understand nothing about Web Services.
    Web Services are just doing the job, RPC supposed to do. But it does not mean these 2 are the same thing. Good thing about Web Services is that it does not have state. Same way as http talk between browser and webserver does not have state as opposed to RPC and in particular CORBA implementation. Modelling interoperation between 2 distributed objects same way as if they were on the same computer may look good and work good in laboratory, but not in real life.
    That's why Internet succeeded and CORBA not. Because Internet protocols (http) are built to work in loosely coupled environments, not to support stupid slogan "Network is Computer". Network is not a computer. Get real.
  14. Web Services <> Corba or RPC[ Go to top ]

    My dear friend vagif "I never said that webservices is RPC" all I said that webservices buzz flourished the concept of XML-RPC.

    BTW who decide what the webservices is, you and me, MS, IBM? The last time I checked, different people have different meaning for webservices.

    Now talk about the "state" thing. First of all, what makes you think that webservices doesn’t/shouldn’t have the state and RPC always have the state? And please tell me what is so good about not being "stateful"? What is wrong if in some very legitimate scenario I would rather store the state too? My dear friend the reason you think the web services doesn’t have the state and it is so good not having the state is because some "pundits" in the market told you so. The real reason behind that is the nature of the non-deterministic WAN and some other technical issues that I don’t want to get in.

    <-- Modelling interoperation between 2 distributed objects same way as if they were on the same computer may look good and work good in laboratory, but not in real life. -->

    I am amazed how you say that. In today’s world you cannot live and breadth with out RPC, look around and you will be amazed to see how many practical applications build on top of RPC. My 2 cents...
  15. Web Services <> Corba or RPC[ Go to top ]

    My dear friend vagif "I never said that webservices is RPC" all I said that webservices buzz flourished the concept of XML-RPC.

    >

    The bottom line is that Microsoft doesn't support Corba. I understand that this is a really hard to grasp concept, but try to take it "as is". It doesn't matter that "rpc is better in Corba". I fyou need to talk to MS products, what are you gonna do, start a fight with Bill and tell him to behave? Ridiculous.
  16. Web Services <> Corba or RPC[ Go to top ]

    I've got news for you. There is nothing for MS to support as it relates to CORBA. You can implement CORBA clients and servers on MS OSs all day and night.
    I got paid big bucks for doing just that a few years back. Take your "MS is the devil" glasses off and take a deep breath.
  17. Web Services <> Corba or RPC[ Go to top ]

    I've got news for you. There is nothing for MS to support as it relates to CORBA. You can implement CORBA clients and servers on MS OSs all day and night.

    > I got paid big bucks for doing just that a few years back. Take your "MS is the devil" glasses off and take a deep breath.

    Where did I say that "MS is the devil"? You got it completely in reverse, all I said is that is just a fact that MS doesn't support corba. Frankly I think that they have the right attitude(since it is just my opinion I don't think that any other debate is necessary).
    I got paid for using web services(that's the difference:-))
    Congratulations for getting rich.
  18. XML-RPC[ Go to top ]

    XMl-RPC is fast and light.

    .V
  19. I think that you should all read this: http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html

    According to this article, this most of this discussion is irrelevant because you are comparing Web Services to Distributed computing which is a totaly different thing. Both concepts have their place depending of what you are trying to achieve.

    Cheers,

    Noam
  20. I think that you should all read this: http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html

    Werner's analysis is very insightful, and he does expose some glaring flaws in the current WSDL specification. He says on that page: "Web services share none of the distributed object systemsÂ’ characteristics. They include no notion of objects, object references, factories, or life cycles. Web services do not feature interfaces with methods, data-structure serialization, or reference garbage collection."

    But Werner might not be familiar with the Global Grid Forum's Open Grid Service Architecture (promoted by IBM), which slightly extends WSDL to accomodate Werner's issues. WSDL is subject to continuing official revision by W3C. As for his concern with lack of "data structure serialization" -- SOAP has always had this.

    Have you heard of XSOAP? It runs RMI over SOAP, which belies the silly notion that web service can't provide distributed objects.
  21. I have a different take on what interoperation between J2EE and .NET applications entails. I submit that Web Services are a "top-level" or "end-point" integration solution while CORBA and RMI are "deep" integration technologies. All of these solutions are appropriate for different situations, and any discussion of one being inherently "better" than that other is a pointless endeavor. CORBA and RMI do a good job of providing deep integration in the form of object inter-change and they require that the developer create all of the application functionality from the ground up. In contrast, I would like to introduce xNova, which is a
    "deep" integration technology for J2EE and .NET but provides significant value with the functionality that it brings in a cross-paradigm (Java/C#) way.

    By way of example, xNova Cache provides the ability to mix languages, (C# and Java), on a variety of platforms, (MS, Linux, and Solaris) transparently to the respective applications. For instance, an application can have a native MS client application written in C# caching data and transparently participating in the cache cluster with the server side written in Java and deployed on a J2EE app server running on Linux. Further, the xNova Cache service, as with all of the xNova services, work identically in Java and C# and have an identical API.

    In this way, the functionality is in the forefront and the interoperation is an artifact of the architectural design of xNova and allows the developer to build applications which heretofore couldnÂ’t have been designed.

    Happy Holidays!
    Jon Webster
    Technical Director
    Fitech Laboratories Inc.