This article is selected from an article "J2EE VS .NET" article from ObjectWatch, the article is translated by others, and I only reprint. If you are interested in the original text, you can refer to http://www.bobjectWatch.com/our_position.htm
Difference between J2EE and .NET platform
You can see a big overlap between J2EE and .NET platform technology. But how do you choose between them? In this section, the author will discuss the main difference I have seen.
Developer neutrality
Many companies buy J2EE, they believe this can give them a developer. In fact, this is a determination target for Sun Program: Configuring and implementing a variety of products that meet J2EE specifications. A portable J2EE application is successfully deployed in any of these products [1], it can operate correctly.
In fact, in addition to the supporters of Sun J2EE, few people believe this is achievable. Paul Harmon is one of the most important independence J2EE spokespersons. He is the Cutter Consortium's chief consultant, which is widely released by Architecture / E-Business E-mail Advisory author. Although Harmon always opposes J2EE, he recently wrote such unusual frank evaluation to J2EE's developers portability.
Does the EJB model have reached the extent that I can move the EJB component from an EJB application server to another? In most cases. The EJB specification is not comprehensive enough. Improve this model by providing proprietary solutions to ensure that their customers can create production systems, and EJB application server developers make up this. [2]
Harmon has summarized the situation in today's developers. His comments are as follows: At this moment, the real situation is if you want to develop an EJB application, you should be faithful to a developer. [3]
Today's reality is that there is no such situation like developers. Of course, the .NET platform is not a developer neutral, it is bundled with Microsoft's operating system. But both are not the implementation of J2EE. The best suggestion that the author can give is to choose a developer and plan to stand together, so you can take advantage of the platform advantage provided by the developer.
Overall maturity
The first J2EE specification, EJB specification was proposed in 1998, and the first beta version appeared in 1999. And this is three years after the first time with it is the first time with it. Net platform technology, MTS, COM . The author discussed the development process from MTS to COM in the most recent article [4].
Under the case where the .NET platform appears than J2EE, it is not surprising that the .NET platform is more mature than the J2EE platform. Although we have a highly reliable website that uses .NET technology (NASDAQ and Dell are two in many examples), but we don't know which website uses J2EE platforms. Paul Harmon made the following comments:
Today, any company is trying [J2EE-based] company-wide enterprise-wide company, all doing efforts, better ways to let a real outstanding development team to help them get rid of trouble. More importantly, it may reconsider an integrated project and is satisfied with initial approximation. [5]
Interoperability and network services
If the author is discussed in detail, the .NET platform electronic collaboration model is based on UDDI and SOAP standards. These standards are widely supported by more than 100 companies. Microsoft, IBM and Ariba are leaders in this field. Sun is a member of the UDDI Association and recognizes the importance of UDDI standards. At the recent press conference, Sun is responsible for the vice president of Java group development, George Paolini, said:
"Sun has been working to help build and support open, standard-based technologies to promote network-based applications, and we believe that UDDI is an important, establish a registered architecture for B2B e-commerce." [6] However, although Sun discloses believes in the UDDI standard, but in fact, Sun has not taken any measures to merge any UDDI standard into J2EE. This includes the most basic, more than a year of UDDI standards, SOAP. As IBM's Rod Smith (Emerge Technologies, Vice President, the company is one of the most powerful partners of Sun): So far, Sun has not published comments on [UDDI] network service. But I think this is reason. I think they are considering Java. When we consider online services, we are listening to our customers and their needs, but the truth is that customers have not based on Java-based systems and Java applications. Therefore, Sun is still adhering to Java, but it is very calm on this issue. [7]
In fact, smith is analyzed in the analysis of the interoperability strategy of Sun. Sun will focus mainly in the interoperability of J2EE developers and CORBA developers. Sun's interoperability idea is that it should be based on a so-called IIOP communication protocol.
There are three main defects using IIOP-based interoperability.
First, it requires the world to run J2EE or CORBA, which is a hypothetical assumption that SUN's partners are opposed. IBM's Rod Smith explains IBM support SOAP instead of supporting IIOP as an interoperability open standard:
When publishing a statement, and saying that we will use SOAP as an open standard, and the response is unbelievable and positive, because people want to make such integration. They have Microsoft-based solutions. They also have Java-based solutions. They also have a solution based on [Windows] NT and Linux-based solutions. [8]
The second defect is that like all communication protocols, IIOP should be in line with transmission over the Internet. This makes it impossible to be a universal electronic collaborative mechanism.
The third defect is that even the world agrees to use IIOP and J2EE, even in the J2EE developer, it is not appropriate to ensure that the current IIOP specification of the interoperability is also inappropriate. As Paul Harmon said:
Does the EJB application server from different developers have been standardized in a way that can bite in a larger system? Although Internet Interorb Protocol (IIOP) is used to support application communication between EJBs, it is still unable to join multiple EJB products together in a network. Two EJB application servers that each dependent several non-standard tools to communicate smoothly need some important programming work. [9]
Today's reality is that compared with J2EE, the .NET platform has a more powerful technical neutral electronic collaboration strategy. IBM is convinced that UDDI, rather than IIOP is the correct interoperability method, on this issue, this has been broken with Sun. At this point, it is painful but it is obvious that although it has been leading 10 years in UDDI, it is a complete failure.
Scalability
Scalability refers to the ability to add more workload. In general, additional workload is caused by the increase in customers. Scalability is a complex problem, and the author has conducted in-depth discussion in a few articles that have been available [10]. In the future, this discussion will be simplified, and the author will discuss scalability in the context of the problem encountered in the next three years. The author will further simplify this discussion, and only consider the cost of running business and database layers, although similar results may be similarly analyzed. Let us assume that MoneyBroker's business model requires it to handle 100,000 payments per day this year, next year is 1 million, and then 10 million. What are the related costs of the J2EE / UNIX solution or .NET platform / Windows solution?
In order to judge MonryBroker's machine size required in the next three years, we need a standard for transaction performance. The industrial standard benchmark for transaction-proactive throughput is specified by the so-called Transaction Performance Council (TPC) association, which is called TPC-C based. TPC members include companies in Sun, IBM, Oracle, BEA, Microsoft and Most of the sales intermediate / database layers.
The TPC-C benchmark is evaluated a system that the highest workload of the system is available. The measurement unit defined by the TPC-C reference is TPMC, which represents the number of transactions per minute (Transactions Per Minute). In addition to this reference, the transaction processing of transactions in the distributed order input system environment will not be discussed. Description of this reference can be obtained in TPC website [11]. (http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?ResultType=All)
In MoneyBroker, the number of TPC-C has made its platform a user choice, and it is facing two issues.
The first question is that the transaction processing specified in TPC-C is completely different from MoneyBroker transaction processing. This requires MoneyBroker to completely review TPC-C specification, guess how much TPC-C transactions in workload can be comparable to a MoneyBroker. We assume that MoneyBroker calculates a transaction with 10 TPC-C, thereby having a large number of surplet for handling errors.
The second question is that there is no J2EE developer has publicly published its own TPC-C number. This makes MoneyBroker difficult to calculate the throughput implemented by J2EE, namely AIX. Interestingly, although all important J2EE developers have submitted TPC-C benchmarks, no developers have submitted TPC-C based on their J2EE technology.
For example, there are 6 benchmarks for IBM's WebSphere technology (including one brand of IBM companies in J2EE technology). However, if someone studys the result of WebSphere, it will find that there is no reference code to use Java, and there is no reference to use any WebSphere J2EE performance. In fact, these benchmarks use IBM's traditional ENCINA transaction monitoring technology, which is included in total WebSphere brand. Similarly, BEA has used its traditional Tuxedo technology to run their benchmark, and Tuxedo technology is part of its WebLogic brand, but is not included in J2EE.
Since we don't have J2EE performance numbers, we must estimate the relevant performance of J2EE implementation. Since J2EE is based on a traditional transaction monitoring program (the developer has already determined the baseline), it will still increase the Java programming language. The overhead of Java virtual machines and EJB (middle layers) is a relatively reasonable speculation that J2EE will be able to complete 50% of the non-J2EE system (such as Tuxedo performance). Therefore, the author will use a 50% adjustment factor to estimate the throughput of J2EE. Below we use TPC-C information to analyze MoneyBroker behavior. MoneyBroker is trying to determine which system is purchased. Obviously, MoneyBroker wants to spend as few funds as possible, but it is still convinced that the throughput required for customer usage reaches peaks, and it is also aware of its system to expand to meet the needs of the next three years.
This year, MoneyBroker needs to handle 100,000 transactions every day. This is equivalent to handling 70 transactions per minute, with a peak to handle 700 pens per minute. Since a MoneyBroker transaction handle is equal to 10 TPMC transactions, this is about 7000 when the workload reaches peaks. Next year, this number increased by 10 times to 70000 TPMC, and the number increased by 10 times, reaching 700,000 TPMC.
So, in the next three years, what expenditures (including hardware and software) are required (including hardware and software)? Let us start from the possible spending of J2EE / UNIX, so the author will consider which one of the best represents J2EE / UNIX systems in IBM's AIX operating system, WebSphere, and Oracle 8i systems. For this configuration, there are 6 benchmarks. Press TPMC from the lowest to the highest order, and J2EE adjustment (previously discussed), the results are as follows:
Corporate systems tpmC Total System Cost Bull Escala T610 c / s 16,785 $ 1,980,179IBM RS / 6000 Enterprise Server F80 16,785 $ 2,026,681Bull Escala EPC810 c / s 33,375 $ 3,037,499IBM RS / 6000 Enterprise Server M80 33,375 $ 3,097,055Bull Escala EPC2450 110,403 $ 9,563,263IBM IBM eServer pSeries 680 Model 110,403 $ 9,560,594 7017-S85
If we consider some representative .NET platform systems (there are too many systems, it is impossible to consider, but the numbers are very consistent), the results are as follows:
The company system tpmC total system cost Dell PowerEdge 4400 16,263 $ 273,487 Compaq ProLiant ML-570-6 / 700-3P 20,207 $ 201,717Dell PowerEdge 6400 30,231 $ 334,626IBM Netfinity 7600 c / s 32,377 $ 443,463Compaq ProLiant 8500-X550-64P 161,720 $ 3,534,272 Compaq ProLiant 8500- X700-64P 179,658 $ 3,546,582Compaq ProLiant 8500-X550-96P 229,914 $ 5,305,571Compaq ProLiant 8500-X700-96P 262,244 $ 5,305,571Compaq ProLiant 8500-700-192P 505,303 $ 10,003,826 you can understand the choice MoneyBroker face. This year it only needs a 7000 TPMC system. In the UNIX market, this will cost approximately $ 2 million, while in the .NET platform market, it takes $ 2.73 million. MONEYBROKER will need a 70000 TPMC system, which takes $ 9.5 million in the J2EE / UNIX market, while in the .NET platform market, it takes $ 3.5 million. In the late years, MoneyBroker needs a 700,000 TPMC system. Among these systems, there is no one to be 700,000 TPMC, but the nearest system until there is a 10 million USET platform system. If a comparable J2EE / UNIX machine exists, it is estimated that it takes $ 47.5 million.
Obviously, if the cost of the system is an important consideration, compared with J2EE, the .NET platform has a great advantage. It is expected that the same function is to be obtained, and the cost of spend is 5 to 10 times the cost of the .NET platform. If a working unit spends 10 cents on the .NET platform, the same work unit may need to spend 50 cents to $ 1 in J2EE / UNIX.
The author needs to point out again, although these .NET platform benchmarks are the actual baseline of the actual machine, there is no truly existence in these J2EE benchmarks. These benchmarks are extrapolation benchmarks, and the actual system does not necessarily get these results. Before the J2EE developer issued their reference number, we must remember that there is no J2EE platform that has been demonstrated to handle these high workloads without cost.
Architecture support
When creating a large e-commerce solution, no one wants to start from the beginning. Instead, I hope to create a solution based on the e-commerce architecture that has been fully defined. Using such a architecture can greatly reduce the development cost, it may be lowered by at least 10 times.
The .NET platform includes a so-called Commerce Server e-commerce architecture. At this point, there is no architecture that is neither a proportional developer in J2EE space. Using J2EE, you should assume that you need to create your new e-commerce solution from your head. Paul Harmon seems to agree to this evaluation, saying: Which [J2EE] developer chooses if you expect a perfect e-commerce application that allows you to implement it quickly, you will have a frustrated experience. [12]
If you use MS Commerce Server as your e-commerce base, it is most likely that there is a great impact on the cost of the development system. Commerce Server is especially suitable for retail business. Such an e-commerce system should carefully consider this technology.
Language
In terms of language, choose very simple. J2EE supports Java and only supports Java. In the foreseeable future, it will not support any other language. The .NET platform supports any other language other than Java (although it supports a language, C #) that is quite equivalent to Java, C #). In fact, if the .NET platform is as important as a language independent vehicle, it is likely to support the .NET platform in the near future.
Some companies drive J2EE to support other languages. Although IBM's WebSphere and BEA's WebLogic support other languages, they are not implemented through J2EE technology. In J2EE platform, there are only two formal ways to access other languages, one is through Java Native Interface, and another method is to intermo it through CORBA. Sun is recommended to adopt a latter method. Just as Sun's famous scientist and Java designer Rick Cattell said in an interview:
You can call C through the Java Native Interface feature and C via CORBA. CORBA may be a recommended approach because it passes more flexibility and we have designed J2EE [13] that can work together with CORBA in an approved environment.
Creating any new code in the CORBA architecture is a very problematic policy. CORBA is a favorite architecture in the 1990s, but it is no longer used. According to the author, there is no CORBA developer (except Iona) earnings on CORBA, and there is no developer (including Iona) to continue to invest in this technology. The bottom line is if someone wants to develop any language other than Java, then J2EE is an incorrect platform selection.
Some non-Java currently is considering the possibility of re-standardization on Java. To achieve this, there are three possible methods:
Rebond new staff for existing staff, and replace existing staff outsourcing as much as possible
Rehabilitation may be the most expensive choice. With my experience, there is a lot of management costs related to the traditional programmer training into an object-oriented Java programmer. This is the result of the recent research of the Gartner Group, and it is concluded that a Cobol programmer training into a Java programmer, and each person takes approximately $ 60,000 [14]. The author believes that for Visual Basic programmers, the cost is substantially. And at the end of training, you have no time in productivity. You can simply hire a code that can now be written and the code written after 20,000 US dollars, but now you can use Java to write programmers. In many companies, the author once sees that due to the case of object-oriented technologies, working hours are often wasting the theoretical discussion of endless and no results on the "correct" object-oriented design and analysis.
Employment and / or replacement staff is expensive. Currently, the salary requested by the Java programmer is 30% higher than the traditional Visual Basic / Cobol programmer. In the experience of the author, they have a higher new employment ratio. For companies that want to turn to Java, outsourcing may be the only feasible choice. However, assuming outsourcing can completely enhance the problem mentioned above, it is clear, especially the additional programmer cost is transferred to you, even more.
So what language do you use? The bottom line is that if you have a Java training staff, and there is already a suitable strategy to ensure the effective management of the program design process, then do everything else. The author likes to use Java as a programming language, although the author thinks there is at least other good languages. On the other hand, if your store is mainly composed of Visual Basic and Cobol, then the steering Java will definitely be expensive, frustrating an experience.
Your language choice will not determine your choice between J2EE and .NET platforms. Of course, if you want to use some things outside Java, then you are in J2EE space. However, Java's appeal does not need to deprive your right to use the .NET platform. The .NET platform includes support for C # (pronunciation to C Sharp), which is a language similar to Java, so that many people cannot distinguish them. A experienced Java programmer can learn C # syntax within a few hours.
However, if you choose Java not because J2EE claims a portability strategy, C # or any other language that can be run on the .NET platform is unlikely to make you happy. If this is, it is clear that J2EE is your choice. However, before making a selection, you must read the chapter on the portability. .
portability
Many of J2EE's appeal is the commitment of portability. There are two portability. One of the developer portability. The author called this portability as a developer neutrality (Vendor NeutRality), which has been discussed (and refused) this idea. The second portability is the Operating System Portability. This refers to the ability to transfer the code base from one operating system from one operating system to another without any changes to the code. Unlike developers, most J2EE implementation is most likely to take the operating system portability.
J2EE is most likely that the operating system is portable, is largely not due to any inherent portability of J2EE, but most J2EE developers support a variety of operating systems. Therefore, it is possible that as long as a company is loyal to a established J2EE developer and a established database developer, it is possible to turn to another operating system from an operating system. This may be the only one of the most important J2EE platforms exceeding the .NET platform, and the .NET platform is limited to Windows operating systems. However, Microsoft submits a subset of C # specification and .NET Framework to ECMA (a group that standardizes JavaScript) (called Common Language Infrastructure) without value.
Why is the developer portable / neutrality and satisfactory, but what is the benefit of portability of operating system? We recognize that there are two types of companies that require operating system portability: Independent Software Developers (ISV, INDEpendent Software Vendor and companies seeking contractability).
Independent Software Developers (ISV) requires operating system portability when there is a large number of non-Windows platform customers. A developer is impossible to sell one product to UNIX customers depend on the .NET platform. If the .NET platform is better than J2EE, it is not good. It is not running on UNIX. If the independent software developer's product must be sold to non-Windows customers, especially when the J2EE platform itself needs to be bundled with independent software developers, J2EE provides an acceptable solution.
If the independent software developer's main customer base is Windows customers, then the .NET platform should be selected. It provides much products with much lower cost.
Many companies that need to operate system-portability are not independent software developers. Most companies' companies believe that portability is a path to contractability. These companies believe they, with the expansion of throughput requirements, they can get higher contraction by transplanting the application to a higher-end hardware platform.
If you believe that the operating system can contract to help you get shroomable in any way, you are making a serious mistake. Contracted is not a hardware problem; it is a software problem. The highest contraction can be obtained by seeking a highly contracted platform and then serves as much as possible. The J2EE that is running on multiple platforms is implemented, and it takes a long time in terms of receivability. So far, in terms of high-contractability, the best proven platform is .NET platform.
Use the author to give the number about the contractability of the contractability, the .NET platform can increase from 16,000 transactions per minute to more than 500,000 transactions per minute. IBM WebSphere J2EE / UNIX technology is one of the best representatives of J2EE, which may not be better than handling 17,000 to 110,000 transactions per minute, while the cost of each transaction is higher.
Therefore, portability is not as simple as it looks. If you really need a contractability, it is obvious, in the .NET platform and J2EE, .NET platform is a winner. If you have to support non-Windows platforms, it is obvious that J2EE is a winner.
If you need portability, don't rely on a moment of thought or a specific independent software developer, so forget it. This portability does not exist at all. So you have to take care of the developer seriously. Confident, you understand and feel satisfied with the developer's technical guidance. Great to your developer has a long-term commitment to the platform. Finally, it is sure that your developer has financial resources to survive on this highly competitive stage.
Client equipment independence
The author discussed the difference between the Java and .NET platform representing the layer program design model. Main differences, using Java, decided to transfer the ultimate HTML to the client to the client, and use .NET, the Visual Studio .NET control.
This Java method has three problems. The first question, it requires a lot of code that represents the layer, because each possible thin client does a different code path. The second question is difficult to test the code using each possible thin client system. The third issue is difficult to add new thin clients to existing applications, as this will involve search and modify the number of amazing representation layer logic.
The .NET Framework method is an independent code that is written with an inter-visual control interactive. Responsible for determining what HTML for transmission based on the client device is control, not a programmer.
In the .NET Framework model, a person may forget something like HTML!
This method solves all three problems of the Java / old ASP method. A person can use less code. Testing the code is easier, as you only test the interaction with the control, not the client device. Finally, you can easily add new client devices, just download the latest version of the latest knowledge about thin client devices.
From a cost perspective, .NET Framework method is no doubtful winner. If the layer developer is no longer responsible for determining which content displayed on the client device, it will easily be much easier (, much more cheap). Conclusion For e-commerce architecture, we have two mutual competitors.
Sun's J2EE concept is based on a family specification that many developers can implement. Any company can permit and implement the technology. In this sense, J2EE is open,
However, from only one developer controls the technology, it is closed and is an isolated architecture that has a very limited self-satisfaction architecture that affects each other.
One of J2EE's main disadvantages is that choosing this platform indicates using a programming language, a language that is not suitable for most companies.
One of J2EE's main advantage is that most J2EE developers provide operating system portability.
Microsoft's .NET platform idea is a product, rather than a norms that use to define interoperability points. The residence of this method is that if it is limited to the Windows platform,
The application written for the .NET platform can only be run on the .NET platform. There are several important advantages: Net platform:
Developing applications is lower, because you can use standard business languages, and you can write independent representation layer logic. The cost of running the app is lower because the item hardware platform can be used (cost is 1/5 of their UNIX opponents). The ability to telescopic is larger, proved to support the client number is 10 times the number of clients that can support any J2EET platform indicated. The interoperability is stronger, and the industrial standard electronics can be built into the platform.
The most different feature of these two platforms is the portability of the entire system. Companies seeking cost e-commerce platforms may ignore the functions provided by Microsoft due to negligence. E-commerce always requires high reliability and excellent rehabilitation. For the first time, these functions can be obtained on the commodity hardware platform with a small part of UNIX-based solutions.
