FAQ'S ON DOT NET FRAME WORK PART FOUR

Different between NET and J2EE :

Vendor Neutrality

The .NET platform is not vendor neutral, it is tied to the Microsoft operating systems. But neither are any of the J2EE implementations.

Many companies buy into J2EE believing that it will give them vendor neutrality. And, in fact, this is a stated goal of Sun's vision:

A wide variety of J2EE product configurations and implementations, all of which meet the requirements of this specification, are possible. A portable J2EE application will function correctly when successfully deployed in any of these products.

Overall Maturity

Given that the .NET platform has a three year lead over J2EE, it should be no surprise to learn that the .NET platform is far more mature than the J2EE platform. Whereas we have high volume highly reliable web sites using .NET technologies (NASDAQ and Dell being among many examples)

Interoperability and Web Services

The .NET platform eCollaboration model is, as I have discussed at length, based on the UDDI and SOAP standards. These standards are widely supported by more than 100 companies. Microsoft, along with IBM and Ariba, are the leaders in this area. Sun is a member of the UDDI consortium and recognizes the importance of the UDDI standards.

Framework Support

The .NET platform includes such an eCommerce framework called Commerce Server. At this point, there is no equivalent vendor-neutral framework in the J2EE space. With J2EE, you should assume that you will be building your new eCommerce solution from scratch.

Moreover, no matter what [J2EE] vendor you choose, if you expect a component framework that will allow you to quickly field complete e-business applications, you are in for a frustrating experience.

Language

In the language arena, the choice is about as simple as it gets. J2EE supports Java, and only Java. It will not support any other language in the foreseeable future. The .NET platform supports every language except Java (although it does support a language that is syntactically and functionally equivalent to Java, C#).

In fact, given the importance of the .NET platform as a language independent vehicle, it is likely that any language that comes out in the near future will include support for the .NET platform.

Some companies are under the impression that J2EE supports other languages. Although both IBM's WebSphere and BEA's WebLogic support other languages, neither does it through their J2EE technology.

There are only two official ways in the J2EE platform to access other languages, one through the Java Native Interface and the other through CORBA interoperability. Sun recommends the later approach. As Sun's Distinguished Scientist and Java Architect Rick Cattell said in a recent interview.

Portability

The reason that operating system portability is a possibility with J2EE is not so much because of any inherent portability of J2EE, as it is that most of the J2EE vendors support multiple operating systems. Therefore as long as one sticks with a given J2EE vendor and a given database vendor, moving from one operating system to another should be possible.

This is probably the single most important benefit in favor of J2EE over the .NET platform, which is limited to the Windows operating system. It is worth noting, however, that Microsoft has submitted the specifications for C# and a subset of the .NET Framework (called the common language infrastructure) to ECMA, the group that standardizes JavaScript.

J2EE offers an acceptable solution to ISVs when the product must be marketed to non-Windows customers, particularly when the J2EE platform itself can be bundled with the ISV's product as an integrated offering.

If the primary customer base for the ISV is Windows customers, then the .NET platform should be chosen. It will provide much better performance at a much lower cost.

Client device independence

The major difference being that with Java, it is the presentation tier programmer that determines the ultimate HTML that will be delivered to the client, and with .NET, it is a Visual Studio.NET control.

This Java approach has three problems. First, it requires a lot of code on the presentation tier, since every possible thin client system requires a different code path. Second, it is very difficult to test the code with every possible thin client system. Third, it is very difficult to add new thin clients to an existing application, since to do so involves searching through, and modifying a tremendous amount of presentation tier logic.

The .NET Framework approach is to write device independent code that interacts with visual controls. It is the control, not the programmer, that is responsible for determining what HTML to deliver, based on the capabilities of the client device.. In the .NET Framework model, one can forget that such a thing as HTML even exists!

Conclusion

Sun's J2EE vision is based on a family of specifications that can be implemented by many vendors. It is open in the sense that any company can license and implement the technology, but closed in the sense that it is controlled by a single vendor, and a self contained architectural island with very limited ability to interact outside of itself. One of J2EE's major disadvantages is that the choice of the platform dictates the use of a single programming language, and a programming language that is not well suited for most businesses. One of J2EE's major advantages is that most of the J2EE vendors do offer operating system portability.

Microsoft's .NET platform vision is a family of products rather than specifications, with specifications used primarily to define points of interoperability. The major disadvantage of this approach is that if is limited to the Windows platform, so applications written for the .NET platform can only be run on .NET platforms.

Their are several important advantages to the .NET platform:

  1. The cost of developing applications is much lower, since standard business .
  2. languages can be used and device independent presentation tier logic can be written.
  3. The cost of running applications is much lower, since commodity hardware platforms (at 1/5 the cost of their Unix counterparts) can be used.
  4. The ability to scale up is much greater, with the proved ability to support at least ten times the number of clients any J2EE platform has shown itself able to support.
  5. Interoperability is much stronger, with industry standard eCollaboration built into the platform.

RELATED POST

ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART ONE

ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART TWO

ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART THREE

ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART FOUR

ASP.NET INTERVIEW QUESTIONS AND ANSWERS PART FIVE

ADO.NET INTERVIEW QUESTIONS AND ANSWERS PART ONE

ADO.NET INTERVIEW QUESTIONS AND ANSWERS PART TWO

You can also learn the concept of frame work concept in detail with questions and answers in the following place.

MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART ONE

MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART TWO

MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART THREE

MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART FOUR

MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART FIVE

MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART SIX

MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART SEVEN

MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART EIGHT

MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART NINE

MICROSOFT DOT NET FRAME WORK QUESTIONS AND ANSWERS PART TEN

No comments:

Post a Comment