Java 2 Enterprise Edition (J2EE)
VS
.NET platform
About two ideas of electronic enterprises
Roger sessions
ObjectWatch, Inc.
March 28, 2001 6:59 AM
This white paper copyright belongs to Derxs Austin ObjectWatch Co., Ltd. all rights reserved. It is forbidden to carry out unauthorized replication or release again. To get a copy or release, please contact: Roger@ObjectWatch.com.
Introduction.. 4
About MoneyBroker 5
Electronic business demand .. 5
Typical e-commerce architecture. 6
.NET platform architecture .. 7
.NET Framework and Visual Studio.net. 8
.NET Enterprise Server ... 9
UDDI collaboration infrastructure ... 10
.NET platform: Merge everything together ... 13
J2EE architecture. 14
Java language system ... 15
Client program design model ... 15
Intermediate layer infrastructure ... 16
Programmer enterprise API 16
J2EE: Merge all together ... 17
J2EE and .NET platform similar point .. 17
Difference between J2EE and .NET platform .. 18
Developer neutrality ... 19
Overall maturity ... 19
Interoperability and network services ... 20
Scalable ... 21
Architecture support ... 24
Language ... 25
Portability ... 26
Client equipment independence ... 28
Conclusion .. 28
Glossary .. 30
Trademark information .. 32
About the author .. 32
Acknowledgment .. 32
introduction
An e-commerce site without a profit plan is like a car without gasoline. It can look very beautiful. It may be impressed by people. It may make you pay a lot. But ultimately, where it can't go.
Last year, people have a deep understanding of this lesson. Ebusiness (ebusiness) one is released, but this is not due to lack of customers, but due to lack of programs on these customers.
In the upcoming year, profits will be as very important as in the past. However, the profit model will cooperate based on competitive transitions. In the case of repeated, the most competitive company will be the company that does not have to worry about competition, but will focus on collaboration.
For business, the rugby metaphor ("" It's flattering your opponent! ") Has passed. Future business metaphor is a symphony orchestra. The success of the overall collaboration will determine the success of each unit.
In e-commerce, collaboration means sales activities through partnerships. This means profit sharing. Profit sharing forces us to carefully check the profit model in each step of collaboration. We need to make technology in each step of the collaborative environment in each step of the collaboration environment.
Today, there are two technical ideas for electronic companies and electronic enterprises. One is the idea of Microsoft, the whole, called .NET platform. The other is the idea of Sun, the entire Java 2 Enterprise (Enterprise Edition, J2EE).
In this white paper, the author will compare the .NET platform and J2EE. The author will focus on the author's main problem that will drive electronic enterprises in the next five years: collaboration and profitability. The author will discuss the technical details of both platforms, but only discuss those details affecting collaboration or profitability.
It should be pointed out that J2EE is a specification, not a product. Many developers have implemented this specification in the product. The most important two J2EE developers / products are IBM 'WebSphere and WebLogic's WebLogic. According to Cutter Consulting [1] Company recent research report, these two developers occupy 59% of the J2EE market. Although Sun has only a small share, it is important because it controls the J2EE specification.
Each implementation details of J2EE are more than Microsoft's .NET platforms beyond the scope of this white paper. The author will make a comparison of the overall J2EE defined by Sun Corporation (J2EE Specification) to make a comparison with Microsoft's definitions. In order to make the entire discussion more accurate, the author will link this problem with a virtual enterprise Moneybroker, but although this is just an imaginary business, the problem discussed is related to any electronic company. . About MoneyBroker
MoneyBroker is just a virtual enterprise for explaining. We assume that the use of MoneyBroker is allowed to pay online. Customers can deposit in a Moneybroker account and then pay the bill online. In order to attract customers, MoneyBroker pays interest for unpaid deposit balances.
Customers can pay the bill directly or indirectly. Direct payment in the MoneyBroker website, customers can log in and arrange bill payments. Indirect payment through the Moneybroker partner. MoneyBroker partners refer to retailers who accept customers' MoneyBroker currency when they order. When a customer accesses Austinkayaks.com (another virtual enterprise), a choice of Austinkayaks.com can be provided by a MoneyBroker account when ordering Austinkayaks.com (another virtual enterprise).
MoneyBroker is profitable by investing unpaid customer deposits. The interest rate paid to the account owner and the interest rate of the investment will be the company's profit.
Electronic business demand
MoneyBroker To support Ecollaboration, ECOLLABORATION, ECOLLABORATION, computer systems running MoneyBroker must contain certain capabilities. In my experience, the most important demand is:
Interoperability - The system must be able to share information with collaborative systems. Availability - The system must be highly available; the first time Austinkayaks lose a sales chance due to the MoneyBroker system, it will be very unhappy. Second, Austinkayaks will terminate the cooperative relationship. The throughput - the system must support high transaction processing throughput, because the payment request is not only from the Moneybroker's own website, but also indirectly from its partner's website.
In order to profit, the total system cost must be as low as possible. In my experience, the most important system costs are:
Development Cost - Design and Implementation Cost of the Moneybroker System. System Management Cost - Managing the cost of the MoneyBroker system. Unit of Work Costs - Handling the cost of MoneyBroker payment. Scalability cost - with the increase of customer group, add a throughput of throughput throughout the MoneyBroker system.
In this white paper, these issues will be the main issues of the author: 3 main collaborative needs (interoperability, availability and throughput), 4 major system costs (development cost, system management cost, unit production cost And scalable costs).
Typical e-commerce architecture
The current network-based e-commerce architecture is usually based on the three-layer structure and two firewalls shown in Figure 1. These architectures do not support electronics collaboration. We will discuss the changes necessary to support electronics collaboration later.
Figure 1. 3-layer e-commerce architecture
Indicator layer
Business layer
Database layer
HTTP
HTML
Patent component agreement
Database Access API
Each layer shown in Figure 1 has a use, an architecture, an API. In this section, the author will give a general architecture overview. In the next two sections, the author will analyze the differences in J2EE and .NET platforms
The representation is responsible for working with the client. With the MoneyBroker application, this layer works with the browser-based payment thin client. The layer accepts the HTTP request from the web browser and then returns a browser to the HTML page. Different browsers have different display capabilities, so representing the layer must often adapt to HTML of a particular browser (or other thin client).
A large number of business logic is implemented in the business layer. For MoneyBroker, including the logic of the reserved customer account, and the logic of transfer when the bill is paying bill. Since the business layer is located between the representation layer and the database layer, it is often referred to as an intermediate layer.
The representation is transmitted through a method to communicate with the business layer. For the .NET platform, this protocol is usually DCOM or SOAP. For J2EE, this protocol is RMI / IIOP.
In the J2EE and .NET platform, business logic is usually packaged into components. A component is used to interacting business logic by an interface that defines a detailed definition.
Components are often used with objects (using this technology, they usually have historical relationships, but there are very few shared contents in other ways) confusion. In particular, controlling object-oriented programming and component packaging rules are very different. The author recently discussed the difference between the two technologies [2], so it will not be discussed here.
Business logic usually requires expensive resources such as database connections, threads, TCP / IP connections, and message queues. These resource demands typically make it difficult to support a large number of clients at any time, and this is a need for most e-commerce applications.
In order to solve this problem, the business level of the J2EE and .NET architecture includes a complex, supporting the intermediate structure shared by the client intermediate resource. This structure is critical to supporting a large number of clients, giving high system throughput is critical. In J2EE, this intermediate layer structure is referred to as Enterprise JavaBeans (EJB). In the .NET architecture, it is called COM .
The third layer is a database layer, and the actual data is stored in this layer. For the Moneybroker system, the database layer is used to store the customer's account information and bill payment records.
Although most large companies also have internal applications that use the database resident in the data layer (not through an e-commerce architecture), the business layer is still the main customer of the data layer. Communication between business and data layers uses specific APIs: .NET architecture Using ADO.NET, J2EE uses JDBC.
Now let us analyze the two techniques.
