No Spin Architecture : .NET Inteoperability

Web Cast: Java Interoperability with .NET

makif — Wed, 28 Mar 2007 03:15:00 GMT

About: This blog post is about the web cast that I will conduct next week,

Hello,

I will conduct the a Web Cast on Java and .NET interoperability next week, details of the Web Cast and the registration link is as follows:

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032331985&Culture=en-US

Microsoft recognizes that many financial services companies have diverse IT environments; therefore, Microsoft is developing software and technologies that allow you to take advantage of your existing investments in third-party solutions. In this webcast, we discuss real-world best practices and strategies for implementing interoperability between Microsoft .NET and the Java programming language from Sun Microsystems. We focus on implementing interoperability between Java 2 Platform Enterprise Edition (J2EE) and Microsoft .NET versions 1.1, 2.0, and 3.0. We also provide an introduction to interoperability between Windows Communication Foundation (WCF) and Java Platform Enterprise Edition 5 (Java EE 5). We conclude the session with a discussion of the architecture and development processes you can institute to accommodate varying technologies while maximizing reuse.

http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032331985&Culture=en-US

Best regards,

Mohammad

Interoperability resources

makif — Sun, 05 Mar 2006 18:53:00 GMT

About: This post contains a series of interoperability resources between .NET and Web Sphere, Web Logic, Jboss and other J2EE technologies. It also contains lniks for interoperability between Unix and Windows, windows and mainframes, Netware and Windows and other Interoperability related resources. I have included Web Casts, Web Sites, Books and articles.

Hello,

Here is a list of interoperability resources, this is of course not an exhaustive list but I hope that you will find it to be useful starting point, I am hoping that with your help I will be able to grow it further and keep it current. If you are aware of a great Web Cast, Web Site, Book or article on Interoperability, please send me an email and I will include it in this list.

Web Cast

1) J2EE and .NET, similarities, differences and interoperability

http://www.microsoft.com/canada/events/event_details_ww.aspx?event_id=1032289781

2) Microsoft Windows and Linux Interoperability: Shattering the Myths

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032281352

3) How to Design Your Web Services for Successful Interoperability

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032266665

4) Interoperability Between .NET and WebSphere

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032265620

5) HIS Bi-directional Transaction and Data Inter-op between Windows and IBM Mainframe Systems

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032268822

6) Security Integration between Windows and IBM Mainframes

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032268825

7) Best Practices for J2EE and .NET Interoperability in Financial Services

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032289117

8).NET Integration with BEA Weblogic

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032265912

9) Interoperability Between .NET and Apache Axis

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032265898

10) Interoperability Between .NET and Jboss

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?EventID=1032265896

11) Integrating Active Directory with Unix and Java/J2EE Environments

http://msevents.microsoft.com/cui/WebCastEventDetails.aspx?culture=en-US&EventID=1032267729

12) Novell Netware and Windows Server 2003 Migration and Interoperability

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032268767

Web Sites

1) Interoperability Web Site

http://msdn.microsoft.com/vstudio/java/interop/default.aspx

2) Web Services Interoperability

http://msdn.microsoft.com/webservices/webservices/building/interop/default.aspx

3) Web Services Interoperability resources

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsvcinter/html/globalxmlwebsrvinterop.asp

Books and articles

1) Microsoft® .NET and J2EE Interoperability Toolkit

http://www.microsoft.com/mspress/books/6711.asp

2) Microsoft® Application Interoperability: Microsoft .NET and J2EE

http://www.microsoft.com/products/info/product.aspx?view=22&pcid=6f549360-a854-4325-b8b7-6db0443098ae&type=ovr

3) Microsoft® Building Interoperable Web Services: WS-I Basic Profile 1.0

http://www.microsoft.com/products/info/product.aspx?view=22&pcid=e95ee5d8-fb4a-4cee-8d2e-c71746c939f1&type=ovr

Best regards,

Mohammad

J2EE and .NET interoperability through .NET remoting

makif — Mon, 26 Dec 2005 21:59:00 GMT

About: This post outlines further details about implementing J2EE and .NET interoperability through .NET remoting

Hello,

In my November 25, 2005 post I outlined the following four strategies for interoperability; 1) Web Services, 2) .NET Remoting, 3) HTTP (REST), and 4) Custom solutions. This particular blog post focuses on .NET remoting that allows for binary and XML communication between Java/J2EE and .NET systems.

