知识大全 J2EE vs .NET-建置XML WebServices

Posted 2022-07-21 知

篇首语：学如逆水行舟，不进则退。本文由小常识网(cha138.com)小编为大家整理，主要介绍了知识大全 J2EE vs .NET-建置XML WebServices相关的知识，希望对你有一定的参考价值。

J2EE vs .NET-建置XML WebServices 以下文字资料是由(全榜网网www.cha138.com)小编为大家搜集整理后发布的内容，让我们赶快一起来看一下吧！

　　在本文中我们将深入的比较两种可用来建置商业XML Web Services 的平台分别是Sun Microsystems 所提供的Java Enterprise Edition (J EE)以及Microsoft所提供的 NET平台在读完本文之后您将会更加了解这两种架构的彼此优缺点而且在制定贵公司下一代Web Services决策时将有更明确的考量

　　前言

　　下一代的分布式运算时代已经来临了在过去几年中 XML 被广泛的运用于电脑运算环境中以达到在全球信息网上共享信息的远大目标如今它可以更进一步地提供运算能力上的分享从技术的观点来看 Web Services的出现并不能算是分布式计算机运算的新革命它可以结构化的呈现信息甚至是程序内部的讯息因而很自然地比XML应用程序更加引人注目

　　工业标准与企业标准

　　透过Web Services 任何应用程序可以在网络上顺利地整合在一起 Web Services的基本原理是利用标准的网络协议(例如:HTTP)来传送XML讯息这是一种非常轻便的沟通机制因此可以让任何程序语言中间层组件或平台很轻易地整合进来一般工业上或企业内部会接受成熟且广为厂商采用的业界标准更尤其是已经受过市场考验行之有年的标准有了Web Services 您就可以快速且低成本的整合两个企业部门或甚至是两个程序

　　要建置Web Services必须得采用业界通用的Web Services技术现在让我们来看看Web Services究竟是什么首先您必须先知道如何建置以及使用Web Services 其实Web Services是种很简单的XML界面适用于商业应用程序以及系统服务说穿了也就是将既有的技术旧衣新穿而已 Web Services其实是一种新一代的分布式服务在这之前有CORBA D + RMI 都是用来实作分布式架构的技术而且也被证明运作的非常顺利;而新一代的分布式服务采用的是XML技术如XML RPC和SOAP就是最佳的例子新一代的分布式技术可以用寄有的通讯协议做基础(如SMTP FTP等) 但是目前最受欢迎的方式仍然是将XML基植于HTTP这个广受欢迎但是效能并非最佳的通讯协议上即使如此这些新一代的技术尚未通过时间的考验或许他们有可能运作得很成功也可能有些许的风险存在

　　面对这么多的分布式技术 J EE平台与 NET平台的支持程度如下表:

　　对旧有分布式技术的支持:

　　对新一代Web Services的支持:

　　从上述两个图表之中我们可以得知对于姿态保守的公司而言 J EE支持了较为广泛应用于现有企业系统的分布式运算服务而 NET平台支持延伸自与D的+ 其技术前身MTS +比Enterprise JavaBeans技术早了三年我们可以推断J EE提供的分布式服务比 NET的技术领先三年此外目前企业内部使用之大型主机所使用的皆为CORBA技术 J EE对旧有技术的支持当然是最佳的因为+只能在Windows平台上运行

　　如果是态度前卫的公司使用J EE者可以选用XML RPC ( )或是SOAP ( )技术 Sun Microsystems更提供了 Java Web Service Developer Pack ( ) 供开发者开发Web Services 反观 NET技术只提供对于SOAP的支持在对于既有分布式技术支援不足的情况下对新一代分布式技术的支持又无法提供弹性的选择风险之大是可以预估的

　　就算新一代的Web Services非常稳定好了他的稳定度常常会被底层作业系统的稳定度所影响如果你选用 NET 就会被绑死在公认最不稳定的Windows平台上更糟糕的是 NET还只能在Microsoft官方的网页服务器上运作相信之前使用IIS的朋友在遭受过Nimda等不断出现的病毒恶梦之后会不会对其安全性与稳定性产生质疑? 但是如果您选用的是J EE技术那么在诸多遵循标准的厂商所提供的应用程序服务器中您可以选择最符合您需要成本最低而且又认为最佳的平台

　　总而言之我们就平台的稳定性服务器的稳定性以及产品的多样性这三方面来考量 J EE似乎优于 NET技术

　　下列的技术都是已为业界所采用而且也是通往Web Services的最佳途径:

　　提供Web Services的人员使用自己的程序语言组件与平台来开发连接与布署Web Services

　　提供Web Services的人员以WSDL (Web Services Description Language)定义Web Services WSDL文件可以让其它人知道Web Services的功用

　　提供Web Services的人员以UDDI ( Universal Description Discovery and Integration )将Web Services注册 UDDI让程序开发人员可以布署Web

　　使用者透过UDDI登录来找寻Web Services

