Discussions

News: Java and .NET interoperability using CORBA

  1. Java and .NET interoperability using CORBA (33 messages)

    There are many products and solutions that deal with interoperability of Java and .NET.
    While the need for interoperability between Java and .Net has become a common problem in larger organizations, CORBA is often not the first choice of techniques for building a bridge between the two worlds. The lack of a commercially available CORBA implementation for .Net required a high up-front investment into this technology, resulting in significant increases in cost and time to market. Since the release of MiddTec's MiddCor earlier this year, this barrier has vanished. In this article, Christian Donner explores the fundamental concepts of using CORBA in a heterogeneous environment consisting of Java and .Net. The article features a simple application that implements object-level calls from Java to .Net in less than 50 lines of source code.
    Read Java and .Net interoperability using CORBA

    Threaded Messages (33)

  2. Very interesting! IMO CORBA is a great solution for J2EE and .NET interop if you dont want to use slow WEB services or propriatory (and sometimes expensive) third part bridges.

    Maris

    http://maris.site.lv/ejb.html
  3. Here is one LGPL alternative:

    IIOP.NET allows a seamless interoperation between .NET, CORBA and J2EE distributed objects.

    http://iiop-net.sourceforge.net/
  4. Hurrah! Now we come full cycle and ready to accept that CORBA makes a lot of sense. And that foolish “simplifications” like SOAP are next to worthless ( technically ).
  5. At last, we can ditch web services.

    SOAP = IIOP
    WSDL = IDL
    UDDI = COSNaming

    :-)

    -John-
  6. At last, we can ditch web services.SOAP = IIOPWSDL = IDLUDDI = COSNaming:-)-John-
    But then with proxy ports headaches, right? Do you opt for that instead?
  7. So, let's make sure I understand the a priori assumptions.

    Network staff blocked ports with firewalls thinking that makes flimsy operating systems and applications with open ports safer, and let through http, usually, but with proxies on the firewalls, so, because we don't want to deal with jumping through the hoops necessary to get new ports open, etc., we somehow decided to just circumvent the intent of the firewalls by using port 80 for all kinds of traffic, heck just make port 80 proxiable http carry *everything*, and now we realize that just maybe http is not the be-all and end-all for all communications.
    So, if I understand it, by "proxy ports headaches" you mean "the headache of following the intended procedures our own network staff has set up for traffic other than browsers to pass through their firewalls".

    I posit that problems arising from our own omphalos should be faced not eluded.

    -Tom
  8. Tom,

    I think you missed something. What if you're selling you application and/or distributing it to another company or even another branch of a single firm? I know that some of the companies I work for have different networking policies at different branches, but I can always rely on port 80 being open.

    Just a thought,
      Tyler
  9. Proxy headaches[ Go to top ]

    This is just something that is driving our it security guys nuts!

    You know, these guys like explicit application security. To them port 80 is ALWAYS a "browser port" and mostly disabled on internal servers. For application-to-application traffic they insist that we use a proprietary port. If an application should think that it can use port 80 to its pleasing, it is BANNED (oh well, more likely routed through a secure gateway or smthg.. more headache..).

    //ras
  10. No, I didn't miss anything, I am totally cognizant of all the same factors you are. Look at the big picture. More and more things use port 80. Then, Security guys make firewalls look into protocol, or block http without MSIE headers, etc. etc... The situation that port 80 is always open arises because it is used for browsers, which security decides to allow through. You change the use, you are changing what will get blocked and filtered. Big-picture wise, it is a stupid stupid direction to go. Yes, I know that the firewall-dmz situation is stupid in the first place, but that doesn't excuse acting and speaking as though it is part of god's gift to IT staff. You want to wait until there is a SOAP transported worm or other attack that gets some publicity for people to get it? The right answer is to use all 65K ports tha the RFCs give us, and explain to the network security people, in simple terms, using words of three syllables or less, why it is in their own best interest not to throw up walls that are too high to using them. -Tom
  11. At last, we can ditch web services.

    WSDL = IDL

    :-)

    -John-
    Is WSDL == IDL? Are you sure?
    http://www.sys-con.com/story/?storyid=44354&DE=1

    I guess that smiley means you were only half-serious?
  12. Is WSDL == IDL? Are you sure?http://www.sys-con.com/story/?storyid=44354&DE=1I guess that smiley means you were only half-serious?
    You're right, I wasn't entirely serious. I personally think WSDL is quite good, it's about the best part of WebServices trio there is and definately better than IDL. SOAP is just slow IIOP/JRMP/Serialized Java. UDDI is so crap it's and insult to even compare it to JNDI/CosNaming.

    My vote goes for WSDL + Serialized Java (Integration Objects)+ Distributed Naming Services like Jini's. :-) <-- Again though I add the smiley, I do not begin to pretend you can replace everything one to one. It is funny though to see CORBA back in the running for Java <-- --> .NET inter-op.

    -John-
  13. Is WSDL == IDL? Are you sure?http://www.sys-con.com/story/?storyid=44354&DE=1
    I have read that article several times and I must admit that I just don't get the distinction trying to be made between contract and interface. I have seen how RPC, DCE, CORBA, messaging systems, RMI, DCOM, .Net and Web Services specify interfaces and from a technical point of view I see nothing magical about WSDL as far as specifying the interface goes. I don't necessarily think deployment info belongs together with behavioural info but that is another aspect of WSDL. It seems strange that when I write a Java class and "click a button" to generate the web service from it as you can do in most of the current IDEs (or ISEs if you are into Gartner) that suddenly extra information is in the WSDL file which warrants it being called a contract. If I look at the UML generated from the Java class vs the UML generated from the Web Service they look the same!

    That doesn't mean the politics behind and tools built for web services aren't compelling - I just don't believe the hype which tells me it is further advanced than more mature middleware offerings.

    Paul.
  14. What abut Janeva?[ Go to top ]

    What planet is this guy on? Borland's Janeva has been out since last year (at least), and uses CORBA (it's derived from VisiBroker).

    Kito D. Mann
    Author, JSF in Action
    http://www.JSFCentral.com - JSF news, info and FAQ
  15. You are absolutely right ...[ Go to top ]

    But this guy did his homework. When I researched the article several weeks ago, Janeva 6 was not released yet. Prior to version 6, it did not provide bidirectional communication capabilities and could not be seen as a full-featured alternative.
  16. Janeva 6 release[ Go to top ]

    When you say "several weeks ago" how many do you mean?

    We use Janeva and version 6 went RTM in December 2003.

    ---
    Robert
  17. Janeva 6[ Go to top ]

    Robert, I wrote the article in March. I came across Janeva during the research and I read the specs on the Borland website at http://www.borland.com/janeva. At the time, the web site clearly stated that it only provided one-way communication capabilities. When I looked at the same site yesterday, it stated that one of the new features of version 6 is bidirectional interop.
     
    Don't forget that MiddCor is not a mere Java/.Net bridge, but a full CORBA 2 ORB written C#, which means that it opens up .Net to any other platform that supports CORBA, and there are many.
    The Java interop is only one aspect. I don't believe that Janeva is equally powerful.
  18. Janeva 6[ Go to top ]

    Christian,

    I am afraid you are quite mistaken about Janeva. Janeva has all the features of a CORBA 2.4 ORB. It supports all CORBA 2.4 features and can talk to any CORBA compliant application. Janeva has been so since its first version(w/ the exception of server side support which was added in 6.0). Not only does it support all that, it can *ALSO* talk to/from Java/J2EE applications.

    Some other salient aspects of Janeva.

    1. It supports all CORBA 2.4 features (in addition to the features that similar solutions provide)(Portable Interceptors, QoS, Transactions, Security (CSIv2)+ SSL, Valuetypes, RMI-IIOP, Firewall traversal)
    2. It is based on Visibroker technology which is a very robust, mature, standards compliant implementation (i.e not a brand new implementation) and one of the most widely deployed CORBA ORBs in the world.
    3. It supports all advanced Visibroker functionality as well.
    4. It supports CORBA,J2EE as well as .NET Remoting programming models seamlessly (ie. you can use any programming model, the one you are most familiar with for example, to program your .NET application independent of what you are talking to/from (CORBA/Java/J2EE)).
    5. It has a very rich datatype mapping layer that can support mapping built in Java framework classes to .NET framework classes. In addition, it supports customization of this mapping including custom marshaling to allow for new user defined mapping.
    6. It has tight integration with .NET IDEs such as Visual Studio.NET and Borland C# Builder
    7. The development license for Janeva is FREE!

    In summary, It provides an extremely rich environment in .NET to program with and take advantage of CORBA *AND* Java/J2EE.

    You may want to take a closer look at Janeva :)

    Vijay
    Janeva Team@Borland Software Corp
  19. Are we gradually going back to the good old days? :)
  20. New does not mean better. We do not neglect Pythagorean Theorem on the ground that it is old, do we?
  21. Pythagorean[ Go to top ]

    Pythagorean sucks. I use XML for all of my geometry now.
  22. DotNetJ is a tool that gives .NET applications the ability to use Java components or J2EE applications as if they were .NET assemblies. DotNetJ can either access any Java library with its built-in J2SE server, or can link to J2EE applications.

    http://dotnetj.objectweb.org
  23. This is why I get so unexcited about Web Services. Most developers use webservices for interoperability when CORBA, an older, more mature technology, is a better choince. CORBA is faster, is designed to support transaction and security propagation, supports failover (multiple endpoints within IOR), and is a better overall architecture.

    Sure, CORBA is a complicated solution, but so are webservices and WSDL, etc... IMO, webservices should never have gone beyond http://www.xmlrpc.org.

    Bill
  24. This is why I get so unexcited about Web Services. Most developers use webservices for interoperability when CORBA, an older, more mature technology, is a better choince. CORBA is faster, is designed to support transaction and security propagation, supports failover (multiple endpoints within IOR), and is a better overall architecture.Sure, CORBA is a complicated solution, but so are webservices and WSDL, etc... IMO, webservices should never have gone beyond http://www.xmlrpc.org.Bill
    Web services are complicated ??? and u r comparing it CORBA ?? who are you kidding. Development of web services doesnt need u to learn new language IDL. and i dont even want to mention the whole 9 million network issues , deployment issues and the mental pain u go thru with CORBA. If it was that simple CORBA - which now about 5-6 years old ( mature) would have been very commonly accepted. But its not. where as webservices is ..... As someone said earlier in this forum - why not go back to COBOL.
  25. Web services are complicated ??? and u r comparing it CORBA ?? who are you kidding. Development of web services doesnt need u to learn new language IDL. and i dont even want to mention the whole 9 million network issues , deployment issues and the mental pain u go thru with CORBA. If it was that simple CORBA - which now about 5-6 years old ( mature) would have been very commonly accepted. But its not. where as webservices is ..... As someone said earlier in this forum - why not go back to COBOL.
    There are new web services specs coming out and the end is nowhere in sight. Give it some time and WS will be just as complex and hard to use as CORBA. I guess nobody has to learn WSDL. But maybe you meant to say that the web services tools are better?
  26. Web services are complicated ??? and u r comparing it CORBA ?? who are you kidding. Development of web services doesnt need u to learn new language IDL. and i dont even want to mention the whole 9 million network issues , deployment issues and the mental pain u go thru with CORBA. If it was that simple CORBA - which now about 5-6 years old ( mature) would have been very commonly accepted. But its not. where as webservices is ..... As someone said earlier in this forum - why not go back to COBOL.
    There are new web services specs coming out and the end is nowhere in sight. Give it some time and WS will be just as complex and hard to use as CORBA. I guess nobody has to learn WSDL. But maybe you meant to say that the web services tools are better?
    Given the young age of web services , its bound to have some more spec coming in - especially for security etc. CORBA didnt standardize everything in one release either. <br>
    Also I m not sure what tools are you talking about to create a web service. its just that u agree on wsdl and choose any language u know - .NEt, java, perl, c++ ... U DONT NEED TO WASTE time in learning the complicated IDL and its own illogical syntax and restrictions on input and output types. I can never accept that CORBA is simple. Infact its the most complicated. I remember spending days and nights trying to get a " hello world" string passed from client to server and a result back. FRUSTATING. And in these many years its still complex. OMG never tried to simplfy it. They were busy with very big stuff all the time. anyway ... my last 2 cents on corba....
  27. I think WS as complicated as CORBA without tools and both are simple
    to use with tools. See Delphi and
    you will not find any compications in CORBA or DCOM and probably this tool is more mature than tools for WS too,
    IDL or ODL must be more readable for JAVA developer than WSDL for webmaster, visual editors generate IDL (It is trivial to generate it from JAVA interface definition too), but there is no problems to write it manualy.
    Web services are complicated ??? and u r comparing it CORBA ?? who are you kidding. Development of web services doesnt need u to learn new language IDL. and i dont even want to mention the whole 9 million network issues , deployment issues and the mental pain u go thru with CORBA. If it was that simple CORBA - which now about 5-6 years old ( mature) would have been very commonly accepted. But its not. where as webservices is ..... As someone said earlier in this forum - why not go back to COBOL.
    There are new web services specs coming out and the end is nowhere in sight. Give it some time and WS will be just as complex and hard to use as CORBA. I guess nobody has to learn WSDL. But maybe you meant to say that the web services tools are better?
    Given the young age of web services , its bound to have some more spec coming in - especially for security etc. CORBA didnt standardize everything in one release either. <br>Also I m not sure what tools are you talking about to create a web service. its just that u agree on wsdl and choose any language u know - .NEt, java, perl, c++ ... U DONT NEED TO WASTE time in learning the complicated IDL and its own illogical syntax and restrictions on input and output types. I can never accept that CORBA is simple. Infact its the most complicated. I remember spending days and nights trying to get a " hello world" string passed from client to server and a result back. FRUSTATING. And in these many years its still complex. OMG never tried to simplfy it. They were busy with very big stuff all the time. anyway ... my last 2 cents on corba....
  28. I think WS as complicated as CORBA without tools and both are simpleto use with tools.
    That is the point. When we work with tools ( as we should do ) CORBA is very – very –very simple, so why do we need slow, bloated, and impaired XML based RPC?
  29. deja vu??[ Go to top ]

    Web services has completed its cycle, too verbose, slow, blah blah ... now go back to what it was supposed to replace: CORBA. whats next??
  30. It's nice to see other players coming late to the game and validating solutions that IONA has already been providing in this space for awhile now. We provide two high-powered ways to solve this particular integration problem:

    For pure J2EE-CORBA integration, we provide Orbix Connect, which is an easy way to let your JBoss, WebSphere, or WebLogic app server talk to existing CORBA servers and services.

    For integration based on Web Services, we provide Artix, which is light years ahead of any competition in the Web Services space. Artix allows Web Services clients to natively talk to not only CORBA services over IIOP, but also to services based on other popular middleware systems such MQ Series, Tuxedo, and Tibco. Being a web services product, naturally Artix also supports SOAP and HTTP and HTTP/S, of course. With Artix, all such services, regardless of how they're implemented, are abstracted in WSDL so that their contracts are logical and thus independent of how messages physically get sent to them. Their physical bindings are also defined in WSDL, using WSDL extensors (WSDL was explicitly designed to be extended in this fashion), and these bindings allow for native access over the service's existing transport(s), which allows for non-invasive integration and preservation of existing investments. Artix's support of multiple transports, protocols, and on-the-wire formats enables it to disintermediate your enterprise systems and get rid of the hard-to-manage and slow-performing gateways that other vendors foist on you.

    You can download Artix for free to try it for yourself, and you can also read more about it in my blog.
  31. Please elaborate[ Go to top ]

    Steve, As a consultant, I am always on the lookout for products that allow me to design better solutions for my clients. The beauty of having a .NET ORB is not only Java/.Net interop, but .Net interop with any other CORBA partner, such as IBM Cobol running on MVS.
    Based on your posting above, I am not sure if I understand how IONA can help me getting a Java client talk to a .Net server through CORBA and vice versa, especially when SOAP is explicitely not wanted in the picture?
  32. Please elaborate[ Go to top ]

    If you don't want web services in the picture, and you want .NET talking to CORBA, then you use our .NET remoting support for Orbix 6.1. Run the CORBA IDL through our tool to produce the remoting metadata, connect to an IOR and the IONA DLLs generate a DII request and invoke the target object over IIOP. This is essentially an IIOP stack for .NET with the Remoting API. Feel free to read our documentation for more details.

    As for other integrations, our customers generally seek to future-proof their systems, which is why with Artix we use WSDL as a services abstraction layer. WSDL can be applied to any services endpoint. You describe the logical service contract once, and then use that contract with as many different middleware or infrastructure bindings as you want to. JMS, .NET, MQ Series, TIBCO, Tuxedo, CORBA, SOAP, whatever. Our multi-middleware Artix system can handle them all, and it's also pluggable so it can easily handle anything else you want to throw in there too. It doesn't sacrifice performance to attain that level of flexibility, either.
  33. Also consider JuggerNET[ Go to top ]

    Codemesh's JuggerNET tool has provided .NET calling Java functionality since the middle of last year. It also exposes Java to COM via .NET. Threading, callbacks, just about everything you wish works extremely naturally.
    Together with it's sister product JunC++ion, it can make Java available to C++ programmers on many platforms and to .NET programmers on Windows. Take a look at the FAQs to get an idea about how easy integration of Java with other languages can be.
  34. MiddTec has changed into Middsol[ Go to top ]

    MiddTec has changed into Middsol (www.middsol.com).

    Jo