In the context of interoperability, .NET remoting is a Microsoft specification that has been implemented by companies like J-Integra (http://j-integra.intrinsyc.com) and JNBridge (http://www.jnbridge.com). It is a framework that allows implementation of solutions where features like high performance and call back capabilities are required. .NET remoting allows for binary and XML encoding, synchronous or asynchronous communication and provides services like lifecycle management across application boundaries. .NET remoting engines like J-Integra generate proxies that allow .NET applications to invoke Java/J2EE systems as if they were just another.NET system, it also allows Java/J2EE to invoke the .NET applications as if they were Java/J2EE objects, in short, either .NET or Java/J2EE system can be in control of the execution flow.

.NET remoting can be used to implement interoperability between Java (swing) clients and .NET applications on the desktop as it allows for sharing of memory as well as communication through sockets, however, in my opinion; it’s most common use in the industry remains in the area of invoking J2EE servers from .NET clients and for communication between J2EE and .NET servers.

During the 1997-2001 timeframe a number of companies made significant investments in implementing Java/J2EE systems, however the early focus of Java/J2EE on completely web-based enterprises slowed the pace of innovation on the client side and with the release of .NET and Microsoft’s understanding of the needs of business users, .NET quickly took a leadership position on the desktop. The IT managers (those who did not feel religiously about Java or .NET) realized that in many instances the needs of the business users can be better fulfilled by developing .NET solutions that could be developed faster than their Java counterparts and allowed users to harness the powers of .NET on the client while preserving the investments that the organization has made in Java/J2EE on the server side. .NET remoting was a natural choice in these instances as it allows for invocation of Java/J2EE servers by .NET applications by using TCP, HTTP (SOAP over HTTP) and RMI/IIOP. The solutions based on the RMI/IIOP channel have gained momentum as they provide an elegant solution which maintains clean separation amongst the two systems, while allowing for high performance, stateful interoperability

One of the key choices that must be considered before implementing a .NET remoting solution is implementing interoperability through Web Services e.g. exposing the J2EE servers as a web service rather than using the .NET remoting, RMI/IIOP solution. My opinion is that you should use Web Services if you can, however, if your business needs cannot be fulfilled through web services because of performance or other requirements then .NET remoting might be the next best choice.

Companies that provide .NET remoting solutions using the RMI/IIOP channel include J-Integra (http://j-integra.intrinsyc.com) e.g. the J-Integra Espresso is a solution where the Object Request Broker (ORB) has been written in C# and has been developed entirely as managed code which means that it allows clients & servers written in any .NET language e.g. C#, C++, ASP.NET etc. to access the ORB and interoperate with J2EE servers.

There has been some discussion about how the upcoming Windows Communication Foundation (code named Indigo) will impact solutions that have been implemented using .NET remoting. Please note that .NET remoting is NOT going to disappear when Indigo is released i.e. it is NOT being removed from the framework. It is true that Indigo is the next wave of evolution and it will be in your interest to upgrade your .NET remoting solution to it based on your business requirements and environment. You can minimize your future upgrade effort by avoiding the use of custom .net remoting channels and sinks as upgrading those would be significantly more involved.

In conclusion, .NET remoting is a viable and valid choice for implementing certain types of interoperability solutions; it is an approach currently being used in the industry for systems of all sizes and complexities and along with Web Services it allows you to take advantage of both Java/J2EE and .NET to serve the needs of the business.

Best regards,

Mohammad

J2EE and .NET Interoperability

makif — Fri, 25 Nov 2005 17:27:00 GMT

About: This post outlines some of the architectural mechanisms and strategies for programmatic interoperability between J2EE and .NET

Hello,

According to a recent study, over 80% of large enterprises will have both J2EE and .NET systems deployed in their IT environments for the next few years. Although vendors supporting the respective paradigms are trying their best to win market share from each other and some trends have started to emerge, I believe that it will still take 5+ years for the market to decide an absolutely clear winner. In the meantime, many enterprise customers need to come up with strategies for interoperability between these technologies to make it a transparent experience for the user and avoid having technology-based silos.

Interoperability can be looked at from a variety of angles including management, monitoring, measurement, security/Identity management and federation, programmatic interaction etc. In this post, I have concentrated on the programmatic portion, based on interactions with many large enterprises; I have observed the following interoperability scenarios in the industry

1) .NET clients interacting with J2EE Servers - Most common

2) .NET servers interacting with J2EE Servers

3) .NET clients interacting with Java Clients (on the desktop)

3) .NET servers interacting with Java Clients - Least common

The common programmatic techniques for interoperability can be summed up in the following areas

1) Web Services

2) .NET Remoting

3) HTTP (REST),

4) Custom solutions

Web Services are the future of interoperability and more, all major vendors of J2EE and .NET related software are enabling their products to support Web Services standards and are making significant investments to overcome any deficiencies that may exist today. My personal advice is that you should look at Web Services as the first choice for .NET client to J2EE server and .NET server to J2EE server interoperability solution. Web Services offer a number of advantages over other approaches and adopting this as the strategy increases your chances of taking advantage of the investments being made by the software vendors. Please also note that using Web Services does not necessarily translate in to a low performance system and the standard stack is fairly mature in some of the areas while considerable work is occurring to finalize uncovered portion. It is a good idea to do an objective proof-of-concept to determine the viability of the Web Services approach.