　　使用者的程序会结合Web Services 并透过SOAP (Simple Object Access Protoco) 或XML RPC来呼叫Web Services XML RPC或SOAP 在HTTP协议上提供一份XML格式的讯息传递这是所有Web Services共同的沟通协议

　　请注意上述的机制是建置Web Services并让它运作的一种途径虽然有其他方法可以做到但我们认为这些技术是最重要且将广为业界采用的一种

　　由此可知实际上我们尚未有一致的方式来建置Web Services 建构上仍然有许多的困难需要克服以SOAP ebXML以及服务串流的规格来说众家厂商意见各异了而且SOAP最常被宣传的: 与程序语言无关与特定平台无关这两项特点会在您尝试着使用Apache SOAP与Microsoft SOAP Toolkit产生的Web Services进行沟通时彻底地粉碎(译注:这是因为xsi:type属性在实作上有分歧的关系) 除了是对于实作上细节的理解有差异之外更重要的原因是因为有人刻意地破坏标准

　　即使如此对于Web Services来说仍然有不少好消息:

　　很难得的所有的厂商包括Sun Microsystems与Microsoft等大厂均同意SOAP WSDL以及UDDI 是有潜力的好产品因此他们将在未来的产品中进

　　所有意见不一的厂商都团结在一起共同为建立Web Services的标准并广植Web Services的应用而努力

　　使用J EE / Microsoft NET来开发Web Services

　　如果您想开发一个有用的网络服系统所面临的挑战并非表面上所看如此简单您的Web Services必须可靠普及不容易出错有弹性而且必须让大家愿意接受这些严格的要求并不亚于任何企业等级的商业应用程序

　　J EE 以及 NET 是现有用来开发服务器端企业级应用程序的技术延伸这些技术的早期版本并非专门用来开发Web Services用如今Web Services已经成为趋势于是两大阵营也随之调整各自平台的解决方案因此您现在已经可以使用这些技术来开发Web Services了 J EE 以及 NET的共通愿景就是希望能达成开发Web Services的基础工程例如:跨平台的XML沟通负载平衡以及交易与其自己重新撰写这些基础工程倒不如在可提供这些服务的平台上撰写应用程式

　　但是当开发到一定规模的应用程序时会产生一定的复杂度这个时候就必须有开发工具的辅助如果您选用了其中一种平台那么您可以选用的工具如下所示:

　　J EE平台的工具有 :

　　JBuilder (Borland)

　　Forte for Java (Sun)

　　WebLogic Workshop (BEA)

　　JDeveloper (Oracle)

　　VisualAge for Java (IBM)

　　Visual Cafe (WebGain)

　　 NET平台

　　Visual Stdio NET

　　J EE

　　Java Platform Enterprise Edition (J EE) 被设计成专门用来解决多层式企业解决方案的开发布署以及管理上的问题在Sun Microsystems 所带领的诸多厂商的努力之下 J EE 已经成为一种业界标准对您而言最重要的一点就是您必须先了解J EE是一种标准而非一种产品您不能说下载 J EE 而是下载一系列的Adobe Acrobat PDF 档案这些档案会仔细说明应用程序与所在容器(Container)之间的运作规定透过遵守J EE的规定应用程式可以被部署在各种平台上的容器中 J EE阵营的目标是提供客户有多重选择产品与工具的机会并以此带动良币驱逐劣币的效应让最好的产品成为市场上的赢家要达成此理想的唯一的方法就是所有的厂商都要符合J EE标准

　　在交易安全方面 Sun Microsystems更与许多提供电子商务平台的厂商合作例如:BEA IBM以及Oracle等共同制定J EE Sun Microsystems更发起一个Java标准制定组织Java Community Process (JCP) 专门随时构思新决策来改善J EE Sun Microsystems之所以这样作的理由是因为要达到电子交易安全最好的方法就是要请所有的专家共同来制定严格的规范唯有这样的作法才能成功地达成他们整合市场的目标 J EE 是一种Java的应用您的J EE 组件必须被转译成bytecode并在Java的执行引擎下执行JRE 值得一提的是即使是相容于J EE平台的容器大多数都是以Java技术实作而成的相较于Microsoft NET在正式发行没多久时间就因为安全上的错误而发表Service Pack 来说我们应该更了解一件事就是:安全性是大家的事决不是单一厂商就能决定的

　　J EE 以及Web Services

　　J EE 在以往的Java程序语言中被定位成开发伺服端应用程序的架构它可以被用来建置传统的网站软件组件或是Web应用程序(Web Application) 到了最近 J EE更被扩充成可支持XML Web Services的标准这些Web Services可以和其他用J EE或非J EE标准所开发的Web Services沟通

　　J EE应用程序存在于一个容器之中这个容器提供企业级应用程序所需的服务当然也具有企业所需要的品质例如:交易安全以及Persistence services

