亚洲成人伦理_成人午夜视频在线观看_日本免费网站_黄网站色大毛片_超碰97人人人人人蜜桃_久久在线视频

Rss & SiteMap

曙海教育集團論壇 http://www.bjzhda.cn

曙海教育集團論壇
共1 條記錄, 每頁顯示 10 條, 頁簽: [1]
[瀏覽完整版]

標題:Microsoft .NET vs. J2EE:

1樓
wangxinxin 發表于:2010-12-15 11:13:20

What exactly is the .NET platform [and] how does the .NET architecture measure up against J2EE?

Java runs on any platform with a Java VM. C# only runs in Windows for the foreseeable future.

.NET and J2EE offer pretty much the same laundry list of features, albeit in different ways.

By allowing cross-language component interactions, .NET is enfranchising Perl, Eiffel, Cobol, and other programmers.

.NET is a good thing for those of you committed to Microsoft architectures.

.NET will undoubtedly become the default development environment for Microsoft platforms.

However, several of the goals of the .NET platform are fairly lofty and not at all guaranteed to fly, at least not in the short term.

It would be easy to dismiss .NET as more Microsoft marketing-ware and continue on your merry way. But don't.

[Microsoft is] fighting Java and open source initiatives on their own terms, putting their own spin on "open" and attempting to directly address the needs of developers.

If you consider yourself an evangelist for Java or open source platforms, then the nature of the war is changing. Be prepared.

Microsoft has put a stake in the ground with SOAP, and they're pushing hard to put something understandable and useful in the hands of developers. J2EE proponents need to do the same with their platform.

Even if you don't write code dedicated to Microsoft platforms, you have probably heard by now about Microsoft .NET, Microsoft's latest volley in their campaign against all things non-Windows. If you've read the media spin from Microsoft, or browsed through the scant technical material available on the MSDN site, or even if you attended the Microsoft Professional Developers' Conference (where the .NET platform was officially "launched"), you're probably still left with at least two big questions:

And, if you think more long-term, you might have a third question rattling around your head:

  • What can we learn from the .NET architecture about pushing the envelope of enterprise software development?

The .NET framework is at a very early stage in its lifecycle, and deep details are still being eked out by the Microsoft .NET team. But we can, nevertheless, get fairly decent answers to these questions from the information that's already out there.

What is it?

