| By: | Pervez@myfaithsolution.com | | Date: | 6/1/2010 5:14:43 AM | |  Rate this | Expertize in Microsoft Technology.having 4 years of experience in web and windos development |  | |
| | 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.[12]
In fact, few non-Sun J2EE proponents believe this is achievable. One of the most prominent independent J2EE spokespersons is Paul Harmon, a principal consultant for the Cutter Consortium and the writer of the widely read Architecture/e-Business E-Mail Advisory. While Harmon is usually very pro-J2EE, he recently wrote this unusually frank assessment of J2EE vendor portability
Has the EJB model reached the point where I can move EJB components from one EJB application server to another? Not in most cases. The EJB specification isn't comprehensive enough. EJB application server vendors have "filled in" by providing proprietary solutions to complete the model and to guarantee that their clients can build production systems. [13]
Harmon summarizes the vendor neutrality situation today, as do many, with this assessment:
The reality, at the moment, is that if you want to develop an EJB application, you should stick with a single vendor.[14]
The reality today is that there is no such thing as vendor neutrality. Of course, the .NET platform is not vendor neutral, it is tied to the Microsoft operating systems. But neither are any of the J2EE implementations. The best advice I can give is to choose some vendor, plan on staying with that vendor, and leverage the heck out of the platform that vendor provides. | | Post Your Comment |
| By: | Maspnet@gmail.com | | Date: | 1/12/2010 10:18:52 PM | | | Rate this | Expertize in Microsoft Technology.having 6 years of experience in web and windos development |  | |
| Hi
I discussed the difference between the Java and the .NET platform presentation tier programming models. 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!
This approach solves all three of the problems of the Java/old-ASP approach. One can write an effective presentation tier application with much less code, since a single code path works for all possible thin clients. It is much easier to test that code, since one is only testing one's interaction with the control, rather than the client devices themselves. And finally, one can add new client devices very easily, but simply downloading the latest version of the control that has hopefully been updated with the latest knowledge about thin client devices.
From a cost perspective, the .NET Framework approach is a clear winner. Development, debugging, and maintenance are all much easier (and much cheaper) when the presentation tier developer is not responsible for determining what will be displayed on the client device. | | Post Your Comment |
| By: | shabir@myfaithsolution.com | | Date: | 1/11/2010 10:18:52 PM | | | Rate this | Shabir has 12 yrs of exp in I.T using Asp, Asp.NET, Vb6/.NET/C#, MOSS/WMI/html/DOM, Ajax, XML,xsl.SharePoint |  | |
| Hi,
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. There 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.
The single most important differentiating characteristic between these two platforms is overall system profitability. Companies seeking a low cost eCommerce platform would be negligent to ignore the Microsoft offering. eCommerce has always required high reliability and excellent scalability. For the first time, these functionalities are available at on a commodity hardware platform for a fraction of the cost of Unix based solutions. | | Post Your Comment |
|
