DotNet FrameWork – Client device independence and basics – Day 11 of 30

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! Contd ….

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:

* The cost of developing applications is much lower, since standard business languages can be used and device independent presentation tier logic can be written.

* The cost of running applications is much lower, since commodity hardware platforms (at 1/5 the cost of their Unix counterparts) can be used.

* 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.

* Interoperability is much stronger, with industry standard eCollaboration built into the platform.

Please read all the post in the Dotnet Framework series.

Reference : Dilip Kumar Jena ( https://mstechexplore.wordpress.com )

Advertisements

One thought on “DotNet FrameWork – Client device independence and basics – Day 11 of 30

  1. Pingback: DotNet FrameWork – Dot Net Basics Complete Series Reference – Day 0 of 30 « Exploring Dot Net with Dilip Kumar Jena

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s