Web服务的体系结构和最佳实践
城市公共信息服务平台介绍
通行证
基于OAuth2.0协议的通行证，实现多系统间授权访问。 认证流程（以微博为例） 1. 选择采用通行证 登录； 2. 跳转至通行证登 录页面； 3. 通行证登录后， 弹出授权确认页 面； 4. 用户确认后，转 向原始请求页面。
资讯类应用最佳实践
资讯内容的获取 A、内容抓取（通过网络爬虫系统将资讯信息抓取到内容管理系统指定栏目 中维护） B、运营人员内容采编（通过内容管理系统实现） C、信息数据直接获取（通过资源聚集系统将数据信息获取并导入到内容管 理系统指定栏目中维护） 应用的开发实现 WEB端，通过内容管理系统的模版工具制作资讯内容展示界面，并将资讯 内容发布为静态页面信息供应用程序使用； 移动端，通过订阅方式获取内容管理系统中维护发布的资讯数据接口，再 由客户端原生解析XML格式资讯内容信息展示； 平台提供服务目录 获取站点栏目分类信息 获取栏目文章列表信息 获取栏目下文章正文信息 （移动端）资讯推送消息服务
城市 A（自建模式） 应用资源池 渠 道 平 台
地方专项 服务 应用
调用
调用
地方平台（城市 A）
渠道平台 同步
调用 注册 通用应用 全国平台核心应用 运行资源池
调用
地方平台租用资源 池
聚集平台 全国平台 服务 接入
第三方服务系统
信息与服务资源的接入（地方）
城市 B（租用模式） 注册 城市 A（自建模式） 应用资源池
2014年5月
城市公共信息服务平台介绍 开放平台
项目经理：贺喆
目录
1 2 3
开放平台是什么
开放平台面向的对象 1+N架构模式 移动技术架构
4
5 6
开放平台最佳实践案例
平台服务目录
开放平台是什么
ArcGIS Server管理与性能优化
68.5
64.3
50
0 SHP FGDB Oracle11g PostgreSQL SQL Server
大数据不同数据源矢量查询
• 大数据不同数据源矢量查询
– Shapefile劣势很明显 – 如果是只读操作File Geodatabase表现不错 – PostgreSQL 免费且足量
吞吐量KB/S
配置用户和角色的存储
•
配置用户和角色信息存储的位置
用户角色管理
•
添加用户
-
配置完存储位置以后，立即添加user和role可能会报错，重 启som和manager服务以后就可以了。
用户角色管理
•
添加角色
开启安全设置
•
激活安全机制
-
配置完用户角色以后再激活
设置服务的访问权限
• •
激活了安全机制以后，默认情况下所有的服务都不能匿 名访问 对于已有的服务，可以用特殊角色进行授权
•
根据最大吞吐量设置实例数 (通常为每个核有2 到4个 实例
最佳的做法是运 行测试实例，在 机器上查看CPU 和内存使用情 况。最大压力下 CPU使用80%为 最优
内存瓶颈（现阶段出现几率不大）解决
•
增加主机内存
•
限制主机上实例数
-
一旦达到这个限制，服务器开始取 代最近很少使用的实例，而不是创 建新的实例
Web Server (Windows/UNIX) Web Application
Web Browser ArcGIS Desktop
Web Service
ArcGIS Desktop
Administrator (ArcCatalog)
• • • •
IETF介绍
IETFIETF是Internet工程任务组（Internet Engineering Task Force）的简写。
IETF又叫互联网工程任务组，成立于1985年底，是全球互联网最具权威的技术标准化组织，主要任务是负责互联网相关技术规范的研发和制定，当前绝大多数国际互联网技术标准出自IETF。
1.IETF概述IETF（互联网工程任务组—The Internet Engineering Task Force）是松散的、自律的、志愿的民间学术组织。
IETF是一个由为互联网技术发展做出贡献的专家自发参与和管理的国际民间机构。
它汇集了与互联网架构演化和互联网稳定运作等业务相关的网络设计者、运营者和研究人员，并向所有对该行业感兴趣的人士开放。
任何人都可以注册参加IETF的会议。
IETF大会每年举行三次，规模均在千人以上。
2.IETF体系结构IETF体系结构分为三类，一个是互联网架构委员会（IAB），第二个是互联网工程指导委员会（IESG），第三个是在八个领域里面的工作组（Working Group）。
标准制定工作具体由工作组承担，工作组分成八个领域，分别是Internet路由、传输、应用领域等等。
IAB成员由IETF参会人员选出，主要是监管各个工作组的工作状况，它必须非常认真的考虑Internet是什么，它正在发生什么变化以及我们需要它做些什么等问题。
互联网工程指导委员会（IESG）主要的职责是接收各个工作组的报告，对他们的工作进行审查，然后对他们提出的各种各样的标准、各种各样的建议提出指导性的意见，甚至从工作的方向上、质量上和程序上给予一定的指导。
IETF基本上不太涉及应用领域，但仍设立了一个应用领域。
另外凡是没有归到以上那些领域的研究课题，都把它归至此类。
IETF实际上有上百个工作组，这里是真正完成工作的地方。
IETF大量的技术性工作均由其内部的各类工作组协作完成。
这些工作组按不同类别，如路由、传输、安全等专项课题而分别组建。
文件上传下载和三层架构
⽂件上传下载和三层架构⽂件上传下载和三层架构⼀、⽂件上传method 需要使⽤ post 提交，get 限制了数据⼤⼩。
enctype 需使⽤ multipart/form-data，不然直接报错（需要⼆进制数据）。
需要提供 fifile 控件。
<%@ page contentType="text/html;charset=UTF-8" language="java" %><html><head><title>Title</title></head><body><span style="color: red">${errorMsg}</span><br/><form action="/fileType" method="post" enctype="multipart/form-data"><p>账号:<input type="text" name="username"/></p><%--input 便签 type选择file 即选择了⼀个上传⽂件控件--%><p>头像:<input type="file" name="Default"/></p><input type="submit" value="注册"></form></body></html>注意： enctype="multipart/form-data" 提交的数据，getParameter() ⽆法获取到。
最好的人力资源管理系统---朗新eHR产品介绍
26
．．．将先进技术的力量运用于人力资源管理
人力资源服务系统和管理流程电子化
Do Things Better
Do Better Things
– 缩短管理周期，减少HR工作 流程重复操作 – 工作流程自动化，消除不必 要的人为干扰因素 – 最终用户(员工)自主选择HR 信息和服务 – 事务性工作和日常服务的外 包
• 朗新eHR体系模型 • 朗新eHR功能结构 • eHr管理的含义
• 朗新e-HR系统特点
• 典型客户与成功案例 • 朗新eHR优势 • 朗新对公司eHR建设的初步理解
北京朗新天霁软件技术有限公司
28
代码体系标准化、规范化
北京朗新天霁软件技术有限公司
广州分公司 总公司 上海分公司 北京分公司 外出主管
B/S: 数据资源高度共享，信息全局掌握。只需对服务器端进行投入和管理，降低总体拥有成本，易于维护。
北京朗新天霁软件技术有限公司 18
18
朗新eHR －－ 技术架构
朗新 eHR 应用平台
Web Services
HTTP(S)
薪酬制度的个性化与差异化如何通过eHR落地；
子公司薪酬控制与监管。
北京朗新天霁软件技术有限公司
16
议程安排
• 朗新公司及朗新eHR介绍
• 人力资源管理面临的挑战和机遇 • 朗新eHR集团管控+最佳实践解决方案
• 朗新eHR体系模型 • 朗新eHR功能结构 • eHr管理的含义
• 朗新e-HR功能展示 • 朗新e-HR系统特点 • 典型客户与成功案例
• 朗新eHR优势
• 朗新对公司eHR建设的初步理解
基于Smart Client的RIA架构及其在WebGIS中的应用
些都对开发人 员提出了更高的技术要求和
Ｉ Ｔ应 用计算 模 式经 历 了不 ｍ 的 发展 阶段 ， ｌ
从 大型机刘 ｃ ／ｓ架 构 再 到 Ｂ ／ｓ架 构 ， 每 次
的 Ｓ ｒ Ｃ ｉｎ 智能客户端 ）技 术， ｍａ ｔ ｌｅ ｔ（
Ｍａ ｒＭｅｉ 的 Ｒｉ ｌ ｎ ｃｏ ｄａ ｃ Ｃｉ ｔ还 有 Ｍｏｉａ ｈ ｅ ｚｌ ｌ
饕 ≮誉 蠹警蓉≯
架构 ； Ａ ＳａｔＣｅ￣Ｗ ｂ Ｉ Ａｃ Ｉ 客 户 端 Ｐ ；ｍ ｒ ｌ ； ｅＧＳ ｒ Ｓ Ｊ ， ｉ ｎ ； Ｇ；
用的集 成者 ，更多时候是被动地去接受单
一
服务器提供 的应 用，因为安 全模型的畸
形 ，我们 无法做到在同一浏览器内流畅 地 实现跨应用集 成。 （） ５ 、基于浏 览器的技 术严格意义来
变革浪潮的领先者。新一轮的应用技术架构 是不 可避 免的 ，Ｒｌ Ａ时代的 到来充分说明 了
这一 切。 Ｓ ａ￥Ｃｉ ｔ 术 为主 流 的 ＲＡ架 ｍ ｒ ｌｎ 技 ｅ Ｉ 构颠 覆 了传 统 的 Ｂ 架 构 设 计 ， 为 Ｗ ｂ ］ ／Ｓ ｅＧＳ的 ．
的是 依赖 于这些扩展去实现更加绚丽的 图
ＲＡ 应用架构思想 Ｉ
１ １Ｂ Ｓ 架 构 的 先 天不 足 ． ／
说是依赖于在线访 问而构建的应用 ，在需 要一些离线（ ｆＬｎ ） ｏｆ ｉｅ的应用 中， 就显得有 心无力 ，毕竟从浏览器设计的一开始就是
希 望 能够 在一 个 最 小 极 限 的 “ 盒 ”模 型 沙
从 互联 网开始向社会普及 ，Ｂ Ｓ 结 ／ 构 以其 易部署 易管理 的优 点 ，成为 了网 络 应用 开发最 主流架 构 ，浏 览器成 为客 户端的唯 一工具 。这种软 件应 用 ，彻底
信息化运维内容包括三部分
信息化运维内容包括三部分：1、信息化基础设施运维：以硬件资产和软件资产可用为目的，包括支撑系统正常运行的网络系统、主机系统、安全系统、存储系统和机房专用设施和数据库等的运维服务；2、应用系统运维：以系统整体可用和为业务提供可靠服务为目的，包括业务和应用的技术运维，以及信息内容服务运维等；3、信息资源维护类：以深化信息资源共享利用为目的，包括信息资源获取、处理、存储、传输和共享使用等。
信息化运维服务传承国内最大规模钢铁企业宝钢近三十年的IT运维服务实施和管理经验，在追求为客户提供高品质IT服务目标同时，遵循ISO20000国际IT服务管理标准，致力于IT服务最佳实践（ITIL）的导入，倡导“服务管理体系化，服务技术专业化，服务实施规范化”的服务理念，多年来，随着IT运维服务实施和管理实践，宝信逐步摸索出一套符合中国国情的、具有行业特色的、高效可行的IT运维服务解决方案和服务产品。
1、IT运维咨询服务宝信作为业界领先的IT服务供应商，在IT服务管理领域努力耕耘，通过实践不断提升自身的管理水平和服务管理成熟度，积极推进行业发展，并大规模研发投入推出自有知识产权的宝信IT服务管理平台产品（eShop-ITSM）和宝信集中监控平台产品（eShop-Sure），产品遵循ITIL V3行业标准、ISO20000国际标准、ITSS国家标准，研发团队通过CMMI3认证。
2007年宝信IT服务管理体系获ISO/IEC 20000体系认证，2008年宝信信息安全管理体系获ISO/IEC27001体系认证，成为业界首批获得IT服务国际“双认证”的IT服务供应商。
2009年，宝信软件参与了中国IT服务标准（ITSS）体系建设项目。
作为主要成员，先后参与了ITSS运行维护系列标准、ITSS白皮书及ITSS培训教材的编制，并成为首批获得ITSS授权培训师资质企业。
宝信将通过IT运维咨询业务的开展，帮助企业构建健康的IT环境、坚实的IT系统和规范的IT服务管理体系，促使企业IT与业务的融合，提高企业的核心竞争力。
软件开发安全PPT课件
系统测试 集成测试
底层设计
单元测试计划
单元测试
实施
原型法（Prototyping）
为了克服瀑布模型的缺点而于1980年代提出的系统开发方法，其 特征是首先建立一个应用程序的简化版本（原型），用于检查、 分析和收集用户意见，在此基础上开发出更好的版本，再重复上 述步骤直到开发出最终版本。
24
.
软件开发模型
任务分解（WBS）是一种用于以有组织的方式定义和 组项目的各个工作元素的项目管理工具。SDLC的应以 WBS格式被示出，以使各相的妥善处理。
14
.
需求收集阶段（Requirements Gathering Phase）
% % %
安全需求
安全风险评估
隐私风险评估 需求 风险级别验收 活动
需求活动中发现的一定 比例的脆弱性将在需求 分析、威胁建模和开发 滥用案例过程中修复
编写或采购并安装安全相关代码（Write or Procure and Install Security-related Code），包括对代码的访问控制、标 识和标识/记录；
执行和评估单元测试（Perform and Evaluate Unit Tests）
执行单元测试并评估安全代码；
在最终系统中实施详细设计（Implement Detailed Design into Final System）
系统从生产环境中删除
6
.
启动（Initiation）
确定安全需求（Identify Security Needs），包括信息/ 应用的安全级别和关键程度、基本安全目标、安全控 制工作量；
评估备选方案（Evaluate Alternatives） 初始风险分析（Initial Risk Analysis），包括威胁/缺陷/风
报业集团IT运维管理平台建设思路
年第期6随着浙江日报报业集团业务系统向多元化结构发展，新媒体技术及报业信息化技术也发生日新月异的变化，集团信息化网络的规模越来越大，报业出版及发行等业务系统越来越多。
这直接推动W eb 服务器、应用服务器、数据库以及服务器虚拟化的应用快速发展，I T 部门的重要性也不断提升的同时，IT 运维面临的挑战也更加复杂化。
如，原有的机房已经不能满足现有信息化设备的发展；日益增多的信息化终端设备和放开的USB 设备权限导致病毒攻击、流量异常的情况增多；众多的业务系统和需要开启的远程监控窗口，易出现抢桌面和重复开启服务的状况；IP 地址冲突以及I P 地址不够用等现象。
如何能将现有的IT 管理小软件进行资源整合，实现统一平台的集中管理，做到跨域扫描IT 运维管理体系，并通过制定相应的流程规范来合理、高效的调配资源，使IT 运维管理架构与集团业务系统的管理架构相统一，并将网络拥塞状况直观展现，为管理者和运维工作人员报业集团IT 运维管理平台建设思路■文/王任华黄格非施芸决策提供参考。
这将是IT 运维监控系统建设项目的总体目标。
总体设计思路为更合理地配置网络资源、更好地管理网络IP 资源，及时统计用户访问量、网络带宽分析、机房环境预知和巡检等，针对集团的实际情况，我们研发了IT 运维综合管理平台（IT Operation Manage-ment platfor m ，ITOM ），为技术管理者提供了多管理领域的全方位解决方案。
I T 运维综合管理平台的设计主要分三个：1.信息采集层。
包含故障性能信息采集和故障信息采集。
性能信息采集是对运行在服务器的中间件、数据库以及应用程序的监控。
通过在被管理设备上安装监控程序的方式，然后将来自ICT 内各部分的信息标准化为通用格式，实时保存为逻辑分析提供信息基础。
包括发现网络拓扑，通过网络运行状况监控，判断网络的运行质量、运行效率、网络流量以及连通率信息等。
在信息采集层采集到的故障信息通常是逻辑故障信息。
内网安全整体解决方案
内网安全整体解决方案二〇二四年十一月目录第一章总体方案设计 (3)1.1 依据政策标准 (3)1.1.1国内政策和标准 (3)1.1.2国际标准及规范 (4)1.2 设计原则 (5)1.3 总体设计思想 (6)第二章技术体系详细设计 (8)2.1 技术体系总体防护框架 (11)2.2 内网安全计算环境详细设计 (11)2.2.1传统内网安全计算环境总体防护设计 (11)2.2.2虚拟化内网安全计算环境总体防护设计 (21)2.3 内网安全数据分析 (30)2.3.1内网安全风险态势感知 (30)2.3.2内网全景流量分析 (30)2.3.3内网多源威胁情报分析 (32)2.4 内网安全管控措施 (33)2.4.1内网安全风险主动识别 (33)2.4.2内网统一身份认证与权限管理 (35)2.4.1内网安全漏洞统一管理平台 (37)第三章内网安全防护设备清单 (38)第一章总体方案设计1.1 依据政策标准1.1.1 国内政策和标准1．《中华人民共和国计算机信息系统安全保护条例》（国务院147号令）2．《国家信息化领导小组关于加强信息安全保障工作的意见》（中办发〔2003〕27号）3．《关于信息安全等级保护工作的实施意见》（公通字〔2004〕66号）4．《信息安全等级保护管理办法》（公通字〔2007〕43号)5．《关于开展全国重要信息系统安全等级保护定级工作的通知》（公信安〔2007〕861号）6．《信息安全等级保护备案实施细则》（公信安〔2007〕1360号）7．《公安机关信息安全等级保护检查工作规范》（公信安〔2008〕736号）8．《关于加强国家电子政务工程建设项目信息安全风险评估工作的通知》（发改高技〔2008〕2071号）9．《关于开展信息安全等级保护安全建设整改工作的指导意见》（公信安〔2009〕1429号）10．国资委、公安部《关于进一步推进中央企业信息安全等级保护工作的通知》（公通字[2010]70号文）11．《关于推动信息安全等级保护测评体系建设和开展等保测评工作的通知》（公信安[2010]303号文）12．国资委《中央企业商业秘密保护暂行规定》（国资发〔2010〕41号）13．《GB/T 22239.1-XXXX 信息安全技术网络安全等级保护基本要求第1部分安全通用要求（征求意见稿）》14．《GB/T 22239.2-XXXX 信息安全技术网络安全等级保护基本要求第2部分: 云计算安全扩展要求（征求意见稿）》15．《GB/T 25070.2-XXXX 信息安全技术网络安全等级保护设计技术要求第2部分: 云计算安全要求（征求意见稿）》16．《GA/T 20—XXXX 信息安全技术网络安全等级保护定级指南（征求意见稿）》17．《信息安全技术信息系统安全等级保护基本要求》18．《信息安全技术信息系统等级保护安全设计技术要求》19．《信息安全技术信息系统安全等级保护定级指南》20．《信息安全技术信息系统安全等级保护实施指南》21．《计算机信息系统安全等级保护划分准则》22．《信息安全技术信息系统安全等级保护测评要求》23．《信息安全技术信息系统安全等级保护测评过程指南》24．《信息安全技术信息系统等级保护安全设计技术要求》25．《信息安全技术网络基础安全技术要求》26．《信息安全技术信息系统安全通用技术要求（技术类）》27．《信息安全技术信息系统物理安全技术要求（技术类）》28．《信息安全技术公共基础设施 PKI系统安全等级保护技术要求》29．《信息安全技术信息系统安全管理要求（管理类）》30．《信息安全技术信息系统安全工程管理要求（管理类）》31．《信息安全技术信息安全风险评估规范》32．《信息技术安全技术信息安全事件管理指南》33．《信息安全技术信息安全事件分类分级指南》34．《信息安全技术信息系统安全等级保护体系框架》35．《信息安全技术信息系统安全等级保护基本模型》36．《信息安全技术信息系统安全等级保护基本配置》37．《信息安全技术应用软件系统安全等级保护通用技术指南》38．《信息安全技术应用软件系统安全等级保护通用测试指南》39．《信息安全技术信息系统安全管理测评》40．《卫生行业信息安全等级保护工作的指导意见》1.1.2 国际标准及规范1．国际信息安全ISO27000系列2．国际服务管理标准ISO200003．ITIL最佳实践4．企业内控COBIT1.2 设计原则随着单位信息化建设的不断加强, 某单位内网的终端计算机数量还在不断增加, 网络中的应用日益复杂。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Web 服务的体系结构和最佳实践 级别： 初级 Kyle Brown (brownkyl@us.ibm.com), 高级技术职员, IBM Software Services for WebSphere Rachel Reinitz (rreinitz@us.ibm.com), IT 专业人员，主要从事 Web 服务的研究, IBM Software Services for WebSphere
2003 年 12 月 01 日 在本章中我们将会讨论一些由Web服务引起的体系结构上的挑战，研究如何使用（和不使用）Web服务，并了解一些在应用 Web 服务来解决艰难的体系结构问题时采用的最佳实践。
© Copyright International Business Machines Corporation 2003. All rights reserved.
本文是从 Kyle Brown、Gary Craig、David Pitt、Russell Stinehour、Mark Weitzel、Jim Amsden、Peter M. Jakab 和 Daniel Berg 合著的新书 Enterprise Java Programming with IBM WebSphere Second Edition的节选，将由 Addison-Wesley 出版社在2003年11月出版
引言 在 本章中我们将会讨论一些由Web服务引起的体系结构上的挑战，研究如何使用（和不使用）Web服务，并了解一些在应用 Web 服务来解决艰难的体系结构问题时采用的最佳实践。Web 服务是我们的体系结构路标上的最后一个部分。在本章中，您将会看到在 WebSphere 中 Web 服务通常如何使用无状态的会话 Bean 作为其组件实现。在我们的路标中，Web 服务的位置如下图所示（图34.1）。 图34.1. 体系结构路标 一些Web服务能做和不能做的事 在 采用任何一种新技术时都会存在一条常见的感情变化曲线。首先，当您开始听到一种技术的风声时，您就开始考虑它可能对解决您的特定问题有用，有正面的倾向看 法。当您知道更多时，您的激情增加，也许短期的概念性验证是成功的，并导致您用双脚跳起来，并在新的大项目中采用新技术。然后，这种技术的状态的现实表现 出来了，并且您开始发现了这种新技术的局限性。此时，您可能能够艰难地前进并使项目取得成功，即便技术存在局限性，或项目可能失败，让您感到失去希望和梦 想破灭。古老的格言“所有的万能药都变成毒药”适用于大多数新技术，并且它对于 Web 服务同样适用。
在过去的两、三年里，Web 服务开始应用于实际的应用程序，从那时起，一系列关于 Web 服务何时实用、何时不实用的基本肯定或基本否定的情形就出现了。接下来，我们将会讨论这方面的一些基本原则，并讨论各种情形，无视这一点已经使项目出现差错。
原则： 争取不要在逻辑应用层之间使用基于 XML 的 Web 服务。 当 Web 服务被用来补充其他 J2EE 技术，而不是替代它们时，它工作得最好。例如，一种极好的使用 Web 服务的方法就是，从应用程序的客户端出发，通过全球的因特网，连接到 WebSphere Application Server 中用 EJB 编写的业务逻辑。这里您得到了您的控制器和应用程序域层之间的一种良好的、清楚的隔离。这是您将会使用 EJB 的同一个地方，因此，如果您将 Web 服务作为另一个对象分布机制来考虑，那么您就会看到为什么这将是合适的。在 HTTP 之上的 SOAP 将会在 IIOP 之上 RMI 无效的地方发挥作用，因而，这将使得基于 XML 的 Web 服务能够补充现有的 EJB。
然而，人们经常在这一点上犯 错误的地方是假定，如果这在一对层之间有效，那么它将会在另一对层之间同样有效。例如，一个我们熟得不能再熟了的常见反模式（anti-pattern） 是这样的一种设计：一个持久性层被包装在一个 XML API 内，然后将它放在与需要激活这个持久层的业务逻辑隔离的流程中。在这种设计方案中，我们看到的是人们实际上将 Java 对象序列化到 XML 中，将它们通过网络发送，然后反序列化它们，用作为参数发送的对象来执行数据库查询，将数据库中的结果转换成 XML，然后将结果从网络上发送回去，仅仅只是为了将它转换成 Java 对象并最后进行操作。这种方法存在着几个严重的问题：
1. 持久性对象应该总是保留在操作它们的业务对象的本地。这种对象序列化和反序列化的开销是您应该尽可能避免的。 2. 还 没有一种切实可行的、完全实现的 Web 服务事务处理规范。如果您使用带有 Mapper 对象的实体 Bean 或会话 Bean（如果您这样选择的话），在采用 RMI-IIOP 的 EJB 中，您就可以选择（尽管不是必须的）在外部事务范围内是否包括持久化操作。如果您在持久性对象和操作它们的业务对象之间引入了一层Web服务，那么您就丧 失了这种能力。 一般来说，XML Web 服务对于细小颗粒的交互是不合适的，甚至还赶不上 RMI-IIOP。例如，不要将它放在应用程序的视图层和控制层之间。解析和 XML 生成的开销以及垃圾生成的开销将会使您的应用程序的整体性能大幅度下降。
原则：在应用程序服务器之间使用Web服务时要非常小心。 在 很多方面，系统之间的互操作性是 Web 服务的特点。因此，如果您正连接到用 Microsoft 的 .NET 编写的系统，那么使用 Web 服务几乎是肯定的。尽管您也可以用其他的机制，比如 WebSphere Application Server 的 COM 支持，但是在 Microsoft 和 IBM 平台之间实现互操作性最好的解决方案可能就是 Web 服务。
有时，连接不同厂商完全不 同的 Java 应用程序服务是可行的，但这种情况并不常见。（举例来说）通过使用 WebSphere 应用程序瘦客户端连接到 JBoss 或 WebLogic 服务器中用 WebSphere 编写的 EJB 是可能的。这会是一种比使用 HTTP 和基于 SOAP 的 Web 服务性能更好的解决方案。在另一方面，更常发生的情况是，您需要异步调用在另一个应用程序服务器或在某种遗留的服务器中编写的业务逻辑。在这种情况下，通 过 JMS 发送 XML 看上起更合理，并且如果您将面向文档的 XML 包装在 SOAP 信封中，那么它甚至会更好；您可以利用 SOAP 的 Header 结构，甚至还可能获得一些现成的功能，比如 WS 安全性（WS-Security）支持。
解决 Web 服务的限制性问题 Web 服务在处理分布式对象的一些有趣的问题方面已经证明是一种有用的方法。自从它引入起，HTTP 之上的SOAP 已经几乎变成了通过 Internet 进行应用程序到应用程序的通信的事实标准。随着一些大型网站（比如 UPS、Amazon 和 Google）开始支持 Web 服务标准，这项技术已经在 IT 业界确定了自己牢固的地位。 然而，当我们看一看在企业内部网环境中使用 Web 服务情况时，这个问题就不像讨论在全球性的 Internet 上可用的系统时那样有明确的答案。当在全球性的 Internet 上使用时，Web 服务具有很多的优点。例如：
由 于 Web 服务最常用的传输协议是 HTTP（大多数 Internet 基础结构也是以 HTTP 协议为基础构建的），所以通过 HTTP 对应用程序进行操作、管理、负载均衡和授权访问比通过其他协议要少一些麻烦。例如，大多数公司已经采用了一种 DMZ 防火墙策略，这种策略允许一组受保护的服务器接收 HTTP 或 HTTPs 协议上的传入流量，但不接收其他协议上的传入流量。这是一种颇具讽刺性的情况，大多数企业之所以允许使用 HTTP，是因为它被认为是一种“安全的”访问web 内容的协议。现在使用 Web 服务，所有类型的业务流量都可以通过企业的防火墙进行传输。仅仅假定因为您的 Web 服务流量是在 HTTP 上传输的所以就认为它是“安全的”是不合适的。您需要与安全性组织展开对话，讨论什么样的业务功能应该在 Internet 上公开以及应该采取怎样的防范措施来保护它们。 Web 服务很快地变得无处不在。这是由于非同寻常的历史性事件，Microsoft 和 Java 第一次同时支持一项分布式技术。由于现在能够理解基本协议的 SOAP 引擎和工具很常见，所以不再要求用与编写 Web 服务的服务器相同的工具来编写 Web 服务的客户端。这将使企业之间通过全球性的 Internet 进行通信成为可能，因为业务合作伙伴不需要假定会话的两边的实现方式。
然而，如果我们考虑一个系统，在这个系统中大多数用户将使用企业的内部网，那么克服 Web 服务和 SOAP 的下列障碍将变得更具有决定性的意义。这些障碍是：
首 要地，我们已经发现，现有的 SOAP 引擎在 Web 服务调用和使用 EJB 协议（RMI-IIOP）的等价调用之间的性能差异简直就有一个数量级。虽然使用 Web 服务的粒度非常大的方法对于业务合作伙伴之间很少进行的通信可能是适用的，但是将它们用于紧耦合、高容量的内部应用程序很可能就是不适当的。例如，每分钟 都接收到来自各个用户的数十或数百个请求的呼叫中心（call-center）对于 Web 服务来说或许就不是一个好的候选者。在这样的一种情况下，生成和解析 XML 的开销是成问题的。 尽管业界正在推进 Web 服务的标准化验证和授权，但不幸的是，大多数现有的 J2EE 产品组为此提供的支持并不完全，还没有达到它们为 J2EE 协议（比如 RMI-IIOP）所提供的支持的程度。
向 前看，这些问题中的许多能够以一种巧妙的方式通过提议的 Web 服务的多协议支持来解决。例如，如果 WSDL 的标准 RMI-IIOP 绑定可以通过 JAX-RPC 实现，那么您就可以简单地选择正确的端口来完成您的 WSDL 中的工作。然而，由于这种方法的标准没有确定，所以这些问题还是现实的难题。
因此，没有一种分布方法可以解决所有的问题， 很多组织已经得出了这样的结论，他们需要在其企业内支持多分布式对象协议和访问机制。可能需要把单个的应用程序 API 作为外部 Web 服务，对于内部远程客户端使用 HTTP 之上的 SOAP 和 RMI-IIOP 之上的 SOAP，在应用程序服务器中使用本地 EJB 引用，甚至有可能将 MQ 之上的 SOAP 用于异步交互。这个问题可以分成两个部分来解决。首先，我们如何通过多分布协议提供对业务逻辑的访问，其次，我们使用什么样的客户端编程模型来提供对远程 业务逻辑的访问。