Comments on: .NET/Java Interop is not a reason for SOA http://www.udidahan.com/2007/05/28/netjava-interop-is-not-a-reason-for-soa/ Enterprise Development Expert & SOA Specialist Sat, 13 Mar 2010 15:04:13 -0600 http://wordpress.org/?v=2.8.4 hourly 1 By: Command Query Separation and SOA http://www.udidahan.com/2007/05/28/netjava-interop-is-not-a-reason-for-soa/comment-page-1/#comment-29042 Command Query Separation and SOA Mon, 11 Aug 2008 13:19:13 +0000 http://udidahan.weblogs.us/2007/05/28/netjava-interop-is-not-a-reason-for-soa/#comment-29042 [...] components will likely be developed using the same technology - although there are already ways to host Java code in .NET and [...] [...] components will likely be developed using the same technology – although there are already ways to host Java code in .NET and [...]

]]> By: Vitaly Shelest http://www.udidahan.com/2007/05/28/netjava-interop-is-not-a-reason-for-soa/comment-page-1/#comment-15414 Vitaly Shelest Sun, 27 Jan 2008 10:04:26 +0000 http://udidahan.weblogs.us/2007/05/28/netjava-interop-is-not-a-reason-for-soa/#comment-15414 What do you mean "opposite"? If this is somthing like .NET Platform Invoke that makes possible to call unmanaged (native) function by declaring its prototype then take a look at my project "Java Platform Invoke SDK". It implements .NET P/Invoke paradigm in Java. See http://www.sharewareplaza.com/Java-Platform-Invoke-API-Demo-version-download_49212.html What do you mean “opposite”? If this is somthing like .NET Platform Invoke that makes possible to call unmanaged (native) function by declaring its prototype then take a look at my project “Java Platform Invoke SDK”. It implements .NET P/Invoke paradigm in Java.
See
http://www.sharewareplaza.com/Java-Platform-Invoke-API-Demo-version-download_49212.html

]]> By: udidahan http://www.udidahan.com/2007/05/28/netjava-interop-is-not-a-reason-for-soa/comment-page-1/#comment-13553 udidahan Sat, 05 Jan 2008 21:48:07 +0000 http://udidahan.weblogs.us/2007/05/28/netjava-interop-is-not-a-reason-for-soa/#comment-13553 Vitaly, That sounds interested. Is it possible to do the opposite as well? Vitaly,

That sounds interested. Is it possible to do the opposite as well?

]]> By: Vitaly Shelest http://www.udidahan.com/2007/05/28/netjava-interop-is-not-a-reason-for-soa/comment-page-1/#comment-13546 Vitaly Shelest Sat, 05 Jan 2008 20:00:56 +0000 http://udidahan.weblogs.us/2007/05/28/netjava-interop-is-not-a-reason-for-soa/#comment-13546 You forget about the option to write Java Native Code in a .NET language and do not use mediators like Web services, SOA, COM, Jintegra, etc. Two years ago I developed JNI for .NET 1.1 and 2.0, Tools for MS VS2003 and MS VS2005 to automate JNI code writing. Google Object-Oriented JNI (OOJNI). You forget about the option to write Java Native Code in a .NET language and do not use mediators like Web services, SOA, COM, Jintegra, etc.
Two years ago I developed JNI for .NET 1.1 and 2.0, Tools for MS VS2003 and MS VS2005 to automate JNI code writing.
Google Object-Oriented JNI (OOJNI).

]]> By: » Don’t let the Jini out of the bottle on SOA http://www.udidahan.com/2007/05/28/netjava-interop-is-not-a-reason-for-soa/comment-page-1/#comment-2269 » Don’t let the Jini out of the bottle on SOA Tue, 12 Jun 2007 22:13:13 +0000 http://udidahan.weblogs.us/2007/05/28/netjava-interop-is-not-a-reason-for-soa/#comment-2269 [...] code, but that’s it. In terms of technology coupling, Jini is Java-only – there are some ways to get interoperability with .net and other platforms, but it doesn’t look like Jini set out to handle it. Finally, [...] [...] code, but that’s it. In terms of technology coupling, Jini is Java-only – there are some ways to get interoperability with .net and other platforms, but it doesn’t look like Jini set out to handle it. Finally, [...]

]]> By: Ben Scheirman http://www.udidahan.com/2007/05/28/netjava-interop-is-not-a-reason-for-soa/comment-page-1/#comment-2093 Ben Scheirman Wed, 06 Jun 2007 17:46:06 +0000 http://udidahan.weblogs.us/2007/05/28/netjava-interop-is-not-a-reason-for-soa/#comment-2093 While I agree with you on the main points, I fail to see why that would be a bad use of web services... The interface doesn't have to be chatty, in fact they should be augmenting the internal interface to minimize the number of method calls required to complete the task. I'd really like your thoughts on my rant about SOA here: http://www.flux88.com/SlayingTheSixHeadedSOABeast.aspx -Ben While I agree with you on the main points, I fail to see why that would be a bad use of web services…

The interface doesn’t have to be chatty, in fact they should be augmenting the internal interface to minimize the number of method calls required to complete the task.

I’d really like your thoughts on my rant about SOA here:
http://www.flux88.com/SlayingTheSixHeadedSOABeast.aspx

-Ben

]]>