　　商业层级负责商业程序与资料逻辑在大型规模的J EE应用程序中商业逻辑是利用Enterprise JavaBeans (EJB) 组件技术所建置由此可知这个层级专门用来负责商业程序以及资料逻辑的处理它可以透过Java Database Connectivity (JDBC) SQL/J来连接数据库或是透过Java Connector Architecture (JCA)技术来连结既有系统它更可以利用Java用来处理XML的API (JAXP Java API for XML Processing) 并透过Web Services技术(包括:SOAP UDDI WSDL以及ebXML)来连接其它协力厂商所提供的商业应用程序因此协力厂商们可以透过Web Services技术(包括:SOAP UDDI WSDL以及ebXML)让J EE程序彼此连接起来所以只要利用Java Servlets (这是一种支持HTTP请求/响应的Java技术)就可以从协力厂商的Web Services中接受请求了并予以响应

　　Java Servlets使用JAXP/JAXR/JAXM/JAX RPC等技术来提供Web Services运作时的所有功能 Web Services目前是扩充链接库的型态存在目前已经着手将Web Services并入J EE下一版的规格之中并成为业界共通的标准传统的客户端程序例如Java Applet或桌面应用程序将直接以Internet Inter ORB Protocol (IIOP)来连接EJB组件而非透露Web Services 如果要使用Web Services也可但是因为通常客户端的应用程序都会和J EE应用程序出自同一家厂商因此根本不需要XML Web Services来扮演沟通的角色就算真的有需要也是没有问题的浏览器以及无线装置则可以连接到Java Server Pages (JSP) 这些JSP则有着各企业自行使用HTML XHTML或WML所设计的使用者界面

　　微软的 NET 平台

　　Microsoft NET 是一项可以让企业开发智能型与企业级Web Services的产品在此要特别注意的是 NET与J EE最大的差异: NET是一项产品策略而J EE则是一项标准 Microsoft NET可说是Windows DNA的大翻修这是微软先前提供开发企业级应用程序的平台 Windows DNA 包含许多现有产品的技术包括Microsoft Transaction Server (MTS)与+ Microsoft Message Queue(MSMQ)以及Microsoft SQL Server 数据库而新的 NET Framework 则是设计来取代这些技术的并加入Web Services层级以及程序语言的改进

　　 NET应用程序存在于一个容器中这个容器提供企业级应用程序所需的服务例如:交易安全以及讯息服务 NET应用程序的商业层级是透过 NET managed 组件所开发的这个层级负责商业程序与资料逻辑它可以透过Active Data Objects(ADO NET)来连接数据库或是在现有的系统中使用Microsoft Host Integration Server 所提供的服务例如: Transaction Integrator ( TI)

　　当然它也可以透过Web Services技术(包括:SOAP UDDI WSDL以及BizTalk)来连接协力厂商的商业应用程序因此协力厂商们可以透过Web Services技术(包括:SOAP UDDI WSDL以及BizTalk)让 NET程序彼此连接起来传统的客户端程序浏览器以及无线装置则可以连接到Active Server Pages(ASP NET) 这些ASP NET则有着各企业自行使用HTML XHTML或WML所设计的使用者界面

　　比较分析

　　就产品上市时间而言:

　　在今日的市场上若要开发一个商业上的解决方案时间就是金钱错失一个小小的机会影响所及将导致一个公司成为市场先驱或成为落后的追赶者要加快产品上市时间的方法之一就是选择可以快速开发程序的Web Services平台这将让开发人员可以快速地开发与维护程序代码降低开发时程 Sun J EE 与Microsoft NET 两者都提供一些执行机制让软件开发人员可以避免触碰到一些底层复杂的部分除了在平台程序语言以及企业架构上支持XML Web Services的中间层外 Sun J EE 以及 NET还分别透过Java Runtime Environment (JRE)与Common Language Runtime (CLR)提供基础层面的服务

　　J EE还提供许有多 NET没有的功能这些功能可以加速产品上市时间例如: 状态管理服务这让开发人员可以撰写较少的程序代码而且不用管理状态因此可以说是高阶且快速的软件开发环境状态管理服务可以让您开发组件保持状态 Persistence services (entity beans)让程序开发人员在开发应用程序时不需额外撰写连接数据库的程序代码因此让数据库程序将变得易于开发与维护 Programmatic transactions让您可以拥有更多的交易控件而custom tags 让程序开发人员与网络设计人员可以更紧密地合作

　　最后我们觉得J EE与 NET所提供的这两种程序的开发环境是完全不同的 NET号称有强大的程序开发工具 Visual Studio NET Java也有各家厂商(Borland Sun BEA IBM等) 的整合式开发工具可供选择使用; 在学习难度和系统设计及开发过程上面 NET也是完全采用Java自始就采行的对象导向分析设计技术学VB NET或是C#要花的的工夫和学Java没有两样而且到系统架构设计上 OOAD UML Design Patterns等方法也是双方都采行的标准步骤

cha138/Article/program/ASP/201311/21877