.NET remoting is a Microsoft specification that has been implemented by companies such as Intrinsyc (http://j-integra.intrinsyc.com) and JNBridge (http://www.jnbridge.com). In a nutshell, these engines make .NET applications look like Java/J2EE applications to the calling Java/J2EE program and vice versa. There are a number of protocol and format choices with .NET remoting including binary communication and sharing in-process memory. .NET remoting can be a viable option for high volume systems as well as systems requiring features like call-backs.

Representation State Transfer (REST) over HTTP is typically used in scenarios where a .NET client is calling an HTTP based service (often a Java Servlet). This approach has its limitations but maybe useful for simpler web scenarios

Custom solutions have been implemented by a number of customers especially large enterprises that had to deal with interoperability issues a few years ago, there are valid business reasons for why an organization may choose to implement a custom solution (which typically involves writing a subset of a commercial interop engine, playing around with native programming (JNI) and implementing mappings), however, you should make an informed decision in terms of the development and maintenance costs associated with the code and the costs of keeping it in sync with the changes in the .NET and J2EE core technologies.

In conclusion, all of the above mentioned solutions are viable options for programmatic interoperability, the decision to choose a particular approach will depend on the business needs, future outlook, costs of implementation and maintenance and quality of service parameters.

Best regards,

Mohammad

J2EE & .NET, similarities and differences

makif — Wed, 16 Nov 2005 01:28:00 GMT

About this posting: This post discusses the high-level similarities and differences between the J2EE and .NET programming models and provides some insight about future postings

Hello,

There are many similarities between .NET and J2EE. I am taking some liberty with the official definitions of these models but in the real world, J2EE is a programming model based on the Java language, having a concept of a container (typically application server) that provides services like lifecycle management and support for declarative transactions. J2EE is based on object oriented design principles; it is a specification owned by Sun Microsystems, however, Sun does involve the community in building the specification through the Java Community Process. The core J2EE specification is supported by multiple vendors most notably Sun Microsystems, BEA and IBM and other vendors build applications that run on J2EE applications servers. In addition to the 'write once, deploy on multiple operating systems' feature of Java, J2EE also defines layers of abstractions in the forms of APIs that provide some level of decoupling between your application and the underlying infrastructure and resources e.g. as in case of JMS and JDBC APIs.

In the real world, .NET is a programming model that supports multiple languages; it provides services like lifecycle management, sand box security and garbage collection and is based on object oriented design principles. The .NET specifications and the core APIs are developed by Microsoft, however, Microsoft involves the community by actively getting feedback through multiple channels and uses that feedback to decide the new features of the framework, the .NET frame work is supported by a large ecosystem of ISVs that develop solutions that utilize the .NET APIs. The applications developed using the .NET model are typically deployable on the Windows platform only, however, they can interoperate with applications running on other platforms using a variety of mechanisms that I will be discussing in my future posts. The new version of .NET, .NET 2.0, introduces the concept of ‘providers’ which decouples your application from the underlying resources like the database and security-credential provider. Both J2EE and .NET have concepts of Virtual Machines and Just-in-time compilation, J2EE has a Java Virtual Machine (JVM) that facilities platform choice and .NET has Common Language Runtime (CLR) that facilitates choice of programming languages, the conceptual architecture for both the models looks quiet similar. I will be willing to provide a mapping for those who are interested in a more detailed comparison.

Keeping all the prejudices aside, it is possible to develop good IT solutions using either model of programming, there is nothing inherently wrong with .NET or J2EE, those who claim that a reliable system cannot be developed in Java or that it is not possible to develop a highly secure and reliable system in .NET have not done their homework or are not current in their research. It is true that both J2EE and .NET have had their set of issues in the past years, however both programming models have passed through radical changes and many of the issues have been resolved some time ago, e.g. I recently corresponded with someone that was concerned about the inherent capability of .NET to support his enterprise mission critical application consisting of 100 transactions per second in a system where a 150 million dollars exchanges take place in an year. It came as news to him that their are many absolutely mission critical applications running on .NET, including applications that support 3000 transactions per second with over 5 trillion dollars changing hands (at a stock exchange). Similarly, I have seen a very complex and large airline reservation system successfully developed and running on J2EE. In my humble opinion, the inherent capability of the programming models is only one of the factors and the architects and technical decision makers need to look at other criteria for making an objective decision, I will talk about some of the decision criteria in my future posts, stay tuned and please do provide feedback so I may learn from you.

Best regards,

Mohammad