mp817/
共76个网摘 [
1 2 3 ]
下一页 |
访问mp817的个人空间
mp817收录，使用标签：中间件，时间：2007-4-13 14:27:23 | 相关网摘，我也收藏
2.平台化软件的设计要求
1)具备灵活方便的二次开发能力
传统的管理软件大多脱胎于财务软件和MRPII的结合，这种结合不仅生硬、集成度不高，而且结构僵化、死板，无法适应千变万化的企业环境和需求，在客户化和二次开发过程时往往进度缓慢，实施困难。作为新一代软件系统，平台化软件则应该具备更好的应用开发和维护的工具和接口，实施时可以迅速根据用户的特点进行部署和二次开发，用户可以最大限度地使用贴近自身特点的管理软件。
2)实现分布式应用系统
传统的管理软件局限于内部的资源管理。平台化软件应该将整条产业链上的多家企业通过Internet和数据平台组成一个更加紧密的协同化生产组织，实现企业与企业之间的资源共享，疏通企业的各自的信息孤岛，实现各类功能互连、互通、互动的有效集成。过去以自身为主的企业与企业之间的竞争，转变成为协同化作业的企业链与企业链之间的竞争，极大地增强企业的竞争能力。
3)做到硬件独立和软件环境独立
这样做给用户带来的好处是，用户不必关心采用何种硬件或数据库平台，应用软件也不受硬件平台的迁移的影响。例如，大部分传统的国产管理软件系统只能支持windows操作系统和MS SQL Server数据库，对UNIX、OS/390等大型主机平台以及Oracle、DB2等企业级数据库就无能为力，而新一代的平台化软件则可以支持各种操作系统平台，多种数据库系统，用户可以有更灵活、广泛的选择余地。
4)实现上层应用的技术无关性
平台化软件使运行于上层的应用软件在某种程度上做到与技术无关，而是面向具体业务；一个平台可以运行企业管理系统、校园管理系统或医院管理系统等。
5)采用B/S与C/S结构相结合
B/S结构具有免安装的特点，C/S则具有更高的安全性，不安装无法访问。只要能上网，就可以通过浏览器对B/S结构系统访问，输入帐号和密码后任意机器(如网吧)可以登录系统。所以，对于网上交易、门户网站等可以采用B/S结构，但是对于重要的内部数据，如财务管理、物资管理等内部机密资料和数据，最好采用C/S结构。但是无论B/S还是C/S结构，都必须采用分布式结构，可远程网络访问，平台设计采用三层结构。
此外，工作流、报表图表工具等也应与应用开发工具组合在一起，提供一个支持管理应用开发的平台。
3.平台化软件的设计思路
1)平台架构
平台架构包括了系统的用户终端、系统管理工具和应用开发工具。用户终端主要用于组织和呈现上层应用系统内容，使用者为终端用户，如会计人员可以在用户终端进行财务数据的处理。系统管理工具主要用于上层应用和运行环境的基本维护，如系统日志查看，人员信息维护等。
应用开发工具在不同阶段可以由不同的人员维护。在应用系统开发期间由平台提供商的系统建模人员使用，用于设计和实现上层应用系统；在系统维护期间，由平台提供商的系统维护人员和用户的系统管理员共同使用(应该主要由平台提供商的系统维护人员负责)。
http://news.csdn.net/n/20070413/102755.html
mp817收录，使用标签：SOA，时间：2007-4-13 14:25:28 | 相关网摘，我也收藏
金碟与用友就象一对孪生兄弟，两家企业都经过了十几年的发展历程了，起源于研发财务软件，同时在财务软件市场上南北各占半壁江山，经过近几年的不断转型，目前都向企业信息化全方位服务的方向进行了转型，目前两家企业都是以致力推广管理软件、ERP软件、财务软件为使命，立足本地化服务及差异化的个性特征抢占市场份额。2006年刚过，用友与金碟的市场争夺大战就已经拉开了序幕，而且在07年的市场纷争中显得尤为激烈，我有幸作为一家企业的信息化顾问参与了企业ERP整个选型的过程，就我所见所闻，谈谈我对两家企业的看法。
局限性：下列我所谈到的金碟与用友的具体情况，只是发生在某一地区的个案，不具备普遍性，而且由于抽查的企业数量很少，因此个案的一些问题不能完全代表企业的实力。
1）售前产品演示比较
用友此次派出的组合是销售员+售前顾问（两人），销售人员能准确捕捉客户的心理，高效的工作作风以及热忱的服务都给我们留下了及其深刻的印象。同时售前顾问对产品的流畅介绍及表达，让我们对用友的U870产品有了更加直观的印象，相比U820，U870无论是从产品功能上，还是界面的灵活性方面都有了一个比较大的飞跃，这也给用友公司的销售人员及技术人员带来了更大的信心。
金碟此次派出的组合是一个团队（4人），重点介绍企业的K3系列产品，销售人员对客户的把握略显不足，同时在产品介绍环节中，由于人数较多，介绍产品缺乏系统性，而且现场应对也略显不足，因此给客户留下的印象并不理想。
通过前期两家公司前期对产品的介绍，应该说用友给客户留下了更深更好的印象。
2）产品功能与技术分析比较
通过仔细对比两家企业的产品发现，其实两家产品目前在技术水准上处于同一水准，而具体模块功能，处理的方式，灵活性方面表现的各有所长，两家都没有特别明显的优势，基本的功能和管理，以及业务流程都能满足企业的需求，但差异化的要求，两个产品都有差距。
http://news.csdn.net/n/20070413/102753.html
mp817收录，使用标签：业务平台，时间：2007-4-13 14:24:26 | 相关网摘，我也收藏
人们总是偏爱“大词”。一个表达方式，如果听起来足够响亮，写在纸上能够吸引眼球，那就会变成很多人的新宠。但同样是这些大词，经过太多人的传递、消费之后，原本的含义反而像硬币上的图案一样被磨损殆尽：几乎没有人知道这些说法到底是指什么了。在IT业界，“平台（platform）”、“框架（framework）”、“构架（architecture）”等等就是这种人见人爱的大词。几乎每个厂商都愿意请来其中的一位、甚至多位为自己推销。久而久之，这些说法似乎适用于各个领域、各个层面：所有的软件系统都是“平台”，所有的开发者都在自矜于独有的“框架”。原本有确切意义的“好词”，经过这一番争夺和滥用，也只能衰减为所谓的“buzzwords”，供市场营销人士们玩味了。
我想让这些词中的一个——“框架”——荡污涤垢，重现青春。要完成这样的任务，必须动用重典才行。软件业圣经《设计模式》对框架有如下定义：“A framework is a set of cooperating classes that make up a reusable design for a specific class of software（一个框架，就是一组相互协作的类，对于特定的一类软件，框架构成了一种可重用的设计）”。这个定义虽然主要着眼于面向对象的软件开发，但已经基本上给出了这个词的核心含义：框架是软件系统的设计、开发过程中的一个概念，它强调对以完成的设计、代码的重复使用，并且，一个框架主要适用于实现某一特定类型的软件系统。
为了更好地说明框架是什么，也许还应该看看框架不是什么。
框架不是现成可用的应用系统。它仍是一个半成品，等待后来者做“二次开发”，实现为具体的应用系统。
框架不是“平台”。后者的概念更加浮泛和模糊——人们说的一个平台，可以是一种操作系统，一种应用服务器，一种数据库软件，一种通信中间件等等，因此“平台”几乎成了所有系统软件的统称。在平台的大家族中，框架的概念可能与近来人们常说的“应用平台”最为接近，但平台主要指提供特定服务的系统软件，而框架则更侧重于设计、开发过程，或者可以说，框架通过调用平台提供的服务而起作用。
框架不是工具包（toolkit）/类库（library）/API。目前流行的很多框架中，就包括了大量的类库和API，但是调用API并不就是在使用框架开发。仅仅使用API时，开发者完成系统的主体部分，并不时地调用类库实现特定任务。而框架构成了通用的、具有一般性的系统主体部分，“二次开发者” 只是像做填空题一样，根据具体业务，完成特定应用系统中与众不同特殊的部分。
框架不是构架（architecture）。构架确定了系统整体结构、层次划分、不同部分之间的协作等设计考虑。框架比构架更具体，更偏重于技术实现。确定框架后，构架也随之确定，而对于同一种构架（比如web开发中的MVC），可以通过多种框架（比如Apache Struts或Apache Velocity）实现。
http://news.csdn.net/n/20070413/102748.html
mp817收录，使用标签：业务平台，时间：2007-4-13 14:22:57 | 相关网摘，我也收藏
企业已经越来越多的认识到，在国际先进管理思想的指导下，有效的利用IT技术和信息化软件系统（如ERP，CRM，SCM等），可以优化企业的业务流程，提高企业的运作的效率，为企业管理和决策提供准确的数据，从而提高企业在市场中的竞争力，实现企业盈利的目标。信息化在企业中应用成功的案例有很多，然而，令人遗憾的是企业信息化应用失败也不乏有之。当然，失败的原因有很多，有的可能是因为企业经营战略发生重大变化或管理变革受阻的问题，有的是技术不成熟问题，但更多的可能是部分系统已经应用，但是企业关心的一些具体需求却无法在系统中流畅的运转。为什么会出现这种情况呢？又该如何来解决呢？
市场上的ERP、CRM等商品化软件产品，属于通用软件产品，是针对一个或多个行业、多个用户而设计开发的软件系统。软件功能比较标准，流程设置相对规范化，注重的是一种通用性。当然，这些通用软件也会提供许多可调参数，通过设置这些参数来满足不同用户的不同需要，但这种灵活性往往是相对有限的，在很多情况下是无法通过调整软件参数来满足企业的一些特殊需求的。如以下几种现象：
现象一：由于不同企业的具有不同的具体情况和具体需求，可能会导致与ERP软件功能匹配的差异，软件商会强调ERP软件的通用性，要求企业改变其原有的流 程来适应软件，而企业又可能会强调这些特殊需求存在的必要性，如果软件中无法实现这个功能，就无法正常的进行后继的工作。
现象二：虽然ERP软件可以提供丰富的统计和分析报表，但是可能有些报表的格式与企业要求的格式差异较大，有些综合分析的报表可能需要多张报表综合整理后才能提供。
从以上出现这些现象和问题可以看出，客观上ERP软件产品业在不断的完善其功能，但也不可能做到面面俱到；要求ERP具备适应各种变化的能力，但有时也无法应对市场的快速变化。此时，通过二次开发和客户化的工作，就可以较好的解决这些“特殊需求的问题”。
企业建设信息化的方式不外乎三种：使用成熟的ERP软件+少量的二次开发；使用不太成熟的ERP系统+比重较大的二次开发；纯粹的按照企业需求定制开发。从已实施成功的案例来看，采用第一种的方式实施成功的企业最多，而且随着典范作用的影响，越来越被企业认可；采用第二种形式的也有成功者但较少，大多是一些刚刚转型做ERP的软件商在企业中完善其产品；采用第三种形式成功的几乎没有，这多是计算机系统刚刚普及时较多存在的一种形式，它最大也只能实现部分业务的自动化，现在正逐步的萎缩。
如果企业是在ERP软件选型阶段，也要考虑到这些问题出现的可能性，了解一下你正在选型的ERP软件是否可以提供二次开发和客户化的功能。实际上，众多成 熟的ERP软件商也都提供了支持的二次开发的功能和工具，如：MAPICS公司提供的报表设计器和二次开发具Centura，SAP提供的开发平台 ABAP等。需要注意的是许多ERP软件不太成熟的软件商，可能会许诺把不能实现的功能放在二次开发中，这时企业可能就变成了软件商完善产品的试验田，而且会造成“没完没了”的ERP实施。
http://news.csdn.net/n/20070413/102750.html
mp817收录，使用标签：业务平台，时间：2007-4-13 14:17:28 | 相关网摘，我也收藏
现在，我以我目前的知识水平，总结一下项目中存在的问题。
1. 合理项目计划的制定
我不是很清楚项目组是否在一开始就了解这个项目的规模，估算过项目的成本和工期，做过资源和技术的可行性研究。当我进入这个项目的时候，就被告知项目将在 3个月内完成，当时项目刚进入需求调研阶段。在还没有了解项目的大部分功能的情况下，就做好了项目的时间计划，这样项目的风险性是否过高呢？这样导致项目的开发计划不是按照功能进行个人的计划安排和项目经理进行了总体把握和调整制定的，而是按照规定的时间制定功能模块的开发计划。最后，很多功能都没有按期完成，也很难按期完成。而且，为了赶进度，代码的质量也就没有得到保证。（当然，代码质量也不止是计划导致的，还包括个人的开发经验等因素。）不合理的开发计划造成项目不但没有按照规定时间完成，项目质量也不是很好。所以，合理的项目计划对项目至关重要
2. 开发团队的稳定
项目进入需求调研阶段，项目所要求的人员并没有按照项目的要求到位，还在招聘当中。在需求调研进展一段时间后，项目组进行界面原型的开发。此时，新招聘N 人进入项目组，参与原型界面的开发，需要说明的是他们没有任何开发经验。在部分功能原型界面设计完成，项目组进入封闭开发阶段。按照项目要求，又加入招聘的N人。同时，也有N人离开项目组。项目在开发的中前期，人员一直都没有按照要求安排到位，团队也没有得到稳定，影响工作进度。而且，每次新加人员后，项目组都要安排相关的培训和业务了解，造成时间和人力的浪费。最可怕的是，人员变更导致不同的人都接手过同一模块的现状，造成现阶段代码维护的难度加大。所以，不稳定的团队，会对项目进度造成不可预计的影响。
3. 明确的项目需求
一是为了赶项目进度，二是对业务的不了解，三是业务人员业务掌握的差异，在没有全部或者大部分业务了解确认的情况，项目组开发人员就进行封闭开发，相关业务人员也在继续了解其他的业务。需求的不完整，以及错误理解，导致开发期间发生过N次的设计变更，程序无数次的改动。而且，在项目测试过程中都发生过业务改变的情况。明确的项目需求，对高效的项目开发是多么的重要。
4. 业务总体设计把握
项目缺乏业务的总体设计把握，每个人都是只了解自己负责的那部分业务，其他的模块不了解，在做模块设计的时候，也考虑不到其他模块的需求。当两个模块之间有交互时，更多的是两个模块负责人之间的沟通和交流，按照要求提供另一个模块的服务。而且，模块之间的交互设计是放在各模块开发后期进行的，后面涉及到的改动也就不可避免，还造成开发管理的混乱。
http://hi.baidu.com/yumcn/blog/item/d17a3573a6d58b1d8701b0fe.html
mp817收录，使用标签：SOA，时间：2007-4-4 9:16:43 | 相关网摘，我也收藏
4月3日消息，据Gartner最新研究成果，2007年全球50％的新的核心业务系统将会使用SOA架构，到2010年，这个比例将达到80％；同时，80％的企业现有应用系统也将在2011年前完全演进并融入到SOA的架构中。在此背景下，近日，面向构件中间件厂商普元软件（Primeton）宣布成为全球电子商务标准制定、融合与采纳的重要组织--OASIS的核心成员。目前全球仅有IBM、BEA、普元、EDS、SAP、SUN等六家公司享此殊荣。它们是全球公认的业界领袖和创新者，坚定地支持开放的、公共的电子商务标准，并能对标准的制定和采纳产生关键性的影响。（http: //www.oasis-open.org/about/foundational_sponsors.php）
据悉，这也是继2006年普元作为唯一的中国软件企业代表，参与SOA架构中两个最重要的标准--"服务构件架构"（简称SCA）和"服务数据对象"（简称SDO）制定后，又一次出现在企业软件标准参与的世界舞台中。它表明普元始终站在国际制高点，与世界同步，得以持续引领中国SOA市场发展。
OASIS（http://www.oasis-open.org/who/）是"结构化信息标准促进组织"的简称（the Organization for the Advancement of Structured Information Standards）。它制定了比其它任何组织更多的Web服务标准，同时也制定了安全和电子商务标准，并在公共部门和特定应用市场的标准化方面做出了努力。作为一个非赢利国际性协会，OASIS于1993年成立，现在参加者超过了5000，代表来自世界100多个国家的600多个组织和个人。已制定并发布的SOA中的SCA/SDO标准都将一并成为OASIS组织的电子商务标准的一部分。
作为SOA国际构件标准制定者之一，以及OASIS的核心成员，普元将为组织持续贡献自己在中国市场中的SOA实践经验。在普元看来，由于中国和发达国家的IT应用国情不同，中国的SOA将呈现与欧美市场全然不同的特点--美国等发达国家强调企业遗产系统的"重用"，变身SOA服务，而中国作为新兴的企业遗产系统较少的国家，SOA重点将在"服务（Service）"的"新建"。依此认知，普元以自己积累了近6年对面向构件的思考和实践，提出 "SOA从面向构件开始"的软件生产新思路，以避免中国企业用户重蹈软件"美国模式"中的"代码"遗产灾难覆辙。
http://news.csdn.net/n/20070404/102503.html
mp817收录，使用标签：中间件，时间：2007-4-2 13:13:59 | 相关网摘，我也收藏
近几年来，以交易中间件为框架基础的三层客户机/服务器模式已被广泛证实为建立开放式关键业务应用系统的最佳环境。这种模式的成功使用已为许多国际大型企业在应用的开发和部署方面节省了大量的时间和金钱。中间件销量正在以惊人的速度增长。据IDC资料显示，1998年中间件市场总值仅为12.34亿美元，而到2004年将达到90.3亿美元，年增长率高达39.7％。我国中间件近年来也进入了快速发展阶段，预计今后5年市场的容量将达到9亿美元左右。目前中间件市场的繁荣其实代表了软件发展的一个趋势，即各种系统应用最终将走向融合。
什么是中间件？
中间件是一种独立的服务程序，分布式应用软件借助中间件在不同的技术之间共享资源。由于中间件技术正处于发展过程之中，因此目前尚不能对它进行精确的定义。比较流行的定义是：中间件是一种独立的系统软件或服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机/服务器的操作系统之上，管理计算资源和网络通讯。中科院软件所研究员仲萃豪形象地把中间件定义为：平台＋通信。这个定义限定了只有用于分布式系统中的此类软件才能被称为中间件，同时此定义还可以把中间件与支撑软件和实用软件区分开来。
中间件位于客户机服务器的操作系统之上，管理计算资源和网络通信。目前，中间件发展很快，已经与操作系统、数据库并列为三大基础软件。中间件主要分为以下几类：
1.通信处理（消息）中间件
此类中间件能在不同平台之间通信，实现分布式系统中可靠的、高效的、实时的跨平台数据传输（如Tong LINK、BEAe Link、IBM的MQ Series等）。这是中间件中唯一不可缺少的，是销售额最大的中间件产品。
2.交易中间件
在分布式事务处理系统中要处理大量事务，常常在系统中要同时做上万笔事务。例如在北京市就要设置各种运载汽车，完成日常的运载，同时要随时监视汽车运行，出现故障时，要有排除措施，发生堵塞时要进行调度。在联机事务处理系统（OLTP）中，每笔事务常常要多台服务器上的程序顺序地协调完成，一旦中间发生某种故障时，不但要完成恢复工作，而且要自动切换系统，达到系统永不停机，实现高可靠性运行；同时要使大量事务在多台应用服务器能实时并发运行，并进行负载平衡地调度，实现昂贵的可靠性机和大型计算机系统同等的功能，为了实现这个目标，要求系统具有监视和调度整个系统的功能。BEA的Tuxedo由此而著名，它成为增长率最高的厂商。一个事务处理平台，根据X/OPEN的参数模型规定，应由事务处理中间件、通信处理中间件以及数据存取管理中间件三部分组成。东方通科技公司的Tong LINK和TongEASY实现了这个参考模型规定。
3.数据存取管理中间件
在分布式系统中，重要的数据都集中存放在数据服务器中，它们可以是关系型的、复合文档型、具有各种存放格式的多媒体型，或者是经过加密或压缩存放的，该中间件将为在网络上虚拟缓冲存取、格式转换、解压等带来方便。
http://www.myipr.com/suma/2007-03/52815.html
mp817收录，使用标签：业务平台，时间：2007-4-2 11:24:22 | 相关网摘，我也收藏
在近几年的技术革新中，软件平台化是最有意义的，也是最有生命力的。在风云乍起的平台软件市场上，基础业务平台即将扮演重要的角色，围绕这个诱人的大蛋糕，包括微软、SAP、IBM在内的国内外厂商展开了龙争虎斗。作为较早介入这一领域的实力派厂商，浪潮自有先行者的一番盘算——
我国软件产业的发展已有近20年的历史，20年来我国企业级软件应用的历史也是一部企业改革和管理创新、技术创新的历史。在这个过程中，日益广阔的市场空间一方面促进了产业规模的增长，另一方面似又加剧了一种不容回避的矛盾:尽管软件提供商与用户都很努力想将实施做好，也都具备将它做好的动力与资源，但依然不能使软件的应用满意度尽如人意。在探索解决之道的过程中，从2002年开始，包括浪潮软件在内的国内多家软件公司不约而同地提出了“软件平台”的发展战略，并推出了不同的软件平台产品。由浪潮集自主研发的第一个真正意义上基于J2EE规范的企业级应用软件开发平台——浪潮楼上开发平台(简称浪潮Loushang)已在政府、烟草、通信、税务、协同、质检、电力、金融等多个行业实现了大规模成功应用。经过研讨与论证，业界也逐渐达成了这样一种共识:“软件平台化”是解决软件应用满意度问题的一个重要方向。2005年，浪潮Loushang又成功结缘东营信产局、东北电力、国家电网、用友、中山大学、上海质监、东风汽车、上海邮政、中兴通讯、中山大学、甘肃烟草、华夏银行等，浪潮集团立足技术创新、持续产品改进，在挺进业务基础软件平台市场后取得了重大突破。
软件之“痛”
如果我们把每一个行业信息化项目都看做是一栋大楼的话，那么，软件开发商就好比建筑师。每盖一栋大楼，都要先打好地基，再一层层地往上盖。软件实施的这种运作方式导致了信息化项目实施的效率低、开发周期长、重复工作多、开发过程容易出错等。遇到新领域的信息化项目，还可能使开发工作陷入不可知的 “技术陷阱”。
中国的软件开发商在实施信息化项目中，经常都是全部重头开发。这样，很多时间和精力都浪费在重复性工作上。这是应用软件开发之“痛”，长期困扰着软件开发人员。然而浪潮在项目的具体实施中发现了这样一个规律:通常有50%的开发内容是所有行业普遍适用的;在同一行业中，这种相似性更是高达 80%。能否开发出一个基础业务平台，把这50%甚至80%的共用的东西包含进来呢?
事实上，早在1998年，浪潮就曾经和IBM合作开发过类似的工具。当时浪潮的想法是希望做一个适用于所有行业的框架，由此积累了一些宝贵的经验。2001年，浪潮在实施各省的烟草信息化项目中，抽象、提炼出了烟草行业通用的框架(代号828框架)，加速了烟草信息化的进程。
分层之“痒”
http://e.chinabyte.com/375/2277875.shtml
mp817收录，使用标签：SOA，时间：2007-4-2 9:35:14 | 相关网摘，我也收藏
去年底宣布SOA 360º平台策略后，BEA第一款以此为架构的SOA模块化组件，将在今年第三季正式登场。
BEA今日（3/30）宣布2007年SOA发展蓝图，表示随着去年底SOA 360º平台的推出，今年起将是全力发展个别模块开发的一年。该公司并将在第三季推出首款全新的SOA模块WebLogic Event Server，更预计2008年旗下三大产品线WebLogic、AquaLogic、Tuxedo都将符合SOA的模块化要求，届时也代表着SOA 360º平台已正式告成。
BEA是在去年10月发表SOA 360º平台。此平台系采用microService Architecture（mSA）为底层技术架构，藉以将BEA的应用服务器软件WebLogic、讯息传输软件AquaLogic与Tuxedo等，透过一致化的共通基础平台，拆解成可组装、重用、并具弹性的组件组合，进一步达到SOA的愿景。
将推出的WebLogic Event Server，即是运用WebLogic功能所拆解、重新组合的第一个符合mSA底层技术要求的全新SOA模块。BEA台湾区首席技术顾问黄开印解释此组件主要功能，在于能自动化实时反应、回报并修复企业中所面临的突发事件（Event）。举例来说，假使制造业工厂的机器临时发生错误状况，此套软件组件则能透过自动化演算，实时分析事件发生原因并产生回报，减低因延迟所造成的成本亏损。
这项模块尤其适于金融证券公司、或是制造业所需的实时响应需求。黄开印表示，这也是BEA全球透过与四、五家企业所共同合作模拟，所开发出的第一项SOA组件。
BEA此举也印证着SOA市场今年正进入实体化应用的趋势。
所谓的服务导向架构（SOA），旨在让原先独立且不相互支持的应用系统，转化成由中介软件及功能化模块所集合成的弹性整体平台；透过此应用，企业即可随需获取由模块所提供，并由中介软件整理而成的符合需求之服务。
SOA更已成为包括BEA、IBM、SAP、甲骨文等众家软件大厂的角力之地。为了加速开发，各家做法其实也大同小异。
http://news.csdn.net/n/20070331/102436.html
mp817收录，使用标签：SOA，时间：2007-3-28 17:14:31 | 相关网摘，我也收藏
SOA来了
2006年12月13日，BEA World大会连续第三次在中国举行。毕益辉系统有限公司(BEA)的首席执行官(CEO) 庄思浩一如既往的向听众宣传：“服务导向架构(SOA)可以帮助你改变一切工作方式”。和IBM、微软等软件厂商一样，BEA已经看到， SOA正成为不可扭转的IT应用趋势。
业内关于SOA的说法有很多，不同供应商会基于各自不同的背景，突出SOA理念中对自己最有利的卖点：提供系统整合工具的公司会突出SOA的整合价值；销售企业资源计划(ERP)软件的公司强调SOA使软件模块可重复应用的特性；那些应用平台提供商则告诉用户，部署SOA将使其应用开发变得更加简单。
中庸的讲：SOA是“Service-Oriented Architecture”，是面向服务导向架构的简称。在企业应用软件系统日趋复杂、多样化的今天，作为服务及产品的提供者，软件厂商开始抛弃传统的 “软件产品”思路而转向“以客户需求”为核心的理念，SOA正是这一思路的具体体现之一。从原理上看，SOA是一种软件系统架构，是一种面向应用服务的解决方案框架；从设计思路来看，“服务”是整个SOA实现的核心。SOA架构的基本元素是服务，在SOA架构下，“服务”是可互操作的、独立的、模块化的、位置明确的、松耦合的，并且可以通过网络查找其地址；从最终的功能上看，SOA的设计以标准、简单的接口实现不同应用服务系统之间的快速集成与整合，这降低了企业对融合应用系统的总体拥有成本(TCO)，也延伸出了新的应用模式。
谁需要SOA
从2005年开始，SOA市场开始出现增长势头，2006年是其快速发展的一年。Gartner认为SOA将成为创建和交付软件的主导框架，同时预测到 2010年时，应用软件收入增长的80%将来自基于SOA的方案；美国另一家专注于软件应用领域的咨询公司Zapthink的报告也认为，全球SOA的市场规模将会由2005年的44亿美元增加到2010年的430亿美元，5年的时间里将有近10倍的增长。
IDC全球研究副总裁兼总经理Vernon Turner认为：框架较大的大企业大公司，应该最先抓住SOA，因为它拥有十分庞大的财政、预算，非常有资本来进行SOA构架。如电信通讯行业，存在着激烈的竞争，包括用户注册量，政策，整个市场环境的影响等，非常需要这么一个架构来起指导作用。其次是普通的中小企业。在一年前， SOA还只能被大企业操纵，因为中小企业缺乏基础实力，对技术要求不高。但如今，随着竞争的激烈，业务的广泛等，中小企业对技术和信息化越来越迫切的需要会成为SOA业务的又一个增长点。而入世之后，我国急剧增长的跨国公司分支机构以及本土快速增长的中小企业为SOA的壮大提供了极其肥沃的土壤！
移动商务能否嫁入SOA的“豪门”
http://blog.sina.com.cn/u/4c211964010008y9
mp817收录，使用标签：SOA，时间：2007-3-28 16:02:26 | 相关网摘，我也收藏
NetWeaver平台的价值
SAP的管理者反驳道，NetWeaver组件支持所有重要的标准，可与其它平台交互应用。不过他们并不否认，其应用服务器配有专有引擎处理“ABAP”代码，“ABAP”是SAP特有的编程语言。
正如分析家看到的，主要的区别在于SAP不单独销售中间件。位于马萨诸塞州的Forrester调研公司副总裁John Rymer说：“Oracle已经单独销售中间件产品，而SAP目前为止仅销售应用系统。”
Rymer说，某些应用以xApps或者综合应用的形式出现，而不再是传统的模块。他同时表示，Oracle开始将自己的中间件产品与其应用平台更加紧密地结合在一起。
SAP解决方案市场营销副总裁Peter Graf说虽然可以将NetWeaver组件归类为中间件，但是“将NetWeaver说成是中间件就好比说保时捷经营方向盘业务一样片面，中间件只是这个解决方案的一个组成部分。”
SAP认为SAP的企业服务架构（ESA）是与一个个特定的业务背景相结合的，例如定义订单。NetWeaver同时包含其它的功能，包括商业智能以及用于和其他系统连接的集成代理器。
VEKA是德国的一家生产门窗合成贴面的制造商，它是NetWeaver平台的用户。总部采用SAP新近版本的R/3 ERP产品，各小型销售分支机构采用SAP Business One产品。
VEKA首席财务官Thomas Sauerlan说，名为XI的NetWeaver组件改善了VEKA公司R/3和Business One两个系统的集成度。XI集成代理器可以更为轻松地实现VEKA公司与其它客户系统间的联接。“我们从前努力实现与客户业务的集成，不过不怎么成功，”他说，“XI集成代理器可以协助我们完成这一工作。”
包括BW数据仓库在内的NetWeaver商业智能组件改善了VEKA公司管理报告的及时性。Sauerlan说，此前不同数据源间数据转换任务非常繁重，业务报告每月生成一次，采用NetWeaver所支持商业智能组件后，报告每日生成一次。VEKA同样使用NetWeaver企业门户以及它的移动应用架构组件。
谁是赢家？
到目前为止谁赢得了这场中间件之争？站在技术的角度，它可能是Oracle。 Forrester调研公司的Rymer主持了2004年的一项市场研究，结果显示Oracle的应用平台、企业门户以及集成服务器的市场占有率高于 SAP，甚至高于IBM的同类中间件产品。Rymer说，Oracle的中间件产品具有更为丰富的功能，以及相对低廉的成本。
http://industry.ccidnet.com/art/884/20060402/494697_2.html
mp817收录，使用标签：中间件，时间：2007-3-28 11:00:13 | 相关网摘，我也收藏
Easily Access, Use, and Reuse any IT Asset
WebLogic Workshop 8.1 enables any developer to easily connect to and use any IT asset with Java Controls, including databases, systems, custom or vendor applications, Web services, and much more. Java Controls hide the J2EE complexity in connecting to any asset, and can be used in any Workshop application, from Web apps and Web services to Portal and Integration applications. New with WebLogic Workshop 8.1 - create custom Java Controls, or use a host of new Java Controls from BEA partners.
WebLogic Workshop 8.1 – Java Controls Everywhere!
Java Controls are everywhere in BEA WebLogic Workshop 8.1! New Controls have been added for assets such as eMail, FTP, Tuxedo, Portals, Integration, and many more. Developers can drag-and-drop Java Controls from the Workshop palette into any Workshop project, from Web apps and Web services to Portal and Integration applications. The WebLogic Workshop 8.1 runtime framework will handle all details of connecting the Control using standard J2EE components, and the Control framework itself is part of JSR 181.
Create Custom Java Controls to Unlock Proprietary Systems or Package Best Practices
New, with Workshop 8.1, you can create custom Java Controls. Create custom Controls that make it incredibly easy for any IT developer and any IT project to unlock any proprietary systems. Create custom Java Controls that wrap up other controls and add business logic to create reusable, composite components that expose business operations or best practices. Create asynchronous, message-buffered Controls for robust, mission critical performance by simply setting a property.
http://www.bea.com/framework.jsp?CNT=java_controls.htm&FP=/content/products/weblogic/workshop/features/
mp817收录，使用标签：中间件，时间：2007-3-28 10:34:47 | 相关网摘，我也收藏
分层的重要性
此处要考虑的主要模式是 EJB 层中的分层。该模式移除了所公开的 Web 服务接口的复杂性。分层的 Web 服务驱动的 EJB 可以通过更简单的面向业务的接口进行设计，而不必将多个接口指向服务集合。从 J2EE 的角度而言，大多数设计人员针对此目的解决方案是使用 Floyd Marinescu 在《EJB Design Patterns:Advanced Patterns, Processes, and Idioms》(由 Wiley 出版社于 2002 年出版)一书中所介绍的 Facade(外观)模式—具体而言，就是创建一个用作外观的会话 EJB，并将组成服务的组件集(即其他 bean，其中的某些 bean 可能是会话 bean 和实体 bean)“包装”起来。这样，服务请求程序将与服务实现的细节分隔开，且会话 EJB 将启用一个“虚拟功能”provide_Service() 方法，该方法不包含业务逻辑并公开一个通用(抽象化)接口。该体系结构方法解除了服务请求程序与服务接口之间的耦合，从而实现了组件的重复使用。它还可以在不同版本的服务存在不同的业务要求时，帮助管理 Web 服务的复杂性。
遗憾地是，在实践中，“外观”模式通常未得到充分地应用，尤其是在以下两种常见的情况下。第一种情况是，用户创建了一个直接包装子系统组件的所有方法的外观，但未提供任何其他抽象。这样的方法是否提供了所需级别的松散耦合?实际上并未提供。松散耦合必须减低总体复杂性，而在这种情况下，复杂性并未降低而只是转移到其他对象。
第二种情况与第一种情况正好相反—开发人员走向了另一个极端，即将会话 bean 中的每个用例包装起来，并向每个 bean 公开一个 Web 服务 API。这样做也不会获得任何好处;其结果是生成了许多体现相似行为的会话 bean(例如，GetAccountBalance、UpdateAccountBalance、TransferFunds、 ListAllAccountBalances 等等)，并且在应用程序中，我们需要密切注意所操作的会话 bean。每个用例实现一个会话外观所需的管理投入令人生畏。此外，复杂性不但没有降低，反而进一步增大。
要实现一个有助于实现其他一些有利设计可能性的理想松耦合状态，必须进一步改进分层：将上述的服务外观层划分为若干层(即子层)，这些层按顺序进行排列，即层“n + 1”主要由层“n”的外观公开的服务组成(如图 4 所示)将外观嵌套(而非增加)可以对服务粒度进行管理—从粗粒度程度很高的服务到粗粒度程度中等的服务，再到细粒度服务。注意，粗粒度意味着更正式(通用)的接口;粗粒度服务接口提供了子系统(如订单管理、帐户管理、定价等)的抽象表示。此处的主要设计思想是采用一个足以满足需要的多个外观复合结构(其后隐藏了基础业务逻辑的所有细节)。只有该方法才能有效地帮助我们实现一个完全符合 SOA 的解决方案。
http://news.csdn.net/n/20070110/100509.html
mp817收录，使用标签：中间件，时间：2007-3-28 10:33:51 | 相关网摘，我也收藏
如果在开发环境中使用适当的工具(如 Oracle 应用服务器 和 Oracle JDeveloper)，则公开 EJB 的过程将非常简单。但情况并非绝对如此，而且实际的大型分布式应用程序需要模块化、可重用性、可扩展性、可移植性、版本控制、一致性以及可伸缩性的可持续特性。
有关如何利用标准 J2EE 组件(其中的模块功能面向业务服务上下文)以及 Web 服务中不断涌现的技术改进或增强软件开发过程以高效构建高质量的大型应用程序的信息很少。即使我们能够精确地标识“可以服务”的业务功能并拥有所有必要的应用程序和中间件工具，也无法回答下面这个问题：如何在分布式处理元素中安排应用程序功能或职责，以便在使用 Web 服务时最大限度地增强质量功能?
通常情况下，研究 Web 服务的组织利用其现有 Java 对象并直接使用 Web 接口公开它们。最终的结果是不符合 SOA 的要求，且此类实现可以使组织面临以下比较严重的问题：
低可重用性—为某个项目开发的服务不易于在其他项目中重用，这是因为它们的结构通常过分依赖于 Web 服务接口的实现。某个服务中的组件之间的依赖性降低了该服务在其他上下文中的可用性。
低可扩展性—当出现新功能需要时，很难扩展现有接口，或至少将更改或扩展孤立到一到两个组件。通常情况下必须设计新接口，尤其是当服务控制逻辑集中用于执行消息处理的代码中时。
低可伸缩性—很难存档高容量工作负载(例如，每秒钟 1,000 个以上的服务请求)。直接使用 Web 服务接口公开每个对象的细粒度解决方案无法通过经济有效的方式扩展到这样的级别。
要避免此类问题，组织需要部署正确的体系结构模式来帮助创建粗粒度、高度面向业务的 J2EE 组件。
http://news.csdn.net/n/20070110/100508.html
mp817收录，使用标签：中间件，时间：2007-3-28 10:32:54 | 相关网摘，我也收藏
设计模式对于面向服务的体系结构具有深远的影响(人们对此尚认识不足)，因此请明智地选择您的设计模式。
当机构使用 Web 服务技术构建、部署和组织业务服务时，显然必须进行仔细、全面设计 Java 2 平台企业版 (J2EE) 应用程序。在这方面，最有效的帮助是严格应用旨在实现面向服务的体系结构 (SOA) 的体系结构模式。当公开 Enterprise JavaBean (EJB) 时，此类模式尤其有用。
人们通常把模式仅仅看作是为特殊设计问题提供指导的参考工具;而事实上，应将模式看作是体系结构要求的组成部分。它们是影响业务服务(封装了业务规则验证、计算、数据访问以及其他驱动 J2EE 应用程序的核心功能的逻辑)组织决策的起点。除其他适用于 J2EE 的模式和思考方式以外，一些学术界人士、供应商和用户还从 SOA 的角度对著名的Design Patterns一书(由 Addison-Wesley 出版社于 1994 年出版，作者是 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides —— 通常称之为“四人帮”或“GoF”)中的许多模式进行了再计算和研究。
本文将从体系结构的角度介绍最重要的模式及其应用，假设您熟悉以下 Web 服务基础知识：简单对象访问协议 (SOAP)、HTTP、XML、J2EE、EJB、Java 消息服务 (JMS) 等。
走进 Web 服务世界
从 J2EE 的角度而言，Web 服务基本上是 J2EE 编程模型的扩展(参见图 1)，具体体现在：
Web 服务继承了符合 J2EE 的应用服务器的容器功能。
远程过程调用 (RPC) 样式的 Web 服务通过非会话状态 EJB 公开。
消息样式的 Web 服务通过 JMS(JMS 监听程序)和消息驱动的 bean 公开。
非会话状态 EJB 或 JMS 被定义为 Web 服务定义语言 (WSDL) 的应用程序入口点，并被部署为 Web 服务。
Web 服务客户机使用 WSDL 生成服务请求程序基于 SOAP 的代码。
http://news.csdn.net/n/20070110/100507.html
mp817收录，使用标签：SOA，时间：2007-3-28 9:44:47 | 相关网摘，我也收藏
IT企业继续从架构和标准层面上对SOA进行评估。但是，截止2006年年底，越来越多使用Java 和.NET技术平台的数据中心与SOA的有效应用产生冲突。从总体趋势上来讲， 这些情况在很长一段时间内依然会持续发生，应用软件服务器的使用从商业边沿转移到了中心地位，数据中心将之看作是他们运营的核心。
而许多这样的数据中心可能并不被认为是SOA, 他们比SOA有过之而无不及。它们是充分的分布并在功能性和复杂性都有成长潜力的应用软件， 而且正变成商业交易的重要组成部分， 在一些案例中也扮演着关键的角色。但是，也有一些技术人员争论到底他们是不是真正的SOA应用。从SOA初步目标来说，他们更快实现了整合，再利用和重新包装和重新定义商业系统目的的目标，而且从成本上来说也更为低廉。
通过与运营经理，应用软件研发人员，IT 执行主管探讨，预计在2007年，SOA内及其相关行业将出现如下趋势，并向您提供这样的一些建议：
1、应用大过技术
人们已经将SOA视为一项技术而非解决方案太久了。在2007年，其重点将径直向着应用的方向发展，具体来说，是向如何管理，监控和扩大已有的Java与.NET应用发展。直到前不久，关于SOA的讨论还着重于寻找服务，选择基础架构，管理开发，仅此而已。以Web服务为基础的应用软件方面的发展使得开发人员着重于一些技术以便得出商业解决方案，驱使数据中心寻找能帮助直接监控和管理已有成果的SOA应用。
假如你想要在SOA技术中找寻ROI(Return on Investment，投资回报)成分，那就请转移注意吧。将您的侧重点重新放在如何将现有的Web服务变得更有效率，在数据中心中更易管理上来。从这方面，SOA和Web服务已经证明了自己：以SOA为基础的解决方案正成长得更为有机，因为它们能完成工作。不管是否是由于端口、电子商务、应用软件整合项目或者商业情报的需求，Java 和以.NET为基础的实施方案已经在IT界发展出合理的甚至是成功的解决方案。
我们的建议是：在初始阶段，不要选择SOA管理工具包或者管理解决方案，为你的Portal，程序整合或者系统合并项目选择所需的技术。记住，这是应用。如果对程序引擎有具体的业务驱动要求，考虑使用ESB(Enterprise Service Bus, 企业服务总线).如果该项目是为端口，考虑使用具体的Portal技术。要持续关注该应用软件和并以其对商务程序的影响为基础测量结果。
2、装配而非购买
第二种趋势的核心是：越来越多的人意识到真正的价值在何处。这样的改变是由于该领域的中心从企业应用软件转向数据中心的核心复合软件。这种观点是由Oracle 和SAP加强并巩固的，他们都在为将其SOA产品Fusion 和 NetWeaver引入市场做努力。这种观点的核心在于装配应用软件包的客制化部分、遗留系统、复合软件的客制化逻辑，而非应用软件包本身。
http://news.csdn.net/n/20070327/102347.html
mp817收录，使用标签：业务平台，时间：2007-3-22 16:18:49 | 相关网摘，我也收藏
当Bull和JBoss被宣告形成世界范围技术和商业合作关系，以此加快SOA企业中间件的部署和开发时，Marc Fleury，Red Hat旗下子公司JBoss的副总裁和总经理，说：“我们欢迎Bull加入到JBoss的阵营中，期待能从Bull吸取中大量的成果，特别是安全领域和 BPM（业务流程管理）方面”。
Fleury接着说：“我们计划开展协作工作，通过灵活的，标准型的，开源的SOA平台，来重点挖掘Red Hat的用户价值，我们相信开源的SOA平台能够给用户带来更多的技术选择空间。作为合作伙伴，Bull扩展我们的系统，提高了强大的综合性能，支持企业级的JEMS——基于全球市场的解决方案。”
遵照协议，Red Hat将要加强它对ObjectWeb的影响力，包括和Bull紧密合作开发和扩充ObjectWeb，开发推广ObjectWeb v2版本。同时，Bull承诺做JBoss和ObjectWeb之间兼容协同方面的工作。
JP Barbéris，Bull服务解决方案总经理，说：“多年来，Bull一直充当的是一个主要的开源综合软件的角色和为众多开发团体服务的角色，为了增加我们在ObjectWeb上长期的努力，我们和JBoss达成战略合作关系，以此，我们想推动开源中间件的互用性。作为开源世界的架构师，我们给企业提供一个唯一的性能指标，让他们在市场上发布，支持那些灵活的、兼容性强的、基于SOA的商业应用软件，这些商业软件无疑会领跑下一代的软件开发”。
这次合作，造就了Bull和Red Hat的联盟，同时也是JBoss第一次在欧洲开源产品的研发战略性合作伙伴关系。多面协议增加开源创新性，协作性，整合性，共享性，兼容性。
Bull 和JBoss的合作将在以下三个方面展开：
研发合作：Bull成为JBoss的贡献者，遵循在Apache、Eclipse、ObjectWeb上采取的合作策略。JBoss项目将从Bull的专门技术中受益，特别是在安全和业务流程管理方面。
系统集成: Bull成为一个战略性的系统集成伙伴，将增加JBoss关于开源解决方案的企业中间件，人们称作“Open Energy”。 Bull的400个以上的开源软件服务和专门的中间件将会极大扩展系统集成服务的范围，包括咨询，应用软件架构设计，校正。Bull将会发表基于JEMS 的解决方案，这个解决方案运行在自己的大型服务器NovaScale 和Escala上。
Subscriptions: Bull将会转售JBoss的一些功能，包括卖给它自己用户的支持和授权JBoss Operations Network（JBoss业务网）。在协议的约束下，Bull将向Red Hat提第一级和第二级的支持，提供第三级的技术支持。
Bull在公共事业，医疗卫生，金融，通信，制造业和国防方面都有重要的一席之地。它的配电网和商业合作伙伴遍布世界60个国家。
http://news.csdn.net/n/20070322/102226.html
mp817收录，使用标签：SOA，时间：2007-3-20 10:50:01 | 相关网摘，我也收藏
在科技日新月异的大潮下，“传统”的企业服务总线(ESB)正经历着保持与面向服务架构需求同步的改革，从原来的综合/信息工具转化成为具备商业流程管理(BPM)工具，管理和分析功能的基础架构。
在近期webMethods Fabric 7.0介绍展现了ESB在其原有的综合支柱角色基础上成长：
AMR Research副主席Bill Swanton先生说，我们看到webMethods Fabric 7.0是以SOA方式建立综合应用软件的一个很直接的发展环境。新的产品将所有历史上与集成有关联的工具加以整合，其中包括原有企业应用系统集成EAI技术和ESB，将BPM和商业活动监控(BAM)囊括进来，并增加了注册，储存和管理的性能。
阿伯丁集团企业整合副主席Peter S. Kastner指出：像EAI一样过时的软件也可能出现在SOA世界中，对于支持遗留技术它还是很重要的， 因为这些遗留技术还存在于许多企业当中。
他还说：“我们发现几乎没有人愿意舍弃他们在EAI上的投资只为了购买ESB然后宣称他们是唯一一个使用ESB的人。”他引用了 webMethods为例，webMethods是原EAI公司，现在已经成功转型进入SOA行业，同时提供与旧的整合技术相连的桥梁。今年他对于IT部门的研究推翻了他自己的观点，旧整合技术供应商并非注定失败。
Kastner还说“今年我的假设是：EAI公司将会受到重创。但事实上，他们绝大多数的客户很容易的将自己的EAI架构通过适配器与SOA连接。”
Kastner 和 Swanton都赞同这一点：对于webMethods 正在包装的旗下品牌ESB技术发展来说，引入更新的技术，特别是BPM是很重要的。
Swanton说：许多ESB供应商都还在尝试仍在整理支持商业分析和软件开发者的综合工具包。整个ESB技术会将BPM纳入其中以便使软件开发者能与商业分析师在商业程序软件上进行合作。
Kastner说， BPM之所以重要， 是因为在其研究的基础上，大综商业交易在很大程度上包含BPM.我们看到大概有50%全球5000强积极投入BPM发展上。他还指出webMethods并不是唯一一个将BPM融入ESB技术的厂商。
他说：我们应该注意到Tibco在过去的几年中已经对BPM进行了大量投资，Fiorano也在近半年中对其ESB产品在BPM领域进行了加强。
webMethods 技术总监Marc Breissinger 说，ESB的发展需要一个新的定义，甚至是对它进行重新命名。他还指出这个产业已经引入了“Fabric”这个术语，这在他的公司和其他公司的产品品牌上可以看到。
http://news.csdn.net/n/20070320/102134.html
mp817收录，使用标签：SOA，时间：2007-3-19 9:27:17 | 相关网摘，我也收藏
之前，在SOA讨论中，反反复复的在说“服务”，多数是从厂商的出发点来说。其实呢，“服务”的另一面就是“消费”，而消费者的观点和态度更是最终决定 SOA命运的关键。所以，这次就想尝试从消费的角度来考量。
所谓消费者是上帝，而上帝的待遇来自于充分的市场竞争；在任何垄断或者寡头垄断的状态下，只有傲慢的厂商。所以，从消费者的观点来看，要有足够多的服务供应商参与竞争，才能建立一个消费者的天下的买方市场。作为SOA中的“服务”，培育众多供应商的环境就是一个共同创新的生态圈。在共同创新的生态圈中，众多厂商百家争鸣，为消费者创造琳琅满目的服务产品。可以选择的东西多了，消费者当然就有空间可以挑三拣四，各取所需。
但是众多的可选厂商，同样会给消费者带来困扰。譬如说，如果为了买一双满意的鞋子，没人会想要到每个厂商那里去看样，也每人做得到，仅仅是了解所有能提供你想要鞋子的厂商名字，这个无形的消费成本也不是普通消费者愿意承担的。那你买鞋会去那里？当然是百货公司或者大超市。同样情况，也需要集中贩卖“服务”的市场(Market Place)的存在。这个市场的功能就是最小化“服务”产品和消费需求配对过程的成本。提供UDDI服务的网站，可以说是这种市场的雏形。
同样用消费者的眼光看众多的服务产品，在万千产品中，为什么偏偏选中你？在生活中，促使消费者做出购买选择主要是品牌和产品的性价比，在选择服务产品时候也不外如此。如果相似的产品，大品牌往往让人感到更加可以信赖而获得青睐；或者因为对服务有特殊性能的要求，例如：特殊的加密安全，不得不选择特定的服务；再有就是最原始的竞争因素——价格了。
虽然类比消费者对普通商品和对“服务”软件产品的要求能够发现许多共同之处，但是“服务”也有它的特殊性。不同于普通商品，对消费者而言，无论你身在那里，互联联网让你能无差别的享受全球服务供应厂商相同的服务。很快提供相同服务的厂商只会剩下最有竞争优势的一家或少数几家品牌，就象提到网络搜索就会直奔Google的网站，想到买书就会顺手输入Amazon的地址。这不是又回到垄断状态了吗？确实在通用服务供应市场，不可避免有垄断的产生，但是服务的供求也许不会是80/20法则，80%的服务由20%的厂商提供；更可能体现是“长尾”理论，有足够多的消费者组成的具有个性化要求的服务“长尾”市场，为足够多数量的“服务”供应商提供纵向市场(Vertical Market)生存空间。而“服务”供应厂商的充分竞争也是基于产品差异化的竞争，而不是简单的价格战。
对“服务”的消费者观点还有许多值得探讨的地方，以上的一些想法，权当作抛砖引玉。
http://blog.csdn.net/juishl/archive/2007/03/17/1532201.aspx
mp817收录，使用标签：SOA，时间：2007-3-14 13:49:43 | 相关网摘，我也收藏
当国内的企业用户对服务导向架构（Service Oriented Architecture，SOA）还懵懵懂懂的时候，国外的SOA鼓吹者已经开始制造SOA 2.0的概念了。
最近，甲骨文公司（Oracle）和顾能公司（Gartner）均提出，客户机/服务器时代的SOA概念属于SOA 1.0，未来的SOA 2.0应该建立在事件导向架构的基础上。当然，甲骨文公司没有忘记交待一下，自己的“融合”（Fusion）计划就包含了SOA 2.0的内容。
不过，就像现在火热的Web 2.0一样，SOA 2.0的概念也引起了极大的争论。国际商业机器公司（IBM）全球SOA销售副总裁庞睿达（Dan Power）前不久接受《信息周刊》专访时就表示，现在并没有给SOA划分版本的必要，在他看来，SOA 2.0只是竞争对手的市场手段而已。
SOA 2.0确实已经成为市场上最新的宣传手段之一。有些宣传片面地把SOA与网络服务（Web Service）划上等号，还有些则把SOA吹嘘成解决一切商业问题的灵丹妙药。庞睿达指出，网络服务只是提供了SOA产品的一种技术可能，但并不是所有的SOA都要基于网络服务。同样，很多企业用户期待SOA帮助企业进行商业流程优化或转型，但实际上SOA只是帮助企业实现这一目的的手段之一。
假如不指出其中的关键点，企业用户很有可能被类似的概念搞糊涂，尤其是在中国。“中国企业必须对SOA有更清醒的认识。”日前，国际数据公司（IDC）中国区副总经理万宁在一次SOA论坛上提醒道。
SOA的前景确实诱人，但发展的道路未必平坦。起码到目前为止，SOA距离完全可部署还有相当差距。
阿伯丁集团（Aberdeen Group）的一项调查数据显示，只有16%的公司拥有超过24个月的SOA技术经验。而且，大多数部署SOA成功的企业，都需要有非常丰富的IT经验，拥有庞大的IT预算，或者本身业务就是依赖IT类型的，譬如通信和金融服务。同时，这些企业也拥有优秀商业科技领袖的指引。一句话，不具备这些条件的企业，想要部署SOA，恐怕还需要耐心等待。
另外，并不是所有的企业都适合部署SOA。沪士电子（昆山）有限公司IT经理王翔认为，如果公司规模较小、产品单一，IT部门只是作为附属、支持性部门，一套企业资源计划（ERP）系统就足够了。规模较大、IT部门相对独立的企业，实施SOA会更为容易一些。“IT部门以前偏重于支持，但SOA要求IT部门提供服务。因此，与业务部门并行、相对独立的IT部门更容易部署SOA。”
http://www.informationweek.com.cn/iarticle/18491.html
mp817收录，使用标签：数据库，时间：2007-3-6 15:31:53 | 相关网摘，我也收藏
依照SQL Server Manageability Team称近日发现在SQL Server 2005 SP 2 的升级维护中会出现致命的bug。
SQL Server 2005 SP 2 中包含一个批量清理数据的功能，而近日发现这个功能却是引发这个致命bug的根源所在。
它将会引发删除之前所有时期的数据信息，更为严重的是它还有可能会造成在数据处理过程中用混乱的顺序来处理数据。
现在为止仍没有确切的方案能解决这一问题，所以类似的操作要谨慎进行，在数据处理时手动的设置处理顺序以及时间间隔。
http://news.csdn.net/n/20070306/101757.html
mp817收录，使用标签：SOA，时间：2007-3-6 10:07:07 | 相关网摘，我也收藏
据Linthicum 集团总裁David S. Linthicum称，高达60%-70%的web服务可以被分类为数据服务。
当这些数据服务变的更加普遍的时候，整个行业将会对SOA数据服务层有一个新的认识，他说。
大部分数据不能够通过SOA进行扩展和再生。数据必须符合服务商提出的任何要求。通过矫正服务的数据窗体，使数据分散化。SOA数据服务层是一个故意被打乱的数据层。
Composite 软件的CTO David Besemer说，
SOA必须具备以下四个组成部分：注册，交易，管理，数据存取。Besemer还表示，数据操纵逻辑不应该归纳到业务逻辑中。
模块化设计的概念大家是熟悉的，但是对于很多开发者来说，如果对分配的任务他们的SOA设计技巧欠缺的话，面对如何清理混乱的局面将会是一个很头疼的问题。
“在今天，大多数的人都对SOAP, XSD, WSDLs XQuery 和XSLT不够了解，所以他们可能需要面对一次很艰难的过渡，” Yankee集团分析师Laura Didio说。
即使在最尖端企业，技术性的差异仍然会阻碍和拖延部署边缘的商业优势。Didio表示，如果有需要的话，公司会考虑使用服务外包和系统集成商。
SOA的平缓过渡是综合软件的主要特点. 综合软件可以识别对数据服务平台的需求，并可以使用它来区分其产品。它的综合软件工具集合被放置在SQL范例的图解环境中。
所有被暴露的数据，包括数据、索引和数据文件，是作为一个综合层。
“最好是能够通过某种方式让人们来了解他们的框架结构，”Composite的Besemer说。
Didio说，那将需要时间，资源和支持，来初步解决技能差距造成的困境。
在选择SOA数据服务供应商的时候，我们建议选择那些可以帮助他们设计和开发，并能够提供优良的市场售后服务和技术支持的供应商。
她接着说，早期的SOA 数据服务接收者也应该投入必要的时间和经费进行内部培训。
Didio在预测SOA技术差距造成的影响的同时，就像她说的一样，其他的处于“热门”的技术领域，也将会在主流中逐渐的被减弱。
http://news.csdn.net/n/20070306/101756.html
mp817收录，使用标签：SOA，时间：2007-3-6 9:58:04 | 相关网摘，我也收藏
一、明确的边界
通过跨越定义明确的边界进行显式消息传递，服务得以彼此交互。有时候，跨越服务边界可能要耗费很大的成本，这要视地理、信任或执行因素而定。边界是指服务的公共接口与其内部专用实现之间的界线。服务的边界通过 WSDL 发布，可能包括说明特定服务之期望的声明。
二、服务共享和约和架构，不是类
服务交互应当只以服务的策略、架构和基于合约的行为为基础。服务的合约通常使用 WSDL 定义，而服务聚合的合约则可以使用 BPEL 定义（进而，对聚合的每个服务使用 WSDL）。服务使用者将依靠服务的合约来调用服务及与服务交互。鉴于这种依赖性，服务合约必须长期保持稳定。在利用 XML 架构 (xsd:any) 和 SOAP 处理模型（可选标头）的可扩展性的同时，合约的设计应尽可能明确。
三、策略驱动
尽管它往往被认为是最不为人所了解的原则，但对于实现灵活的 Web 服务，它或许是最有力的。单纯依靠 WSDL 无法交流某些业务交互要求。可以使用策略表达式将结构兼容性（交流的内容）与语义兼容性（如何交流消息或者将消息交流给谁）分隔开来。
四、自治
服务是独立进行部署、版本控制和管理的实体。开发人员应避免对服务边界之间的空间进行假设，因为此空间比边界本身更容易改变。
五、采用可传输的协议格式，而不是API
通常,服务提供商基于某种传输协议(例如HTTP)提供服务,而服务消费者只能通过另一种不同的协议(比如MQ)通信。因此，也许需要在服务提供商与消费者之间建立一座异步起动同步运行的连接桥梁,超越HTTP和Java Messaging Service消息服务(JMS)等协议.从技术角度讲，Java Messaging Service消息服务(JMS)并不是一种传输协议,而是一组供应商中立(vendor-neutral)的通信APIs。
六、面向文档
消息被构造为“纯文本的”XML文档（换句话说，数据的格式只对XML有意义）。 消息通常用于传输业务文档，比如购买订单、发票和提单。这种交互类型与同步消息排队系统的兼容性很好，比如MQ Series、MSMQ、JMS、TIBCO、IMS等等。
七、松偶合
服务之间要求最小的依赖性，只要求它们之间能够相互知晓。
八、符合标准
当通过Web的服务实现时，最原始的(基本的)面向服务的架构(SOA)的模型仅仅提供了很低程度上的关于可靠性、安全性以及事务管理的标准化机制。第二代的技术条件和框架，如WS-ReliableMessaging规范、 WS-Security规范和WS-Coordination规范 (与WS-AtomicTransaction规范和WS-BusinessActivity规范相联系)，它们试图以工业标准的方式定位存在的缺陷。
九、独立软件供应商
向SOA的转变正在深刻改变了经济现实。客户们会期待更合理的费用以及不必重新进行投资就能改进业务的能力。因此，独立软件供应商没有选择，只能使自己的业务更加灵活，以期让自己的客户也变得同样灵活。于是，面向服务不仅是简单的在现有的、紧耦合的、复杂的、不灵活的以及非组件化的业务功能上添加基于标准的接口。更重要的是，为了兑现SOA的承诺，独立软件供应商必须改变他们构建、打包、销售、交付、管理和支持自身产品的方式。
十、元数据驱动
开发元数据本身并不是元数据驱动应用程序的本意。使用元数据来驱动服务在系统边界的传播是一个更为正确的方法。
http://news.csdn.net/n/20070305/101740.html
mp817收录，使用标签：SOA，时间：2007-3-6 9:57:11 | 相关网摘，我也收藏
从企业服务总线(Enterprise Service Bus，ESB)在2002年被正式提出以来，我们看到ESB不管是在实现方式还是部署方式上都有了不小的变化。在过去的四年多的时间里，ESB作为软件领域里的一个独立产品也被越来越多的人所接受，众多的ESB供应商正在架构、连接性、易用性以及服务质量的保证(如持续可用)等方面进行竞争......
很多综合服务供应商(如IBM、BEA)、企业应用集成商(如Tibco、webMethod)以及Web服务工具供应商都纷纷给自己的产品冠以ESB的名号，英国电信甚至把ESB做进了它们的一个硬件产品中。
很明显，作为SOA(Service-Oriented Architecture)的核心和基础架构，ESB已经成为准备踏上和已经踏上SOA之旅的CIO们必须认真考虑和仔细研究的一个产品。因为作为一种中间件，ESB通过与它连接的各种应用的服务级接口实现各种应用之间的连接，控制它们之间的通信，这一功能正在越来越多的生产系统中发挥着作用。更为重要的是，几年来很多企业和机构已经在生产中部署了ESB，ESB的效果得到了一定程度的校验，同时人们对如何充分发挥ESB的作用以及建立SOA的环境，为此需要建设、部署管理哪些基础设施有了越来越清晰的认识。这些基础设施包括：
面向流程、事件驱动的架构(Event-Driven Architecture，EDA);
Web服务的治理;
高级Web服务规范(WS-*);
复杂事件处理(Complex Event Processing，CEP);
语义数据集成。
事件驱动的架构
谈到ESB就不得不谈到面向流程、事件驱动的架构，因为ESB与这种架构配合起来可谓相得益彰。
通常，点对点的集成是通过简单的请求/响应这种同步的方式来完成交互的。在这种环境中，ESB作为数据传输和转换的中介可以很好地完成这一任务，但是，ESB最能发挥作用、也最能体现其带来的灵活性的地方还是在面向流程、事件驱动的架构中。
在进行跨多个应用、大范围的集成时，成功的关键是有一个灵活的架构，面向流程、事件驱动的架构就是这样的架构。通过使用ESB，事件驱动的架构中的每个应用与其他应用之间处于一种松耦合状态。在这种架构中，每个应用独立于其他应用运行完成一项任务，或者异步地完成一组任务中的一个。
即使在一个应用发出了一个请求，然后等待响应以完成接下来的流程时也是这样。这个请求被发到总线上，按照预先定义的流程，这个请求可能会经过很多应用、数据源、路由器和转换器。上述一系列的行为都是独立完成的，最后的响应也是作为一个独立的事件到达最初的这个应用。
事件驱动的交互模式一个主要优点就是保证应用之间的松耦合。只要接入ESB中，每个应用都不用了解如何与其他的应用进行交互这些细节，ESB负责处理所有的协议、数据格式和不同的交互模式。
http://news.csdn.net/n/20070305/101741.html
共76个网摘 [
1 2 3 ]
下一页