本文发表在 rolia.net 枫下论坛Concerns on MS C# vs JAVA/J2EE
Let's start by saying that you have to compare like technologies. The following list of concerns appears to compare .NET to J2EE, but this isn't a fair comparison. The proper levels of comparison are:
C# <==> Java
CLI <==> Java Bytecode
CLR <==> Java Runtime
COM+ <==> J2EE
.NET <==> Sun ONE
HailStorm <==> Sun ONE WebTop Developer (although these two
systems aren't completely comparable)
Java and Sun ONE technologies are available today.
J2EE ENVIRONMENT DOES NOT ADDRESS THE INTERNET AS AN UNDERLYING INFRASTRUCTURE
J2EE certainly does address the Internet as an underlying infrastructure, but perhaps the point you were trying to make is that J2EE is not designed to support Web services. This point is true. But if you're looking for Web services support, you should be looking at Sun ONE, which combines XML and Java technologies to provide an open, vendor-neutral, comprehensive platform for Web services. J2EE is the underlying infrastructure within the Sun ONE platform. Sun ONE layers new functionality on top of a stable J2EE core.
Customer is encouraged to visit http://www.sun.com/sunone, or engage Sun directly, to better understand our support of web services today and going forward. Sun ONE is an open architecture for deploying web services. LDAP, XML, SOAP (XMLP), WSDL, UDDI and CORBA interoperability are some examples of standards that make up the Sun ONE web services architecture.
As for J2EE: J2EE was designed to support Web applications. J2EE is the industry-accepted standard for Web application servers. There are hundreds of software products from hundreds of software vendors based on J2EE. Many production Internet services are written on top of J2EE today and continue to be going forward.
J2EE is based on TCP/IP, HTTP, HTML, LDAP, SQL, XA, CORBA IDL, and many other standards, which, at the time the J2EE spec was written, was the "Internet infrastructure". These standards still form the basis of today's Internet infrastructure. But new technologies, particularly XML, have extended the infrastructure since J2EE was defined.
Web services represent the next generation of Web applications. As the Internet matures, we find that we must continuously morph our definition of "Internet infrastructure". The Java community uses the Java Community Process (JCP) to enhance and extend the Java platform to keep up with new technologies. (see http://java.sun.com/jcp)
Since the introduction of J2EE, a number of new APIs and services have been added to the environment. For example, the Java platform now provides native support for XML processing (SAX, DOM, and XSLT) through the Java API for XML Processing (JAXP). The JSP and servlets APIs have been extended to support XML generation. EJB MessageBeans allow EJB components to converse asynchronously using messaging systems, such as XML messaging.
The JCP is hard at work extending the Java platform to provide native support for XML and Web services:
There's a brand new specification request for Web services:
JSR 109, Implementing Enterprise Web Services, which will define an initial programming model and runtime architecture for implementing Web services in Java.
Status: JSR Approved on March 20, 2001; the Expert Group is now forming.
See http://java.sun.com/jcp/jsr/jsr_109_implement.html
Another new specification request will add support for WSDL:
JSR 110, Java APIs for WSDL (JWSDL).
Status: JSR Approved on April 3, 2001; the Expert Group is now forming.
See http://java.sun.com/jcp/jsr/jsr_110_jwsdl.html
And then there's the series of Java APIs for XML (the JAX* APIs), including:
JSR 63, Java API for XML Processing V1.1 (JAXP) - an API to SAX, DOM, and XSLT processors. Status: Shipping. See:
http://java.sun.com/xml/download.html and
http://java.sun.com/jcp/jsr/jsr_063_jaxp11.html
JSR 31, Java XML Data Binding (JAXB) - a direct data binding between Java objects and XML documents. Status: specification has been in development since October 1999.
See http://java.sun.com/jcp/jsr/jsr_031_xmld.html
JSR 67, Java API for XML Messaging (JAXM) - an API for XML messaging systems such as SOAP, ebXML Message Service, and W3C XMLP. Status: specification has been in development since June 2000; a prototype (the M Project) is available. See:
http://developer.java.sun.com/developer/earlyAccess/mproject/ http://java.sun.com/jcp/jsr/jsr_067_jaxm.html
JSR 101, Java API for XML based RPC (JAX/RPC) - an API to the RPC programming model for SOAP, W3C XMLP, and other XML-based RPCs.
Status: JSR Approved on February 13, the expert group is now forming.
See http://java.sun.com/jcp/jsr/jsr_101_xrpc.html
JSR 93, Java API for XML Registries (JAXR) - an API to access UDDI and ebXML registries. Status: specification has been in development since January 2001.
See http://java.sun.com/jcp/jsr/jsr_093_jaxr.html
- J2EE DOES NOT HAVE A GOOD ANSWER FOR XML AND WEB SERVERS. IT IS TOO HEAVILY JAVA BASED AND THEREFOR WILL NOT LEVERAGE STANDARDS OF XML, SOAP AND UDDI.
Agreed. But J2EE isn't attempting to address XML, SOAP, and UDDI. Sun ONE is, and Sun ONE does. Sun ONE also addresses international standards, such as UN/CEFACT's ebXML. .NET does not support ebXML.
Sun has chosen to design the Sun ONE architecture based on Java and J2EE because it is a proven technology that works and provides choice of operating system, vendor, and J2EE implementation for our customers. The Sun ONE architecture extends Java and J2EE by providing native support for XML and Web services technologies such as SOAP, XMLP, WSDL, UDDI, and ebXML.
XML, SOAP, and UDDI are specifications which can be supported and/or implemented in any language or platform, including Java. There are at least 14 SOAP implementations that support Java. Almost all of these implementations are built on J2EE (servlets or JSP). There are only three UDDI API implementations (IBM UDDI4J, Bowstreet jUDDI, and Idoox WASP), and all of them support Java.
Sun has played a leading role in XML and related standards. Sun chaired and paid for the first W3C XML committee and continues to play a leading role in many W3C XML activities, including XML Core, XML Protocol, XPointer, XLink, SVG, XSL, and other activities. Sun is a member of the UDDI Working Group ?the group that is writing the specifications. We are participating in all of the ebXML groups, and we're leading the ebXML Proof of Concept group. We are on the board of OASIS. We are also involved in various other XML groups such as BPMI, XAML, and S2ML. We are not just following Web services standards, we are helping define them.
- MS .NET ARCHETECTURE ADDRESSES THE WEB BASED "INTEROPERABILTY STACK", FOR INTEGRATING SERVICES FOR VERY LARGE SCALE DISTRIBUTED SYSTEMS, J2EE DOES NOT.
Sun questions the claim that .NET will support "very large scale distributed systems". We certainly haven't seen any benchmarks or customer testimonials that prove .NET scalability, but that would be difficult since the .NET framework isn't available yet. Sun has plenty of benchmarks and customer testimonials that attest to the scalability of the J2EE platform. Meanwhile, Sun ONE supports the "interoperability stack" specified by .NET (SOAP messaging), as well as other XML messaging systems (ebXML, e-speak, and others) and legacy integration schemes (CORBA, Java Messaging Service, Java Connection Architecture, and others).
Sun's products and employees have been involved in building large scale distributed systems much longer than Microsoft has, and with much greater success. While Microsoft was pushing NetBIOS, NetBEUI, DCOM, and DNA as the interoperability stack, Sun and the rest of the industry were building large scale distributed systems using RPCs, CORBA, TCP/IP, and J2EE. History has taught us that open standards and technologies have proved to be the right long-term direction that provides customers with investment protection.
J2EE vendors, including Sun and our partners, are able to deliver more parts of the web-based interoperability stack today than any other technology stack. There are more large-scale web-based services based on J2EE today than any other architecture. Customers have chosen to deploy solutions using J2EE implementations, including those from Sun, iPlanet, and the many J2EE licensees. However, we do realize the need for web service interoperability, hence our support of SOAP (XMLP), UDDI, and ebXML.
The industry seems to be converging on two vendor-neutral systems for building Web services. One is based on SOAP/WSDL/UDDI. The other is based on ebXML.
UDDI is experiencing moderate adoption rates. There are about 300 companies in the UDDI community, most of whom are vendors. Thus far, approximately 2000 companies have registered in UDDI, although very few have registered any services. UDDI's success is dependent upon universal adoption by businesses from around the world -- it's supposed to be a universal registry.
ebXML is experiencing broad adoption from around the world. Thousands of vendor and non-vendor companies, government institutions, academic and research institutions, trade groups, standards bodies, and other organizations have joined the ebXML community. ebXML can be used at both local and global levels.
In addition to these systems, there will be a variety of vendor-specific approaches, such as BizTalk and e-speak. The Sun ONE architecture supports all types of Web services, built with any type of system.
Sun takes "interoperability" to a much greater degree than Microsoft. Interoperability
means not just UDDI, SOAP, and XML, which is where Microsoft's interoperability
stack ends. Microsoft's direction is to put a standards facade around a proprietary set of interfaces and products. Sun Microsystems agrees that interoperability is crucial, not just at the web services layer, but also at the lower "service infrastructure" layers that web services run on. This includes, for example, LDAP, J2EE, CORBA, ebXML, POSIX, and Unix98. This level of interoperability provides investment protection for our customers.
It is important to mention that the industry has had no participation in defining .NET. .NET is a set of products, most of which do not yet exist and will be coming out over the next two to three years. There is only one (realistic) partial implementation available (in beta form) which runs on one operating system - the Windows 2000 product. There have been hints that other implementations will be available, but a question remains -- which products that make up .NET will be (or even can be) supplied on other platforms?
Interoperability in Sun ONE allows for any LDAP implementation, any service container implementation, any operating system, any database, any messaging system, etc... How far down the interoperability stack can Microsoft go without discussing products? Can a .NET user replace Active Directory with any standard directory implementation? Can MS Kerberos be replaced by any Kerberos server? Can a .NET user replace Windows 2000 with any other operating system without sacrificing application functionality? How much will it cost to replace one LDAP implementation with another versus replacing Active Directory with an LDAP compliant directory server? How would that affect applications?
Closed architectures limit choice and increase customer risk; open architectures increase choice and limit risk. Sun focuses on the latter.
We are not stopping here. Open technologies, such as Jini (www.jini.org) and JXTA (soon to be released at www.jxta.org), address additional problem sets in the distributed computing space ranging from highly distributed, dynamic discovery, self-healing applications, to peer-to-peer applications. The open source community can (and are) building on these technologies to provide higher level distributed services, such as OpenWings (http://www.openwings.org) and the cybespace project at www.jini.org.
Microsoft is trying to confuse layers here. Again, there is a difference between the engine (J2EE, COM+) and the car (Sun ONE, .NET).
-MS .NET WILL PREVAIL OVER JAVA BECAUSE DISTRIBUTED COMPUTING WILL HAVE TO USE THE INTERNET INFRASTRUCTURE TO SURVIVE (IN THE COMMERCIAL WORLD). BECAUSE J2EE IS NOT .NET FRIENDLY IT WON'T LIVE LONG OR PROSPER.
Sun ONE uses this "Internet infrastructure" and supports full interoperability with .NET.
.NET interoperability will be available to J2EE services through SOAP in general, and JAXM and JAX/RPC in particular. J2EE applications will be able to discover .NET services through UDDI in general, and JAXR in particular. JAXM, JAX/RPC and JAXR are currently JSR's defined at http://java.sun.com/jcp.
J2EE is managed by the Java Community Process and includes the input from multiple vendors and industry experts. Many implementations already exist in the market and 1000's of web-based services are based on J2EE today. It will interoperate with forthcoming .NET services, assuming that Microsoft sticks to its announced plans to support open, Internet protocols.
- SUN DOES NOT HAVE THE STRENTGH OR SCOPE TO COUNTER THE MS .NET INITIATIVE.
Sun ONE is an open, vendor-neutral alternative to .NET. We are members of numerous very open and very active communities such as the Java community, the Jini community, the Apache community, the Linux community, and so on. NET is a proprietary, single-vendor solution. Also note that MS .NET is a counter to J2EE, not vice versa (count the number of production implementations of each).
It is not Sun versus Microsoft. It is Microsoft versus the rest of the industry.
- JAVA WRITE ONCE RUN ANYWHERE IS FAR FROM REALITY.
Java is the most portal language ever developed. There are many applications (such as Forte for Java, Borland JBuilder, TogetherJ, Sun Management Center Console, many J2EE applications, and so on ...) which run on many operating systems and J2SE implementations with no changes. NetBeans, a development environment on which Forte for Java is based, runs on MacOS X, Linux, OS/2, Windows, and Sparc Solaris/Intel without changing a bytecode.
Sun is not going to state that Write Once Run Anywhere (WORA) works without exceptions. Interoperability problems stem from bugs in vendors implementations, which get fixed. Each revision of J2SE requires more stringent testing be done to help locate incompatibilities proactively. It is vastly easier to move a J2SE or J2EE application from one system to another than it is to move existing C, C++, or VB code to .NET, and from .NET to ... anything else.
WORA protects our customers' investments by giving them choice of partners and implementations. The Java community continues to invest, support, and deploy to the Java Platform. Since you asked about WORA, that means portability is important to you. How portable is .NET?
THE GREATER THE PERFORMANCE DEMAND ON THE USER INTERFACE, THE BIGGER THE WIN FOR MS. THE TIGHT COUPLING TO THE UNDERLYING HW/SW FOR MAXIMAL MULTIMEDIA PERFORMANCE IS ONE OF THE MOST CRITICAL ISSUES AND A WIN FOR MS C#.
C# only wins on a Windows platform. Many analysts (Giga, Dataquest, Jupiter, etc.) have predicted that by 2003, more than half of Web users will access the Web using modern clients such as mobile phones, PDAs, two-way pagers, and gaming systems.
The Java Platform generated a tremendous amount of interest at the Gaming Developer Conference this March, which is arguably one of the most demanding multimedia markets. At the conference Sun showed, on top of J2SE v1.4 (pre-beta), a Quake clone written in pure Java doing 80 frames-per-second (fps) using the Java3D API. We also showed fullscreen games written on top of the Java2D API/J2SE v1.4 showing very similar results!
Java 2 v1.4 has a newly optimized 2D engine and support for graphics hardware acceleration. The advantage the Java Platform brings is the ability to write multimedia applications which are portable across chipsets and operating systems.
The HotSpot virtual machine, introduced in J2SE v1.3, highly optimizes (and inlines) Java bytecodes basically to the point where dynamically generated native machine code is writing directly to the video drivers when running on J2SE v1.4.
- THE BLEEDING EDGE ORGANIZATIONS AROUND THE BELTWAY IN DC ARE ASSESSING MASSIVE CHANGE FROM JAVA TO MS .NET. SOME GROUPS HAVE ALREADY GONE HARD OVER TO MS.
It's really hard to believe this statement since most of the .NET framework doesn't exist yet. Sun works with all the major bleeding edge organizations around the beltway.
None have abandoned Java and J2EE for .NET.
-A LOT OF REFERENCE TO THE JANUARY 24 ZDNET ARTICLE BY MARY JO FOLEY. " SUN MICROSOFT JAVA SPAT: DEVELOPERS ARE THE BIGGEST LOSERS."
We agree that Microsoft's refusal to support a compatible version of the Java Platform on the Windows operating systems is harming developers. Sun and a number of other Java licensees continue to provide high-performance Java implementations for Windows.
This particular magazine article takes a biased stance on this subject with a one-sided list of personal opinions. ZDNet did not include quotes from an opposing view, and there are many. There are many magazine articles which portray .NET in a negative light as well.
However, basing business decisions on magazine articles is a risky business practice. In 1992, Byte magazine had a cover story on "Is Unix Dead?" 9 years later Unix is more popular than ever and has enabled the tremendous the growth of the Internet. We believe that business decisions should be based on facts, not opinions.
-RICK ROSS: PRESIDENT OF JAVA LOBBY WEB SITE. "WE HAVE AN ANEMIC AND UNRELIABLE JAVA GUI IMPLIMENTATION BLOCKING US FROM THE BENIFITS OF THE WRITE ONCE RUN ANYWHERE VISION."
Rick Ross has not experienced J2SE V1.4. This is one opinion; one that has many opposing views within the industry.
-JAVA LOBBY, JASON MICHAEL SAID: "JAVA ON THE CLIENT SIDE IS A BUST: BY 2002 .NET AND C# WILL BE THE DEFACTO CLIENT TECHNOLOGY FOR DISTRIBUTED APPLICATIONS."
This is one more opinion. We can provide many positive opinions regarding Java on the client as well as negative opinions of .NET on the server. We prefer to discuss the facts regarding the value the Java Platform provides on the client. Meanwhile we're seeing great success with J2ME on a variety of devices, including mobile phones, appliances, entertainment boxes, etc. When will we see .NET and C# running on all of these modern clients?
-JERRY BURTON: ORACLE SENIOR VP, "IF MICROSOFT HAD KEPT GOING WITH JAVA, THEY WOULD HAVE CLEANED UP." "NOW JAVA IS THE CASUALTY OF THE WINDOWS VS INTERNET WAR."
We agree that Microsoft should have continued to invest in the Java Platform. If Java were in fact a casualty, then Oracle would not continue to heavily invest in the Java Platform. Oracle participates in the Java community, leads multiple JSRs through the Java Community Process, and continues to embed Java technologies within their product line.
Oracle isn't the only vendor that's continuing to invest heavily in Java: IBM, HP, Compaq, Apple, BEA, ATG, Macromedia/Allaire, SilverStream, Iona, Borland, etc., are all making major investments in Java technology.
TIEING OUR C4SR STATEGY TO JAVA/JINI MIGHT NOT BE REAL BRIGHT. DIRECT COMPETITION FROM MS C# AND PERCEIVED SUPPORT FOR JAVA GOING AWAY.
The DII COE has adopted J2EE for its middleware component architecture. This is in addition to the adoption of Java for virtually all of the COE kernel code. This was the only viable solution for a single source code tree that would run on Unix and NT platforms.
One of the true strengths of the COE is a resistance to "slideware", and .NET is not even on its radar screen since there is nothing there to test except "vision". By selecting J2EE, a cross-platform technology with multiple vendors, DISA is avoiding vendor lockin for this critical infrastructure element. This strategy is sound for anyone considering infrastructure technology.
Industry support for the Java Platform:
o Java currently has 2.5 million developers, projected to grow to over 4 million by 2003 (IDC).
o There are currently over 50,000 Jini developers.
o J2EE is the defacto standard for delivering Web services today.
o There are more Web services being developed in Java than in C++.
o 78% of universities teach Java
o 50% of universities require Java.
o JavaOne is the largest developer conference in the world, and has been consistently growing (beyond the size of the Moscone center, in fact). Customer is invited to attend the JavaOne conference the week of June 4-8th.
Developing applications on the Java Platform provides much more choice, investment protection, and less risk when compared to deploying an application to the specific products that make up .NET.
Java and Jini are implementation agnostic. There are multiple Java implementations running on multiple platforms, and Jini services are being productized by 3rd parties because of open interfaces and the involvement of the Jini Community.
If a particular solution is not appropriately addressed by Java or Jini for some reason, our suggestion would be to continue to utilize technologies which are based on standards (C, C++, Unix 98, OpenGL, CORBA, etc) and deployed to standards-compliant platforms.
DISTRIBUTED COMPUTING ENVIRONMENT: TIGHTLY COUPLED VS LOOSELY COUPLED
RAYTHEON ENGINEERS FEEL THAT J2EE MAY BE GOOD FOR TIGHTLY COUPLED SOLUTIONS FOR HIGH PERFORMANCE APPLICATIONS THAT HAVE PRIOR KNOWLEDGE OF APIS ON THE NETWORK. .NET WILL BE THE SOLUTION OF CHOICE FOR LOOSELY COUPLED DISTRIBUTED COMPUTING BECAUSE IT USES EXISTING INFRASTUCTURE AND WILL HAVE A LOWER PRICE FOR DEVELOPERS AND HAS LESS IMPACT TO LEGACY SYSTEMS. THEY BELIEVE THAT MS WILL BE THE DOMINANT PROVIDER FOR THIS TYPE OF TECHNOLOGY. THEY ALSO BELIEVE THAT MS INFRASTUCTURE WILL BE SECURE,SCALBLE AND RELIABLE. SUN SOLUTION "SMART SEVICES" FOR LOOSELY COUPLED COMPUTING WILL FAIL AND JINI POSSIBLY WILL FAIL WITH IT.
In what sense does .NET use existing infrastructure? In most cases the infrastructure hasn't been completely defined yet and lots of users are complaining about the major amounts of re-writing it will take to get to .NET.
The Web services architecture defined in Sun ONE architecture is basically identical to the architecture proposed by .NET. Both architectures rely on XML documents, packaged into XML messages, transported over standard Internet protocols (a loosely coupled distributed computing environment). Both architectures espouse the use of SOAP (eventually W3C XMLP), WSDL, and UDDI. Sun ONE also recommends the use of ebXML (which extends SOAP). (.NET does not support this international standard. .NET promotes the use of Microsoft's proprietary BizTalk Server instead.) Sun ONE recommends using J2EE to build and host the business logic that implements the Web services. .NET recommends using COM+ to build and host the business logic that implements the Web services. Within the applications, both J2EE and COM+ rely on tightly coupled communication to ensure performance and scalability. Both systems provide a variety of interoperability technologies to enable J2EE and COM+ applications to access other legacy applications. (In terms of legacy integration, there's nothing new in .NET.) The differences between the architectures are that .NET is a product-specific architecture (build your services with Microsoft products -- which don't exist yet) and Sun ONE is a product-independent architecture (build your services with whichever products best suit your business requirements).
Sun ONE addresses loosely coupled services through support of SOAP (XMLP), XML, UDDI, and ebXML. In fact, we are providing support of loosely coupled services through more than just Sun ONE: also through Jini and JXTA (Peer to Peer).
.NET requires customers to create an entirely NEW (closed) infrastructure based on proprietary products such as .NET, Active Directory, MS Kerberos, etc. Simply put, Microsoft customers have to create an entirely new (closed) infrastructure to make sure the old infrastructure doesn't have to change.
To provide investment protection going forward (and to simplify future systems integration and maintenance), infrastructure should not just have a standards facade, but also be based on standards itself. That is the current practice and direction of Sun ONE and the products which Sun and iPlanet build.
In the area of security:
o Windows 2000 is a young OS whose security has been repeatedly compromised
o .NET is unproven from a stability, scalability, and security perspective.
o Solaris Operating Environment is Common Criteria EAL4
o Trusted Solaris is B1+ certified (currently in evaluation against Common Criteria certification)
Sun and iPlanet provide the most scalable, reliable, secure, and proven standards-based platform in the industry. The industry is being built on standards, Unix implementations in general, including Solaris in particular.
In the area of reliability, no military ships have been towed to dock due to failures in Sun products.
Your last sentence implies that Customer thinks that smart services is somehow dependent on Jini. This is not the case. Sun ONE supports Web services. Jini supports Jini services. They are not the same.
Sun recommends that you select product implementations based on the requirements of each project. If these projects require a loosely-coupled computing model, then select a solution that meets those requirements. Sun provides more loosely-coupled options and products (Sun ONE, Jini, JXTA) than Microsoft provides with .NET. Sun has the added advantage that our implementations are based on standards. Also, Sun ONE and Jini are available today.
- REAL TIME: HOW DOES J2EE ADRESS DETERMINISTIC BEHAVIOR (REAL TIME).
There are two relevant JCP efforts here: JSR 1, Real-time Specification for Java, and JSR 50, Distributed Real-Time Specification for Java. What are the corresponding efforts for .NET? Does .NET address deterministic real-time behavior? JSR 1 - Real-Time Specification for Java is now in public release. See http://java.sun.com/aboutJava/communityprocess/first/jsr001/index.html
- JSR76 (RMI SECURITY FOR J2SE) AND JSR78(RMI CUSTOM REMOTE REFERENCES) HAVE BEEN VOTED DOWN BY THE EXECUTIVE COMMITTEE. THIS MEANS THAT NO RMI SECURITY WILL BE AVAILABLE FOR JAVA 1.4. WHAT IS THE IMACT FOR BATTLEFIELD DISTRIBUTED COMPUTING? (EG. "OPEN WINGS")
The security APIs that were being developed under these JSRs will now appear within the Jini community process. This was their main deployment environment, and where they address the biggest risk (mobile code and its deployment is an area of much concern within DoD, see the mobile code policy from OSD).
The fact that it was voted down shows that the Java Community Process is an open process (both of these JSRs were led by Sun). The Java Platform is not a product of Sun, but a product of the Java community.
The fact that JSR 76 did not pass means that security will not be not integrated at the RMI layer. However, secure solutions can be created using JAAS and SSL. This is done in practice today (its proven and works).
When a RMI security JSR is passed, it can be utilized. Note that there is no standards-based secure method for inter-service authorization and authentication in .NET. SOAP does not address these issues. The ebXML Message Service spec, and JAAS (Java Authentication and Authorization Services) do.
Http://www.hirrol.com/Java/J2EE_VS_NET.doc更多精彩文章及讨论，请光临枫下论坛 rolia.net
Let's start by saying that you have to compare like technologies. The following list of concerns appears to compare .NET to J2EE, but this isn't a fair comparison. The proper levels of comparison are:
C# <==> Java
CLI <==> Java Bytecode
CLR <==> Java Runtime
COM+ <==> J2EE
.NET <==> Sun ONE
HailStorm <==> Sun ONE WebTop Developer (although these two
systems aren't completely comparable)
Java and Sun ONE technologies are available today.
J2EE ENVIRONMENT DOES NOT ADDRESS THE INTERNET AS AN UNDERLYING INFRASTRUCTURE
J2EE certainly does address the Internet as an underlying infrastructure, but perhaps the point you were trying to make is that J2EE is not designed to support Web services. This point is true. But if you're looking for Web services support, you should be looking at Sun ONE, which combines XML and Java technologies to provide an open, vendor-neutral, comprehensive platform for Web services. J2EE is the underlying infrastructure within the Sun ONE platform. Sun ONE layers new functionality on top of a stable J2EE core.
Customer is encouraged to visit http://www.sun.com/sunone, or engage Sun directly, to better understand our support of web services today and going forward. Sun ONE is an open architecture for deploying web services. LDAP, XML, SOAP (XMLP), WSDL, UDDI and CORBA interoperability are some examples of standards that make up the Sun ONE web services architecture.
As for J2EE: J2EE was designed to support Web applications. J2EE is the industry-accepted standard for Web application servers. There are hundreds of software products from hundreds of software vendors based on J2EE. Many production Internet services are written on top of J2EE today and continue to be going forward.
J2EE is based on TCP/IP, HTTP, HTML, LDAP, SQL, XA, CORBA IDL, and many other standards, which, at the time the J2EE spec was written, was the "Internet infrastructure". These standards still form the basis of today's Internet infrastructure. But new technologies, particularly XML, have extended the infrastructure since J2EE was defined.
Web services represent the next generation of Web applications. As the Internet matures, we find that we must continuously morph our definition of "Internet infrastructure". The Java community uses the Java Community Process (JCP) to enhance and extend the Java platform to keep up with new technologies. (see http://java.sun.com/jcp)
Since the introduction of J2EE, a number of new APIs and services have been added to the environment. For example, the Java platform now provides native support for XML processing (SAX, DOM, and XSLT) through the Java API for XML Processing (JAXP). The JSP and servlets APIs have been extended to support XML generation. EJB MessageBeans allow EJB components to converse asynchronously using messaging systems, such as XML messaging.
The JCP is hard at work extending the Java platform to provide native support for XML and Web services:
There's a brand new specification request for Web services:
JSR 109, Implementing Enterprise Web Services, which will define an initial programming model and runtime architecture for implementing Web services in Java.
Status: JSR Approved on March 20, 2001; the Expert Group is now forming.
See http://java.sun.com/jcp/jsr/jsr_109_implement.html
Another new specification request will add support for WSDL:
JSR 110, Java APIs for WSDL (JWSDL).
Status: JSR Approved on April 3, 2001; the Expert Group is now forming.
See http://java.sun.com/jcp/jsr/jsr_110_jwsdl.html
And then there's the series of Java APIs for XML (the JAX* APIs), including:
JSR 63, Java API for XML Processing V1.1 (JAXP) - an API to SAX, DOM, and XSLT processors. Status: Shipping. See:
http://java.sun.com/xml/download.html and
http://java.sun.com/jcp/jsr/jsr_063_jaxp11.html
JSR 31, Java XML Data Binding (JAXB) - a direct data binding between Java objects and XML documents. Status: specification has been in development since October 1999.
See http://java.sun.com/jcp/jsr/jsr_031_xmld.html
JSR 67, Java API for XML Messaging (JAXM) - an API for XML messaging systems such as SOAP, ebXML Message Service, and W3C XMLP. Status: specification has been in development since June 2000; a prototype (the M Project) is available. See:
http://developer.java.sun.com/developer/earlyAccess/mproject/ http://java.sun.com/jcp/jsr/jsr_067_jaxm.html
JSR 101, Java API for XML based RPC (JAX/RPC) - an API to the RPC programming model for SOAP, W3C XMLP, and other XML-based RPCs.
Status: JSR Approved on February 13, the expert group is now forming.
See http://java.sun.com/jcp/jsr/jsr_101_xrpc.html
JSR 93, Java API for XML Registries (JAXR) - an API to access UDDI and ebXML registries. Status: specification has been in development since January 2001.
See http://java.sun.com/jcp/jsr/jsr_093_jaxr.html
- J2EE DOES NOT HAVE A GOOD ANSWER FOR XML AND WEB SERVERS. IT IS TOO HEAVILY JAVA BASED AND THEREFOR WILL NOT LEVERAGE STANDARDS OF XML, SOAP AND UDDI.
Agreed. But J2EE isn't attempting to address XML, SOAP, and UDDI. Sun ONE is, and Sun ONE does. Sun ONE also addresses international standards, such as UN/CEFACT's ebXML. .NET does not support ebXML.
Sun has chosen to design the Sun ONE architecture based on Java and J2EE because it is a proven technology that works and provides choice of operating system, vendor, and J2EE implementation for our customers. The Sun ONE architecture extends Java and J2EE by providing native support for XML and Web services technologies such as SOAP, XMLP, WSDL, UDDI, and ebXML.
XML, SOAP, and UDDI are specifications which can be supported and/or implemented in any language or platform, including Java. There are at least 14 SOAP implementations that support Java. Almost all of these implementations are built on J2EE (servlets or JSP). There are only three UDDI API implementations (IBM UDDI4J, Bowstreet jUDDI, and Idoox WASP), and all of them support Java.
Sun has played a leading role in XML and related standards. Sun chaired and paid for the first W3C XML committee and continues to play a leading role in many W3C XML activities, including XML Core, XML Protocol, XPointer, XLink, SVG, XSL, and other activities. Sun is a member of the UDDI Working Group ?the group that is writing the specifications. We are participating in all of the ebXML groups, and we're leading the ebXML Proof of Concept group. We are on the board of OASIS. We are also involved in various other XML groups such as BPMI, XAML, and S2ML. We are not just following Web services standards, we are helping define them.
- MS .NET ARCHETECTURE ADDRESSES THE WEB BASED "INTEROPERABILTY STACK", FOR INTEGRATING SERVICES FOR VERY LARGE SCALE DISTRIBUTED SYSTEMS, J2EE DOES NOT.
Sun questions the claim that .NET will support "very large scale distributed systems". We certainly haven't seen any benchmarks or customer testimonials that prove .NET scalability, but that would be difficult since the .NET framework isn't available yet. Sun has plenty of benchmarks and customer testimonials that attest to the scalability of the J2EE platform. Meanwhile, Sun ONE supports the "interoperability stack" specified by .NET (SOAP messaging), as well as other XML messaging systems (ebXML, e-speak, and others) and legacy integration schemes (CORBA, Java Messaging Service, Java Connection Architecture, and others).
Sun's products and employees have been involved in building large scale distributed systems much longer than Microsoft has, and with much greater success. While Microsoft was pushing NetBIOS, NetBEUI, DCOM, and DNA as the interoperability stack, Sun and the rest of the industry were building large scale distributed systems using RPCs, CORBA, TCP/IP, and J2EE. History has taught us that open standards and technologies have proved to be the right long-term direction that provides customers with investment protection.
J2EE vendors, including Sun and our partners, are able to deliver more parts of the web-based interoperability stack today than any other technology stack. There are more large-scale web-based services based on J2EE today than any other architecture. Customers have chosen to deploy solutions using J2EE implementations, including those from Sun, iPlanet, and the many J2EE licensees. However, we do realize the need for web service interoperability, hence our support of SOAP (XMLP), UDDI, and ebXML.
The industry seems to be converging on two vendor-neutral systems for building Web services. One is based on SOAP/WSDL/UDDI. The other is based on ebXML.
UDDI is experiencing moderate adoption rates. There are about 300 companies in the UDDI community, most of whom are vendors. Thus far, approximately 2000 companies have registered in UDDI, although very few have registered any services. UDDI's success is dependent upon universal adoption by businesses from around the world -- it's supposed to be a universal registry.
ebXML is experiencing broad adoption from around the world. Thousands of vendor and non-vendor companies, government institutions, academic and research institutions, trade groups, standards bodies, and other organizations have joined the ebXML community. ebXML can be used at both local and global levels.
In addition to these systems, there will be a variety of vendor-specific approaches, such as BizTalk and e-speak. The Sun ONE architecture supports all types of Web services, built with any type of system.
Sun takes "interoperability" to a much greater degree than Microsoft. Interoperability
means not just UDDI, SOAP, and XML, which is where Microsoft's interoperability
stack ends. Microsoft's direction is to put a standards facade around a proprietary set of interfaces and products. Sun Microsystems agrees that interoperability is crucial, not just at the web services layer, but also at the lower "service infrastructure" layers that web services run on. This includes, for example, LDAP, J2EE, CORBA, ebXML, POSIX, and Unix98. This level of interoperability provides investment protection for our customers.
It is important to mention that the industry has had no participation in defining .NET. .NET is a set of products, most of which do not yet exist and will be coming out over the next two to three years. There is only one (realistic) partial implementation available (in beta form) which runs on one operating system - the Windows 2000 product. There have been hints that other implementations will be available, but a question remains -- which products that make up .NET will be (or even can be) supplied on other platforms?
Interoperability in Sun ONE allows for any LDAP implementation, any service container implementation, any operating system, any database, any messaging system, etc... How far down the interoperability stack can Microsoft go without discussing products? Can a .NET user replace Active Directory with any standard directory implementation? Can MS Kerberos be replaced by any Kerberos server? Can a .NET user replace Windows 2000 with any other operating system without sacrificing application functionality? How much will it cost to replace one LDAP implementation with another versus replacing Active Directory with an LDAP compliant directory server? How would that affect applications?
Closed architectures limit choice and increase customer risk; open architectures increase choice and limit risk. Sun focuses on the latter.
We are not stopping here. Open technologies, such as Jini (www.jini.org) and JXTA (soon to be released at www.jxta.org), address additional problem sets in the distributed computing space ranging from highly distributed, dynamic discovery, self-healing applications, to peer-to-peer applications. The open source community can (and are) building on these technologies to provide higher level distributed services, such as OpenWings (http://www.openwings.org) and the cybespace project at www.jini.org.
Microsoft is trying to confuse layers here. Again, there is a difference between the engine (J2EE, COM+) and the car (Sun ONE, .NET).
-MS .NET WILL PREVAIL OVER JAVA BECAUSE DISTRIBUTED COMPUTING WILL HAVE TO USE THE INTERNET INFRASTRUCTURE TO SURVIVE (IN THE COMMERCIAL WORLD). BECAUSE J2EE IS NOT .NET FRIENDLY IT WON'T LIVE LONG OR PROSPER.
Sun ONE uses this "Internet infrastructure" and supports full interoperability with .NET.
.NET interoperability will be available to J2EE services through SOAP in general, and JAXM and JAX/RPC in particular. J2EE applications will be able to discover .NET services through UDDI in general, and JAXR in particular. JAXM, JAX/RPC and JAXR are currently JSR's defined at http://java.sun.com/jcp.
J2EE is managed by the Java Community Process and includes the input from multiple vendors and industry experts. Many implementations already exist in the market and 1000's of web-based services are based on J2EE today. It will interoperate with forthcoming .NET services, assuming that Microsoft sticks to its announced plans to support open, Internet protocols.
- SUN DOES NOT HAVE THE STRENTGH OR SCOPE TO COUNTER THE MS .NET INITIATIVE.
Sun ONE is an open, vendor-neutral alternative to .NET. We are members of numerous very open and very active communities such as the Java community, the Jini community, the Apache community, the Linux community, and so on. NET is a proprietary, single-vendor solution. Also note that MS .NET is a counter to J2EE, not vice versa (count the number of production implementations of each).
It is not Sun versus Microsoft. It is Microsoft versus the rest of the industry.
- JAVA WRITE ONCE RUN ANYWHERE IS FAR FROM REALITY.
Java is the most portal language ever developed. There are many applications (such as Forte for Java, Borland JBuilder, TogetherJ, Sun Management Center Console, many J2EE applications, and so on ...) which run on many operating systems and J2SE implementations with no changes. NetBeans, a development environment on which Forte for Java is based, runs on MacOS X, Linux, OS/2, Windows, and Sparc Solaris/Intel without changing a bytecode.
Sun is not going to state that Write Once Run Anywhere (WORA) works without exceptions. Interoperability problems stem from bugs in vendors implementations, which get fixed. Each revision of J2SE requires more stringent testing be done to help locate incompatibilities proactively. It is vastly easier to move a J2SE or J2EE application from one system to another than it is to move existing C, C++, or VB code to .NET, and from .NET to ... anything else.
WORA protects our customers' investments by giving them choice of partners and implementations. The Java community continues to invest, support, and deploy to the Java Platform. Since you asked about WORA, that means portability is important to you. How portable is .NET?
THE GREATER THE PERFORMANCE DEMAND ON THE USER INTERFACE, THE BIGGER THE WIN FOR MS. THE TIGHT COUPLING TO THE UNDERLYING HW/SW FOR MAXIMAL MULTIMEDIA PERFORMANCE IS ONE OF THE MOST CRITICAL ISSUES AND A WIN FOR MS C#.
C# only wins on a Windows platform. Many analysts (Giga, Dataquest, Jupiter, etc.) have predicted that by 2003, more than half of Web users will access the Web using modern clients such as mobile phones, PDAs, two-way pagers, and gaming systems.
The Java Platform generated a tremendous amount of interest at the Gaming Developer Conference this March, which is arguably one of the most demanding multimedia markets. At the conference Sun showed, on top of J2SE v1.4 (pre-beta), a Quake clone written in pure Java doing 80 frames-per-second (fps) using the Java3D API. We also showed fullscreen games written on top of the Java2D API/J2SE v1.4 showing very similar results!
Java 2 v1.4 has a newly optimized 2D engine and support for graphics hardware acceleration. The advantage the Java Platform brings is the ability to write multimedia applications which are portable across chipsets and operating systems.
The HotSpot virtual machine, introduced in J2SE v1.3, highly optimizes (and inlines) Java bytecodes basically to the point where dynamically generated native machine code is writing directly to the video drivers when running on J2SE v1.4.
- THE BLEEDING EDGE ORGANIZATIONS AROUND THE BELTWAY IN DC ARE ASSESSING MASSIVE CHANGE FROM JAVA TO MS .NET. SOME GROUPS HAVE ALREADY GONE HARD OVER TO MS.
It's really hard to believe this statement since most of the .NET framework doesn't exist yet. Sun works with all the major bleeding edge organizations around the beltway.
None have abandoned Java and J2EE for .NET.
-A LOT OF REFERENCE TO THE JANUARY 24 ZDNET ARTICLE BY MARY JO FOLEY. " SUN MICROSOFT JAVA SPAT: DEVELOPERS ARE THE BIGGEST LOSERS."
We agree that Microsoft's refusal to support a compatible version of the Java Platform on the Windows operating systems is harming developers. Sun and a number of other Java licensees continue to provide high-performance Java implementations for Windows.
This particular magazine article takes a biased stance on this subject with a one-sided list of personal opinions. ZDNet did not include quotes from an opposing view, and there are many. There are many magazine articles which portray .NET in a negative light as well.
However, basing business decisions on magazine articles is a risky business practice. In 1992, Byte magazine had a cover story on "Is Unix Dead?" 9 years later Unix is more popular than ever and has enabled the tremendous the growth of the Internet. We believe that business decisions should be based on facts, not opinions.
-RICK ROSS: PRESIDENT OF JAVA LOBBY WEB SITE. "WE HAVE AN ANEMIC AND UNRELIABLE JAVA GUI IMPLIMENTATION BLOCKING US FROM THE BENIFITS OF THE WRITE ONCE RUN ANYWHERE VISION."
Rick Ross has not experienced J2SE V1.4. This is one opinion; one that has many opposing views within the industry.
-JAVA LOBBY, JASON MICHAEL SAID: "JAVA ON THE CLIENT SIDE IS A BUST: BY 2002 .NET AND C# WILL BE THE DEFACTO CLIENT TECHNOLOGY FOR DISTRIBUTED APPLICATIONS."
This is one more opinion. We can provide many positive opinions regarding Java on the client as well as negative opinions of .NET on the server. We prefer to discuss the facts regarding the value the Java Platform provides on the client. Meanwhile we're seeing great success with J2ME on a variety of devices, including mobile phones, appliances, entertainment boxes, etc. When will we see .NET and C# running on all of these modern clients?
-JERRY BURTON: ORACLE SENIOR VP, "IF MICROSOFT HAD KEPT GOING WITH JAVA, THEY WOULD HAVE CLEANED UP." "NOW JAVA IS THE CASUALTY OF THE WINDOWS VS INTERNET WAR."
We agree that Microsoft should have continued to invest in the Java Platform. If Java were in fact a casualty, then Oracle would not continue to heavily invest in the Java Platform. Oracle participates in the Java community, leads multiple JSRs through the Java Community Process, and continues to embed Java technologies within their product line.
Oracle isn't the only vendor that's continuing to invest heavily in Java: IBM, HP, Compaq, Apple, BEA, ATG, Macromedia/Allaire, SilverStream, Iona, Borland, etc., are all making major investments in Java technology.
TIEING OUR C4SR STATEGY TO JAVA/JINI MIGHT NOT BE REAL BRIGHT. DIRECT COMPETITION FROM MS C# AND PERCEIVED SUPPORT FOR JAVA GOING AWAY.
The DII COE has adopted J2EE for its middleware component architecture. This is in addition to the adoption of Java for virtually all of the COE kernel code. This was the only viable solution for a single source code tree that would run on Unix and NT platforms.
One of the true strengths of the COE is a resistance to "slideware", and .NET is not even on its radar screen since there is nothing there to test except "vision". By selecting J2EE, a cross-platform technology with multiple vendors, DISA is avoiding vendor lockin for this critical infrastructure element. This strategy is sound for anyone considering infrastructure technology.
Industry support for the Java Platform:
o Java currently has 2.5 million developers, projected to grow to over 4 million by 2003 (IDC).
o There are currently over 50,000 Jini developers.
o J2EE is the defacto standard for delivering Web services today.
o There are more Web services being developed in Java than in C++.
o 78% of universities teach Java
o 50% of universities require Java.
o JavaOne is the largest developer conference in the world, and has been consistently growing (beyond the size of the Moscone center, in fact). Customer is invited to attend the JavaOne conference the week of June 4-8th.
Developing applications on the Java Platform provides much more choice, investment protection, and less risk when compared to deploying an application to the specific products that make up .NET.
Java and Jini are implementation agnostic. There are multiple Java implementations running on multiple platforms, and Jini services are being productized by 3rd parties because of open interfaces and the involvement of the Jini Community.
If a particular solution is not appropriately addressed by Java or Jini for some reason, our suggestion would be to continue to utilize technologies which are based on standards (C, C++, Unix 98, OpenGL, CORBA, etc) and deployed to standards-compliant platforms.
DISTRIBUTED COMPUTING ENVIRONMENT: TIGHTLY COUPLED VS LOOSELY COUPLED
RAYTHEON ENGINEERS FEEL THAT J2EE MAY BE GOOD FOR TIGHTLY COUPLED SOLUTIONS FOR HIGH PERFORMANCE APPLICATIONS THAT HAVE PRIOR KNOWLEDGE OF APIS ON THE NETWORK. .NET WILL BE THE SOLUTION OF CHOICE FOR LOOSELY COUPLED DISTRIBUTED COMPUTING BECAUSE IT USES EXISTING INFRASTUCTURE AND WILL HAVE A LOWER PRICE FOR DEVELOPERS AND HAS LESS IMPACT TO LEGACY SYSTEMS. THEY BELIEVE THAT MS WILL BE THE DOMINANT PROVIDER FOR THIS TYPE OF TECHNOLOGY. THEY ALSO BELIEVE THAT MS INFRASTUCTURE WILL BE SECURE,SCALBLE AND RELIABLE. SUN SOLUTION "SMART SEVICES" FOR LOOSELY COUPLED COMPUTING WILL FAIL AND JINI POSSIBLY WILL FAIL WITH IT.
In what sense does .NET use existing infrastructure? In most cases the infrastructure hasn't been completely defined yet and lots of users are complaining about the major amounts of re-writing it will take to get to .NET.
The Web services architecture defined in Sun ONE architecture is basically identical to the architecture proposed by .NET. Both architectures rely on XML documents, packaged into XML messages, transported over standard Internet protocols (a loosely coupled distributed computing environment). Both architectures espouse the use of SOAP (eventually W3C XMLP), WSDL, and UDDI. Sun ONE also recommends the use of ebXML (which extends SOAP). (.NET does not support this international standard. .NET promotes the use of Microsoft's proprietary BizTalk Server instead.) Sun ONE recommends using J2EE to build and host the business logic that implements the Web services. .NET recommends using COM+ to build and host the business logic that implements the Web services. Within the applications, both J2EE and COM+ rely on tightly coupled communication to ensure performance and scalability. Both systems provide a variety of interoperability technologies to enable J2EE and COM+ applications to access other legacy applications. (In terms of legacy integration, there's nothing new in .NET.) The differences between the architectures are that .NET is a product-specific architecture (build your services with Microsoft products -- which don't exist yet) and Sun ONE is a product-independent architecture (build your services with whichever products best suit your business requirements).
Sun ONE addresses loosely coupled services through support of SOAP (XMLP), XML, UDDI, and ebXML. In fact, we are providing support of loosely coupled services through more than just Sun ONE: also through Jini and JXTA (Peer to Peer).
.NET requires customers to create an entirely NEW (closed) infrastructure based on proprietary products such as .NET, Active Directory, MS Kerberos, etc. Simply put, Microsoft customers have to create an entirely new (closed) infrastructure to make sure the old infrastructure doesn't have to change.
To provide investment protection going forward (and to simplify future systems integration and maintenance), infrastructure should not just have a standards facade, but also be based on standards itself. That is the current practice and direction of Sun ONE and the products which Sun and iPlanet build.
In the area of security:
o Windows 2000 is a young OS whose security has been repeatedly compromised
o .NET is unproven from a stability, scalability, and security perspective.
o Solaris Operating Environment is Common Criteria EAL4
o Trusted Solaris is B1+ certified (currently in evaluation against Common Criteria certification)
Sun and iPlanet provide the most scalable, reliable, secure, and proven standards-based platform in the industry. The industry is being built on standards, Unix implementations in general, including Solaris in particular.
In the area of reliability, no military ships have been towed to dock due to failures in Sun products.
Your last sentence implies that Customer thinks that smart services is somehow dependent on Jini. This is not the case. Sun ONE supports Web services. Jini supports Jini services. They are not the same.
Sun recommends that you select product implementations based on the requirements of each project. If these projects require a loosely-coupled computing model, then select a solution that meets those requirements. Sun provides more loosely-coupled options and products (Sun ONE, Jini, JXTA) than Microsoft provides with .NET. Sun has the added advantage that our implementations are based on standards. Also, Sun ONE and Jini are available today.
- REAL TIME: HOW DOES J2EE ADRESS DETERMINISTIC BEHAVIOR (REAL TIME).
There are two relevant JCP efforts here: JSR 1, Real-time Specification for Java, and JSR 50, Distributed Real-Time Specification for Java. What are the corresponding efforts for .NET? Does .NET address deterministic real-time behavior? JSR 1 - Real-Time Specification for Java is now in public release. See http://java.sun.com/aboutJava/communityprocess/first/jsr001/index.html
- JSR76 (RMI SECURITY FOR J2SE) AND JSR78(RMI CUSTOM REMOTE REFERENCES) HAVE BEEN VOTED DOWN BY THE EXECUTIVE COMMITTEE. THIS MEANS THAT NO RMI SECURITY WILL BE AVAILABLE FOR JAVA 1.4. WHAT IS THE IMACT FOR BATTLEFIELD DISTRIBUTED COMPUTING? (EG. "OPEN WINGS")
The security APIs that were being developed under these JSRs will now appear within the Jini community process. This was their main deployment environment, and where they address the biggest risk (mobile code and its deployment is an area of much concern within DoD, see the mobile code policy from OSD).
The fact that it was voted down shows that the Java Community Process is an open process (both of these JSRs were led by Sun). The Java Platform is not a product of Sun, but a product of the Java community.
The fact that JSR 76 did not pass means that security will not be not integrated at the RMI layer. However, secure solutions can be created using JAAS and SSL. This is done in practice today (its proven and works).
When a RMI security JSR is passed, it can be utilized. Note that there is no standards-based secure method for inter-service authorization and authentication in .NET. SOAP does not address these issues. The ebXML Message Service spec, and JAAS (Java Authentication and Authorization Services) do.
Http://www.hirrol.com/Java/J2EE_VS_NET.doc更多精彩文章及讨论，请光临枫下论坛 rolia.net