Current ruminations about .NET in various forums are reminiscent of the fable of the three blind men attempting to identify an elephant: It's perceived as very different things, depending on your perspective. Some see .NET as Microsoft's next-generation Visual Studio development environment. Some see it as yet another new programming language (C#). Some see it as a new data-exchange and messaging framework, based on XML and SOAP. In reality, .NET wants to be all of these things, and a bit more.

First, let's get some concrete details. Here's one cut at an itemized list of the technical components making up the .NET platform:

  • C#, a "new" language for writing classes and components, that integrates elements of C, C++, and Java, and adds additional features, like metadata tags, related to component development.

  • A "common language runtime", which runs bytecodes in an Internal Language (IL) format. Code and objects written in one language can, ostensibly, be compiled into the IL runtime, once an IL compiler is developed for the language.

  • A set of base components, accessible from the common language runtime, that provide various functions (networking, containers, etc.).

  • ASP+, a new version of ASP that supports compilation of ASPs into the common language runtime (and therefore writing ASP scripts using any language with an IL binding).

  • Win Forms and Web Forms, new UI component frameworks accessible from Visual Studio.

  • ADO+, a new generation of ADO data access components that use XML and SOAP for data interchange.

How do .NET and J2EE compare?

As you can see, the .NET platform has an array of technologies under its umbrella. Microsoft is ostensibly presenting these as alternatives to other existing platforms, like J2EE and CORBA, in order to attract developers to the Windows platform. But how do the comparisons play out item-by-item? One way to lay out the alternatives between .NET and J2EE is shown in the following table:

Microsoft.NET J2EE Key differentiators
C# programming language Java programming language C# and Java both derive from C and C++. Most significant features (e.g., garbage collection, hierarchical namespaces) are present in both. C# borrows some of the component concepts from JavaBeans (properties/attributes, events, etc.), adds some of its own (like metadata tags), but incorporates these features into the syntax differently.

Java runs on any platform with a Java VM. C# only runs in Windows for the foreseeable future.

C# is implicitly tied into the IL common language runtime (see below), and is run as just-in-time (JIT) compiled bytecodes or compiled entirely into native code. Java code runs as Java Virtual Machine (VT) bytecodes that are either interpreted in the VM or JIT compiled, or can be compiled entirely into native code.

.NET common components (aka the ".NET Framework SDK") Java core API High-level .NET components will include support for distributed access using XML and SOAP (see ADO+ below).
Active Server Pages+ (ASP+) Java ServerPages (JSP) ASP+ will use Visual Basic, C#, and possibly other languages for code snippets. All get compiled into native code through the common language runtime (as opposed to being interpreted each time, like ASPs). JSPs use Java code (snippets, or JavaBean references), compiled into Java bytecodes (either on-demand or batch-compiled, depending on the JSP implementation).
IL Common Language Runtime Java Virtual Machine and CORBA IDL and ORB .NET common language runtime allows code in multiple languages to use a shared set of components, on Windows. Underlies nearly all of .NET framework (common components, ASP+, etc.).

Java's Virtual Machine spec allows Java bytecodes to run on any platform with a compliant JVM.

CORBA allows code in multiple languages to use a shared set of objects, on any platform with an ORB available. Not nearly as tightly integrated into J2EE framework.

Win Forms and Web Forms Java Swing Similar web components (e.g., based on JSP) not available in Java standard platform, some proprietary components available through Java IDEs, etc.

Win Forms and Web Forms RAD development supported through the MS Visual Studio IDE - no other IDE support announced at this writing. Swing support available in many Java IDEs and tools.

ADO+ and SOAP-based Web Services JDBC, EJB, JMS and Java XML Libraries (XML4J, JAXP) ADO+ is built on the premise of XML data interchange (between remote data objects and layers of multi-tier apps) on top of HTTP (AKA, SOAP). .NET's web services in general assume SOAP messaging models. EJB, JDBC, etc. leave the data interchange protocol at the developer's discretion, and operate on top of either HTTP, RMI/JRMP or IIOP.

The comparisons in this table only scratch the surface. Here's an executive summary of .NET vs. J2EE:

Features: .NET and J2EE offer pretty much the same laundry of list of features, albeit in different ways.

Portability: The .NET core works on Windows only but theoretically supports development in many languages (once sub-/supersets of these languages have been defined and IL compilers have been created for them). Also, Net's SOAP capabilities will allow components on other platforms to exchange data messages with .NET components. While a few of the elements in .NET, such as SOAP and its discovery and lookup protocols, are provided as public specifications, the core components of the framework (IL runtime environment, ASP+ internals, Win Forms and Web Forms component "contracts", etc.) are kept by Microsoft, and Microsoft will be the only provider of complete .NET development and runtime environments. There has already been some pressure by the development community for Microsoft to open up these specifications, but this would be counter to Microsoft's standard practices.

J2EE, on the other hand, works on any platform with a compliant Java VM and a compliant set of required platform services (EJB container, JMS service, etc., etc.). All of the specifications that define the J2EE platform are published and reviewed publicly, and numerous vendors offer compliant products and development environments. But J2EE is a single-language platform. Calls from/to objects in other languages are possible through CORBA, but CORBA support is not a ubiquitous part of the platform.

The Bigger Picture

These last points highlight some of the key differentiators between .NET and J2EE, and point towards Microsoft's real play here. Microsoft is doing two very notable things with .NET: It is opening up a channel to developers in other programming languages, and it is opening up a channel to non-.NET components by integrating XML and SOAP into their messaging scheme.

By allowing cross-language component interactions, .NET is enfranchising Perl, Eiffel, Cobol, and other programmers by allowing them to play in the Microsoft sandbox. Devotees of these languages are particularly amenable to gestures like this, since for the most part they have felt somewhat disenfranchised and marginalized in the Microsoft/Sun/Open Source wars. And by using XML and SOAP in their component messaging layer, Microsoft is bolstering their diplomatic face and adding an element of openness to their platform, providing ammunition against claims of proprietary behavior.

What's the correct response?

For Microsoft developers:

.NET is a good thing for those of you committed to Microsoft architectures. ASP+ is better than ASP, ADO+ is better, but different, than ADO and DCOM, C# is better than C and C++. The initial version of .NET won't be real until sometime in 2001, so you have some time to prepare, but this will undoubtedly become the default development environment for Microsoft platforms. And if you're developing within the Microsoft development framework now, you will undoubtedly benefit from adopting elements of the .NET framework into your architectures.

However, several of the goals of the .NET platform are fairly lofty and not at all guaranteed to fly, at least not in the short term. The IL common language runtime, for example, has some fairly significant hurdles to overcome before it has any real payoff for developers. Each language that wants to integrate with the component runtime has to define a subset/superset of the language that maps cleanly into and out of the IL runtime, and has to define constructs that provide the component metadata that IL requires. Then compilers (x-to-IL and IL-to-x) will have to be developed to both compile language structures (objects, components, etc.) into IL component bytecodes, and also generate language-specific interfaces to

共1 條記錄, 每頁顯示 10 條, 頁簽: [1]

Copyright © 2000 - 2009 曙海教育集團
Powered By 曙海教育集團 Version 2.2
Processed in .01563 s, 2 queries.
主站蜘蛛池模板: 中国美女撒尿txxxxx视频 | 国产激情偷乱视频一区二区三区 | 国产毛片毛片 | 日韩波多野结衣 | www日韩 | 天堂久久一区 | 国产 日韩 欧美 制服 另类 | 国产综合av| 欧美成人第一页 | 日日碰狠狠躁久久躁96avv | 国产精品久久性 | 91免费看片 | 日韩美女一区二区三区在线观看 | 日本在线中文 | 国产成人免费视频网站高清观看视频 | 91精品欧美久久久久久久 | 最新国产精品 | 亚州午夜精品 | 国产女人与拘做视频免费 | 天天操夜夜操 | 男人av的天堂| 久久久久中文字幕 | 99久久精品免费看国产小宝寻花 | 日韩av第一页 | 在线视频中文字幕 | 日韩在线不卡视频 | 国产 欧美 日韩 一区 | 天天干,夜夜操 | 欧美精品v国产精品v日韩精品 | 精品视频在线免费观看 | 国产日韩欧美电影 | 久久亚洲一区二区三区四区 | 九九视频在线观看视频6 | 美女福利网站 | 日韩一级黄色毛片 | 91pron在线| 亚洲国产欧美精品 | 1204国产成人精品视频 | 欧美视频一级 | 在线观看亚洲 | 国产视频久久久 |