Performance
A platform performs if it yields an acceptable response time under a specified user load. The definition of what is 'acceptable' changes for each business problem. To achieve acceptable performance, it is important that the underlying web services infrastructure empowers you to build high-performing systems.
The primary bottleneck when building web services is usually integration with back-end database systems. The reason for this is that most enterprise applications are data-driven systems with much more data logic than business logic. Given that the database is usually the bottleneck, any possible tactics for reducing database load will result in a significant wins.
J2EE reduces database traffic through two tactics:
Stateful business processes allow you to maintain business process state in memory, rather than writing that state out to the database on each request.
Long-term caching (provided by some implementations) allow for database data to be cached for long periods of time, rather than re-reading database data upon each request.
It should be noted that both maintaining business state in-memory and caching must be used with caution, and may result in problems if developers are not properly trained on when to (and when not to) use these features. This is a fundamental difference between the J2EE and .NET approaches to building web services: J2EE's advantage is that it gives programmers more control over lower-level services such as state management and caching. Well-educated developers can tap into these features to improve the quality of their deployment. But it is of vital importance that developers are properly educated on when to make these tradeoff decisions, or error may be introduced into systems.
By way of comparison, Microsoft.NET does not offer these tactics for improving performance. There are no opportunities for performance wins, but at the same time, there are no opportunities for developers to introduce errors into systems.
When trying to choose between whether these features are important for your organization, consider the quality of your developers. If they are well-educated and do not require much hand-holding, then they will likely find the flexibility and performance gains from a J2EE system as valuable. If your developers require more hand-holding, then the Microsoft approach is clearly superior.
Scalability
Scalability is essential when growing a web services deployment over time, because one can never predict how new business goals might impact user traffic.
A platform is scalable if an increase in hardware resources results in a corresponding linear increase in supported user load while maintaining the same response time. By this definition, the underlying hardware (Win32, UNIX, or Mainframe) is irrelevant when it comes to scalability, because both J2EE and .NET allow one to add additional machines to increase user load while maintaining the same response time. The major implementations based on J2EE architecture, as well as .NET, provide load-balancing technology that enable a cluster of machines to collaborate and service user load that scales over time.
The significant difference between J2EE and .NET scalability is that since .NET supports Win32 only, a greater number of machines are needed than a comparable J2EE deployment due to processor limitations. This multitude of machines may be difficult for organizations to maintain.
VI. Conclusions
--------------------------------------------------------------------------------
The J2EE verses .NET battle will be the soap opera of the decade for geeks to watch. But there are promises and realities about both platforms. For example, J2EE is a rather brilliant move on the vendors' part, but should not be seen as an altruistic initiative. All vendors that participate in J2EE are after financial gains, as well as an effective weapon against Microsoft. J2EE enables these vendors to collaborate together and stand ground. Many of these vendors have undergone recent mergers and acquisitions themselves, and so organizations must exercise good judgment when choosing such a platform.
As far as Microsoft.NET, that is far from an altruistic initiative. It is a monopolistic initiative dressed in altruism. Microsoft has been claiming that .NET is about open and interoperable web services, when in reality Microsoft is already making their web services closed and proprietary. Microsoft will likely increase the costs of their solutions if a monopoly can be achieved, and innovation will be slowed down significantly.
So what's a company like yours to do? Both platforms are useful, and both can lead you to the same destination. Which platform is right for you? When deciding, we recommend you concentrate on the larger business issues. Think about your existing developer skillsets, your existing systems, your existing vendor relationships, and your customers. Those almost always drive the decision, not the minor features.
Arguments supporting both platforms
Regardless of which platform you pick, new developers will need to be trained (Java training for J2EE, OO training for .NET)
You can build web services today using both platforms
Both platforms offer a low system cost, such as jBoss/Linux/Cobalt for J2EE, or Windows/Win32 hardware for .NET.
Both platforms offer a single-vendor solution.
The scalability of both solutions are theoretically unlimited.
Arguments for .NET and against J2EE
.NET has Microsoft's A-team marketing it
.NET released their web services story before J2EE did, and thus has some mind-share
.NET has a better story for shared context today than J2EE
.NET has an awesome tool story with Visual Studio.NET
.NET has a simpler programming model, enabling rank-and-file developers to be productive without shooting themselves in the foot
.NET gives you language neutrality when developing new eBusiness applications, whereas J2EE makes you treat other languages as separate applications
.NET benefits from being strongly interweaved with the underlying operating system
Arguments for J2EE and against .NET
J2EE is being marketed by an entire industry
J2EE is a proven platform, with a few new web services APIs. .NET is a rewrite and introduces risk as with any first-generation technology
Only J2EE lets you deploy web services today
Existing J2EE code will translate into a J2EE web services system without major rewrites. Not true for Windows DNA code ported to .NET.
.NET web services are not interoperable with current industry standards. Their BizTalk framework has proprietary SOAP extensions and does not support ebXML.
J2EE is a more advanced programming model, appropriate for well-trained developers who want to build more advanced object models and take advantage of performance features
J2EE lets you take advantage of existing hardware you may have
J2EE gives you platform neutrality, including Windows. You also get good (but not free) portability. This isolates you from heterogeneous deployment environments.
J2EE has a better legacy integration story through the Java Connector Architecture (JCA)
J2EE lets you use any operating system you prefer, such as Windows, UNIX, or mainframe. Developers can use the environment they are most productive in.
J2EE lets you use Java, which is better than C# due to market-share and maturity. According to Gartner, there are 2.5 million Java developers. IDC predicts this will grow to 4 million by 2003. 78% universities teach Java, and 50% of universities require Java.
We would not want to use any language other than C# or Java for development of new mission-critical solutions, such as a hacked object-oriented version of C, VB, or COBOL.
We are finding most ISVs and consulting companies going with J2EE because they cannot control their customers' target platforms. We believe this application availability will result in J2EE beginning to dominate more and more as time goes on.
In conclusion, while both platforms will have their own market-share, we feel most customers will reap greater wins with J2EE. We feel the advantages outweigh those offered by Microsoft.NET. That is our preferred architecture, and we stand behind it.
本文地址：http://com.8s8s.com/it/it18639.htm