精华内容
下载资源
问答
  • CORBA——公共对象请求代理体系结构

    千次阅读 2016-11-28 15:30:07
    公用对象请求代理(调度)程序体系结构(Common Object Request Broker Architecture),缩写为 CORBA,是对象管理组织(Object Management Group)对应当今快速增长的软硬件的协同工作能力的要求而提出的方案。...
    •       公用对象请求代理(调度)程序体系结构(Common Object Request Broker Architecture),缩写为 CORBA,是对象管理组织(Object Management Group)对应当今快速增长的软硬件的协同工作能力的要求而提出的方案。简而言之,CORBA 允许应用程序和其他的应用程序通讯,而不论他们在什么地方或者由谁来设计。CORBA 1.1 由对象管理组织在 1991 年发布。他定义了接口定义语言(IDL)和应用编程接口(API),从而通过实现对象请求代理(ORB)来激活客户/服务器的交互。CORBA 2.0 于 1994 年的 12 月发布。他定义了如何跨越不同的 ORB 提供者而进行通讯。

             ORB 是一个中间件,他在对象间建立客户-服务器的关系。通过 ORB,一个客户可以很简单地使用服务器对象的方法而不论服务器是在同一机器上还是通过一个网络访问。ORB 截获调用然后负责找到一个对象实现这个请求,传递参数和方法,最后返回结果。客户不用知道对象在哪里,是什么语言实现的,他的操作系统以及其他和对象接口无关的东西。

             在传统的客户/服务器程序中,开发者使用他们自己设计的或者公认的标准定义设备之间的协议。协议的定义依赖于实现的语言,网络的传输和其他许许多多因素。ORB 将这个过程简单化。使用 ORB,协议定义是通过应用接口,而该接口是接口定义语言(IDL)的一个实现,他和使用的编程语言无关的。并且 ORB 提供了很大的灵活性。他让程序员选择最适当的操作系统,运行环境和设计语言来建设系统中每个组件。更重要的是,他允许集成已经存在的组件。

              CORBA 是在面向对象标准化和互操作性道路上的一个信号。通过 CORBA,用户不必要知道软硬件的平台和他们处在企业网的什么地方就可以操作。

           ORB 结构

    •        下面我来用些图形说明一下:

      通过 ORB 发送请求

             上面的图形说明的是客户端发送一个请求到对象的实现。客户端是希望对某对象执行操作的实体。对象的实现是一片代码和数据来实际实现对象。ORB 负责下面的必要的机制:对该请求找到对象的实现,让对象的实现准备好接受请求,和请求交换数据。客户端的接口完全独立于对象的位置,其实现的语言和其他不影响对象接口的东西。

      ORB 接口的结构

             上面的图形显示的是一个独立的对象请求代理(ORB)的结构。ORB 的接口是灰色的矩形。箭头说明 ORB 的调用关系。

             为了提出一个请求,客户端可以使用动态调用接口(Dynamic Invocation Interface)(和目标对象的接口独立)或者一个 OMG 的 IDL 占位程序(具体的占位程序依赖于目标对象的接口)。客户端也可以直接和 ORB 在某些地方交互。

             对象的实现通过 OMG 的 IDL 产生的骨架或者是一个动态骨架的调用来接受请求。对象的实现可能在处理请求或其他的时候调用 ORB。

             对象接口定义的定义可以有下面两种方式。接口可以通过接口定义语言静态的定义,这叫做 OMG 的 IDL。该语言按照可以进行的操作和该操作的参数定义对象类型。或者(也可以作为补充),接口可以加入到 Interface Repository service。该服务描述了该接口作为一个对象的组件,并允许运行时访问这些组件。在任何 ORB 实现中,IDL 和 Interface Repository 有相同的表达能力。

      客户端使用占位程序或者动态调用接口

              客户端通过访问对象的对象引用和了解对象的类型及要求执行的操作来发布一个请求。客户调用占位程序例程来请求或者动态构造请求。

             无论动态还是占位程序的接口都可以相同实现。接收方不可能知道请求是如何发布的。

      对象的实现接受请求

                ORB 向对象实现定位适当的代码,传递参数,传输控制。这一切都通过 IDL 骨架或者动态骨架。骨架对于不同的接口和对象适配器是不同的。在执行该请求的时候,对象的实现可能由 ORB 通过对象适配器来获得一定的服务。当请求完成,控制和输出值返回给客户。

              对象的实现可能会选择使用的对象适配器。该决定基于对象的实现要求的服务。

      接口和 Implementation Repositories

              上图说明的是接口和实现信息如何让客户和对象实现访问的。接口用 OMG 的 IDL 和/或 Interface Repository 定义。该定义用于产生客户占位程序和对象的实现的骨架。

             对象的实现的信息在安装时就提供好了,储存在 Implementation Repository 中以便请求发布的时候使用。

      2009-09-07                   

      注:源自原百度博客“至美心”

    展开全文
  • 对象关系映射ORM?

    千次阅读 2015-11-15 17:23:12
    对象关系映射(Object Relational Mapping,简称ORM)是一种为了解决面向对象关系数据库存在的互不匹配的现象的技术。 简单的说,ORM是通过使用描述对象和数据库之间映射的元数据,将java程序中的对象自动持久...

       对象关系映射Object Relational Mapping,简称ORM)是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说,ORM是通过使用描述对象和数据库之间映射的元数据,将java程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 这也同时暗示者额外的执行开销;然而,如果ORM作为一种中间件实现,则会有很多机会做优化,而这些在手写的持久层并不存在。 更重要的是用于控制转换的元数据需要提供和管理;但是同样,这些花费要比维护手写的方案要少;而且就算是遵守ODMG规范的对象数据库依然需要级别的元数据。

          对象-关系映射Object/Relation Mapping,简称ORM),是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法,关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式,业务实体在内存中表现为对象,在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系,而在数据库中,关系数据无法直接表达多对多关联和继承关系。因此,对象-关系映射(ORM)系统一般以中间件的形式存在,主要实现程序对象到关系数据库数据的映射。

          面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的,而关系数据库则是从数学理论发展而来的,两套理论存在显著的区别。为了解决这个不匹配的现象,对象关系映射技术应运而生。

          让我们从O/R开始。字母O起源于"对象"(Object),而R则来自于"关系"(Relational)。几乎所有的程序里面,都存在对象和关系数据库。在业务逻辑层和用户界面层中,我们是面向对象的。当对象信息发生变化的时候,我们需要把对象的信息保存在关系数据库中。

          当你开发一个应用程序的时候(不使用O/R Mapping),你可能会写不少数据访问层的代码,用来从数据库保存,删除,读取对象信息,等等。你在DAL中写了很多的方法来读取对象数据,改变状态对象等等任务。而这些代码写起来总是重复的。
     
      如果打开你最近的程序,看看DAL代码,你肯定会看到很多近似的通用的模式。我们以保存对象的方法为例,你传入一个对象,为SqlCommand对象添加SqlParameter,把所有属性和对象对应,设置SqlCommand的CommandText属性为存储过程,然后运行SqlCommand。对于每个对象都要重复的写这些代码。

      除此之外,还有更好的办法吗?有,引入一个O/R Mapping。实质上,一个O/R Mapping会为你生成DAL。与其自己写DAL代码,不如用O/R Mapping。你用O/R Mapping保存,删除,读取对象,O/R Mapping负责生成SQL,你只需要关心对象就好。

          对象关系映射成功运用在不同的面向对象持久层产品中,如:Torque,OJB,Hibernate,TopLink,Castor JDO, TJDO 等。

          一般的ORM包括以下四部分: 
          一个对持久类对象进行CRUD操作的API; 
          一个语言或API用来规定与类和类属性相关的查询; 
          一个规定mapping metadata的工具; 
          一种技术可以让ORM的实现同事务对象一起进行dirty checking, lazy association fetching以及其他的优化操作。

    一、目前流行的 ORM 产品

          目前众多厂商和开源社区都提供了持久层框架的实现,常见的有:

          Apache OJB (http://db.apache.org/ojb/) 
          Cayenne (http://objectstyle.org/cayenne/) 
          Jaxor (http://jaxor.sourceforge.net) 
          Hibernate (http://www.hibernate.org) 
          iBatis (http://www.ibatis.com) 
          jRelationalFramework (http://ijf.sourceforge.net) 
          mirage (http://itor.cq2.org/en/oss/mirage/toon) 
          SMYLE (http://www.drjava.de/smyle) 
          TopLink (http://otn.oracle.com/products/ias/toplink/index.html)

          其中 TopLink 是 Oracle 的商业产品,其他均为开源项目。

          其中 Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位,甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准,这也是开源项目影响工业领域标准的有力见证。

    二、对象-关系映射模式

          从《公共仓库元模型:开发指南》一书第8章CWM元仓库中摘录出来的内容,实现了公共仓库元模型(CWM)的UML图到Microsoft SQL Server数据库的映射,是一种将对象层次结构映射成关系型结构的方法。个人认为可以作为将本体(Ontology)文件存储到关系型数据库中的一种可借鉴方法。

          基本情况:公共仓库元模型(CWM)是对象管理组织(OMG)的一种和数据仓库相关的元模型标准,采用UML表示的对象层次结构,在保存到数据库中时由于面向对象的数据库技术的不完善(理论研究和商业应用都不是主流),所以该书的作者倾向于使用成熟的关系型数据库来保存-这也是存储本体时所遇到的问题。

          采用方法:将UML模型中的各种元素通过转换,保存为数据库模式。由于CWM是一种元模型,因此模型的实例也是一种模型,将这种实例以数据库数据的形式保存。使用数据库中比较成熟的存储过程技术提高开发和执行效率。

          1、数据类型映射模式

          1.1简单数据类型模式:建立UML和关系型数据库中简单数据类型的映射表以指导映射。
          1.2枚举数据类型模式:每种枚举类型对应一个表,只有一个列(_EnumLiteral)表示枚举值。
          1.3基于类的数据类型模式:使用外键约束,将基础列与基于类的类型实例相关联。

          2、类映射模型

          每个类对应一个表。单值属性、多值属性、继承关系可以用下述方法映射,而引用属性将在关联映射模式中提到。

          2.1单值属性模式:是cardinality的上界为1的属性,映射到类所对应的表的列上。若其下界也为1(必须有的属性),列属性为NOT NULL。
          2.2多值属性模式:每个多值属性映射成一个独立的表,使用外键连接到类所对应的表上。
          2.3继承模式:每加入一个类的实例时,根据其继承关系自顶向下生成每个类的对象,这些对象具有相同的ID(根对象对应记录的主键)。删除对象实例时,自底向上删除数据。遇到从中间删的情况怎么办?多重继承怎么处理?(金龙飞)

          3、关联映射模式

          3.1一对一关联模式:在关联两端各加一列。
          3.2一对多关联模式:和3.1一样。如果多这端是有序的,还需加入一列表示序号。
          3.3多对多关联模式:将关联单独作一个表。
          3.4组合关联模式:注意级联式删除。
          3.5反演关联模式:关联两端指向相关的类型,和普通关联一样。
          3.6成对关联模式:关联记录两个类间的关系,用交集类表示关联,表示成一个单独的表,每个关联对应一个表,用外键表示它们间的关系。
          3.7关联上的OCL需要分析成对应的存储过程代码。
          3.8保证关联的cardinality也需要分析成对应的存储过程代码。

          4、引用映射模式


          在UML中不存在的MOF特征,指属性是声明为引用类型的实例。用存储过程实现。

    展开全文
  • 公共关系学》课程内容介绍

    万次阅读 2007-01-01 22:25:00
    公共关系学》课程内容介绍 主讲:谭昆智中山大学 政治与公共事务管理学院 公共传播学系 副教授,公共关系学专业硕士研究生导师。主要从事公共关系学、市场营销学、组织文化和组织行为学等方面的教学、研究与开发...

    《公共关系学》课程内容介绍

     

    主讲:谭昆智

    中山大学 政治与公共事务管理学院  公共传播学系 副教授,

    公共关系学专业硕士研究生导师。

    主要从事公共关系学、市场营销学、组织文化和组织行为学等方面的教学、研究与开发工作。

    发表论文20余篇,参加编写出版的著作和教材有《营销管理》、《营销城市》、《公共关系学纲论》、《公共关系学》、《公共关系学教程》、《管理心理学》、《演讲与口才》等。20065月,荣获由中国公共关系协会学术委员会颁发的“中国公关教育20年突出贡献奖”。

    当前主持科研项目:

    1基于网络资源的《组织文化》课程教改试验,中山大学教育技术博学工程项目,20042006

    2传媒对公共情绪的宣导抚慰功能研究,国家社科基金,2005 -2007

    兼任广东省公共关系协会副秘书长、广州市海珠区公共关系协会副会长、广东社会学学会潜能开发研究专业委员会秘书长、南方发展研究院健康研究所副所长、广东纵横四海广告文化传播有限公司策划总监。

    3.混合教学模式行为研究,中山大学校级教学改革研究课题项目,2006 -2007

    Tel :(020)84038220  手机:13533066002    E-mail: lpstkz@mail.sysu.edu.cn

     

    第一讲 公共关系与团队建设

    [关键词]:意识、组织、功能、素质

    一、公共关系的本质属性

    (一)公共关系本质的确定依据和方法

    公共关系活动过程的三个基本要素是组织传播公众。任何公共关系活动都是由这三个要素构成的。

    在公共关系的这三个要素中,组织公众分别是公共关系的主体客体。这二者之间的相互作用方式是传播(Communication,也译作沟通);而现代公共关系传播的本质即组织与公众之间信息的双向交流;组织与公众沟通交流的双向性是现代公关传播的本质特征。

    三个要素之间的联系就是组织与公众之间通过传播沟通活动所形成的信息的双向交流。据此可以给公共关系下一个简单的定义:公共关系本质上是组织机构与相关公众之间的双向传播与沟通。而现代公共关系是组织的一种管理职能,这种管理职能的本质属性就是组织与公众之间的传播管理。

    公共关系也可以这样定义:“运用现代信息传播沟通手段,建立完善组织与公众之间的  双向交流,促进相互了解、理解、信任与和谐,为组织优化社会环境,树立良好形象”。

    双向传播与沟通是贯串整个公共关系的一条基线,是现代公共关系理论的精髓,是公共关系的本质属性。它渗透到公共关系原理和实务的各个方面,是准确理解公共关系的关键。

    (二)公共关系状态、公共关系活动、公共关系观念

    在使用公共关系这一概念的时候,往往可以表示一些不同层次的涵义:

    1.公共关系状态--表示客观存在的关系状况和舆论状况。

        2.公共关系活动--表示实际的操作实务。

        3.公共关系观念--表示引导、规范组织行为的一种价值观念和行为准则。

    (三)公共关系的职责

    1.收集信息;2.辅助决策;3.传播推广;4.协调沟通;5.提供服务。

    (四)公共关系的功能

    1公共关系对组织的直接功能

    (1)树立组织形象。(2)协调好关系网络

    2公共关系对于个人和社会的间接功能

    (1)提高个人素质。(2)优化社会环境

    二、

    运用现代信息传播沟通手段,建立完善组织与公众之间的双向交流,促进相互了解、理解、信任与和谐,为组织优化社会环境,树立良好形象。

    (一)公关意识的主要内容

    1.尊重公众、为公众服务与公众合作。

    2.注重自身形象,真实、真诚、公道、讲信誉。

    3.注重沟通,实行公开化。

    4.讲求平等和利益上的互惠。

    5.谋求整体协调。

    6.寻求长期和谐发展。

    (二)应变能力

    学会背后鞠躬

    友谊的前提是相互尊重

    学会反常规思维

    (三)公关礼仪

    社交礼仪定义

    礼仪是美德的一种外在表现形式, 这种美德的核心是尊重别人。现代社会要求人们的性格更加开放, 具有更强的交往能力。 因此,要更加处理好人际关系,造成一种相容的心理气氛,才于事业有益。所以,要重视礼仪的良性效应。

    1.社交礼仪的主要内容

    2.学会聆听—从同情心到同理心

    3.IQEQWQ

    、团队建设的内容

    1.团队的种类

    2.团队成员的不同风格

    3.团队是一种有效的组织

    4.有效团队的特征

    5.团队意识的内容

    四、上下级之间的相处艺术

    1.下级尊重上级

    2.上级尊重下级

    思考题:你认为公共关系的终极价值是什么?

    案例分析题:谈谈医患关系产生原因,以及医患关系应该是一种什么关系?

     

    第二讲 公众心理分析

    [关键词]:知觉、需要、态度、流行、舆论。

    一、知觉与公众行为

    (一)知觉的概念

    知觉是大脑对当前直接作用于感觉器官的客观事物的整体反映。

    (二)知觉的偏见

    知觉的偏见是人们在感知事物的时候,由于特殊的主观动机或外界刺激,对事物产生一种片面的或歪曲的印象。

    引起知觉偏见的常见原因有:1.首因效应;2.近因效应;3.晕轮效应;4.定型作用。

    二、需要与公众行为

    一)需要理论的要点

    1.需要的定义

    需要是人对特定目标的渴求与欲望,是推动行为的直接动力。

    2.马斯洛需要层次理论的三个要点

    人类有五种基本需要,需要是有层次的,行为是由优势需要所决定。

    二)需要的五个层级

    1.生理的需要2.安全的需要3.社交的需要4.尊重的需要5.自我实现的需要。

    (三)五种需要的排列关系

    马斯洛认为,对一般人来说,这五种需要由低到高依次排成一个阶梯。生理需要和安全需要属低级需要,尊重的需要与自我实现的需要属于高级需要,归属和爱的需要为中间层次,基本上也属于高级需要。马斯洛认为,在同一时间、地点、条件下,人存在多种需要,其中有一种占优势地位的需要决定着人们的行为。

    三、态度与公众行为

    (一)态度及其与结构

    1.态度的定义

    态度是人们在认识和行为上相对固定的倾向,包括人对事物和社会认知的倾向、情感的倾向和意图的倾向,比如赞成或反对、喜欢或厌恶、肯定或否定等等,这些倾向一经形成就比较稳定、比较持久地影响着人们对事物的判断和看法,影响着人们的行为方向和方式。

    2.态度的结构

    一般说来,态度由认知、情感、意图三个因素构成。

    (二)态度的特性

    1.态度的社会性;2.态度的针对性;3.态度的协调性;4.态度的稳定性;

    5.态度的两极性;6.态度的间接性。

    (三)影响和改变态度的因素

    态度的形成与改变受如下一些主客观因素制约:1.社会因素;2.团体因素;3.宣传因素;4.个性因素;5.态度系统特性因素

    四、价值观与公众行为

    (一)价值观的定义

    价值观即人们对于是非、善恶、好坏的评价标准,对自由、幸福、荣辱、平等这些观念的理解和轻重主次之分,是影响个体行为的重要因素。

    (二)影响人们价值观的因素

    价值观决定了人们行为的方向和能达到的程度,即决定了人们向往什么,追求什么,喜欢什么、推崇什么。

    ★重点探讨:电影文化的心理效应:介绍“霹雳娇娃”、“无间道”、“绿茶”、“活着”的电影片段,从人性的角度,分析看电影文化的心理特征和境界。

    思考题:谈谈你对电影文化的认识?

     

    第三讲 公共关系传播媒介

     

    [关键词]:模式 理论

    一、公共关系传播模式与理论

    (一)拉斯韦尔的 5W模式

    1.5W的基本含义

    谁传播(who);传播什么(says what);通过什么渠道(which channel);向谁传播 (to whom);传播的效果怎样 (what effects)。

    2.传播研究的范畴

    在对传播的研究中,拉斯韦尔所提出的研究对象的五大部分也完全可以视为传播研究的五个基本范畴:(1)传播的控制分析;(2)传播的内容分析;(3)传播的媒介分析;(4)传播的对象分析;(5)传播的效果分析。

    (二)把关人理论

    1.把关人的概念

    把关人又称守门人(gate keeper),它是指在信息传播过程中,对信息的提供、制作、编辑和报道能够采取疏导抑制行为的关键人物。

    2.把关人的传播行为

    疏导抑制。一般地说,把关人的传播行为包括疏导抑制两个方面。把关人对某些信息准予流通的便是疏导行为,对另一些信息不让其流通或暂时搁置便是抑制行为。

    (三)两级传播模式

    两级传播论是由美国著名社会学家拉扎斯菲尔德提出的。两级传播的假设:观念总是先从广播和报刊传向意见领袖,然后再由这些人传到人口中不那么活跃的部分。也就是说,信息的传递,是按照媒介--意见领袖--受众这种两级传播的模式进行的。

    这里所提出的中间环节意见领袖,其作用与意义举足轻重。意见领袖又称舆论指导者,指社会活动中能有较多机会接触来自各种渠道的信息即消息灵通人士,或对于某一领域有丰富的知识与经验即 权威专家,而其态度和意见对广大公众影响较大的那一部分人。

    (四)受众选择3S

    经过长期的观察和研究,传播学者发现受传者在接触媒介和接收信息时有很大的选择性,这就是受众心理上的自我选择过程。这个选择过程表现为以下三个方面:

    1.选择性注意;2.选择性理解;3.选择性记忆。

    (五)议题设置论

    科学调查的结果表明:大众传播对某些议题的着重强调和这些议题在受传中受重视的程度构成强烈的正比关系。换言之,在大众传播中越突出某一事件,多次、大量地报道某一事件,就会使社会中的公众突出地议论这一话题,这便是议题设置。议题设置的理论基于以下两个观点:

    1.过滤作用

    各种传播媒介对传播信息的过滤作用。传播媒介对极为浩繁的信息是经过选择后才传达给公众的。当大众传播媒介热情介绍某个新闻事件,也就意味着这个新闻事件可能成为公众关注的议题

    2.信息整理

    面对传播过多的信息环境,公众常常感到无所适从。他们需要有人出面对复杂的信息加以整理,划出重点和优先顺序,为他们选出那些值得关心和注意的事件,这正是把关人的作用所在。

    二、公共关系的传播媒介

    (一)报纸与杂志

    报纸、杂志同属于文字传播媒介。

    文字传播媒介是指借助于可视的语言文字符号传递社会信息的各种载体。

    文字传播媒介的特征:1.记录性;2.扩散性;3.渗透性;4.准确性。

    1.报纸传播信息的优势和弱点

    (1)报纸传播的优势:传播面广;传播迅速;具有新闻性,阅读率较高;文字表现力强;便于保存和查找;传播费用较低。

    (2)报纸传播的弱点:时效性短;传播信息易被读者忽略;理解能力受限;色泽较差,缺乏动感。

    2.杂志传播信息的优势和弱点

    (1)杂志传播的优势:时效性长;针对性强;印刷精美,表现力强。

    (2)杂志传播的弱点:出版周期长;声势小;理解能力受限。

    (二)广播与电视

    广播与电视同属于电子媒介。电子媒介是指运用电子技术、电子技术设备及其产品进行信息传播的媒介,其中包括广播、电视、电影、录音、录象、光碟(CD、LD、VCD、DVD)等等。电子媒介在信息传播中具有以下特征:1.时效性;2.远播性;3.生动性;4.技术性。

    1.广播在传播信息中的优势和弱点

    (1)广播的优势:传播面广;传播迅速;感染力强;多种功能。

    (2)广播的弱点:传播效果稍纵即逝,耳过不留;信息的储存性差,难以查询和记录。

    线性的传播方式,即广播内容按时间顺序依次排列,听众受节目顺序限制,只能被动接受既定的内容,选择性差。广播只有声音,没在文字和图象,听众对广播信息的注意力容易分散。

    2.电视在传播信息中的优势和弱点

    (1)电视的优势:视听结合传达效果好;纪实性强、有现场感;传播迅速、影响面大;多种功能、娱乐性强。

    (2)电视传播的弱点:和广播一样,传播效果稍纵即逝,信息的储存性差,记录不便也难以查询。电视节目同样受时间顺序的限制,加上受场地、设备条件的限制,使信息的传送和接收都不如报刊、广播那样具有灵活性。电视节目的制作、传送、接收和保存的成本较高。

    (三)Internet:国际互联网

    1Internet的基本特征

    2.Internet的服务功能

    Internet含有极丰富的信息资源,并能使处于异地的计算机方便地进行信息交流与资源共享。人们利用Internet可以进行科学研究、文档查询、联机交谈、电脑购物等等。Internet主要有以下服务功能:电子邮件(E-mail);文件传输(FTP);网络新闻等。

    3Internet的公共关系传播意义

    Internet的传播特征主要表现在范围广泛超越时空高度开放双向互动;个性化;多媒体,超文本;低成本。

    (四)非语文传播符号

    1.身势语言

    身势语言指人们身体部位作出表现某种具体含义的动作符号。

        2.情态语言

    情态语言指人脸上各部位动作构成的语言。

     

    ★重点探讨:

    DV大赛看校园文化

     

    近年来,许多学者对校园文化从理论上和实践上进行了许多有价值的探索。随着学校的精神文明建设工作的深入发展,校园文化建设的研究就提到更为显著的地位。

    对于校园文化,有多种不同解释,在本人定义为:在学校育人的环境中,以学生为主体,以教师为主导,以促进学生成长和提高全员文化素质及审美情操为目标,由全体师生员工在教学、科研、管理、生产、生活、娱乐等各个领域的相互作用中共同创造出来的一切物质的和精神的成果。选择从社会的价值观来进行讨论,聚焦不同的校园文化,研究社会需求人才和育人制度之间的关系。

        对整个社会来说,大学的教育给予了学生很大的期望,它对我们的社会产生巨大的影响。大学的教育不仅仅是知识的传授,而应注重技能和价值观的培养,以适应社会发展的需求,学校的育人和社会的发展有着密切关联。

        一个国家的发达水平,很大程度上决定于它拥有的人才,而高等教育为国家和社会提供怎样的大学毕业生成为社会关注的聚焦点。社会存在决定社会意识,我们将在研究不同的校园文化中,更好的了解校园中学生的思想状态、文化的内涵和精神面貌。

        中山大学DV大赛的参赛作品就是最好的体现。

    观赏的DV作品

    断点---冠军作品

    走进新时代----紧贴十六大,时代触觉敏锐的作品。

    猪油与烧饼———公关班同学参与拍摄作品,荣获最具创意奖

    Die for beauty——唯一一部涉及敏感话题,勇闯雷区的作品,虽没获得任何奖项,但风格另类,予人震撼至深。

    ——广东商学院DV作品

    思考题:谈谈DV作品中的校园文化内涵?

    第四讲 公共关系的过程

    [关键词]公共关系管理  形象设计

    一、公共关系管理过程的基本模式

    (一)公共关系管理的意义

    1.增强公共关系工作的系统性;2.提高公共关系工作的可控性;3.加强公共关系工作的预测性;4.促进公共关系工作的成熟性。

    (二)公共关系管理过程的基本模式

    1.四步工作法:共关系调查;公共关系策划;公共关系实施;公共关系评估。

    2.六步工作法:估计形势;确定目标;确定公众;选择媒介;编制预算;评价结果。

    (二)组织形象地位测量

    1.知名度

    一个组织被公众知晓、了解的程度,是评价组织名气大小的客观尺度,侧重于的评价,即组织对社会公众影响的广度和深度。

    2.美誉度

    一个组织获得公众信任、好感、接纳和欢迎的程度,是评价组织声誉好坏的社会指标,侧重于的评价,即组织的社会影响的美丑、好坏。

    良好的组织形象是由知名度和美誉度构成的,缺一不可。知名度需要以美誉度为客观基础,才能产生正面的积极的社会效果;美誉度需要以一定的知名度为前提条件,才能充分显示其社会价值。

    (三)组织实际形象的四种状态

    根据知名度和美誉度在现实状况中的不同构成,可将组织的实际形象区分为四种状态:

    1.高知名度/高美誉度;2.高美誉度/低知名度;3.低知名度/低美誉度;4.低美誉度/高知名度。

    二、形象设计

    (一)概念:什么是CIS

    Corporate  Identity  System,简称CIS,直译为组织识别系统。是一种组织形象战略,通过提炼组织的理念个性和行为特征,整合组织的各种形象资源,对组织的一切形象要素进行统筹设计、规划、控制和传播,以突出组织的形象个性和统一性,强化组织整体形象的视觉冲击力和市场竞争力。

    (二)CIS概念的要点

    个性化

    统一化

    整合性

    识别性

    从而实现导向作用、约束作用、凝聚作用、激励作用和辐射作用

    (三)CIS战略的构成

    1.理念识别MIS

    2.行为识别BIS

    3.视觉识别VIS

     

    ★重点探讨:城市文化与城市形象分析(广州、深圳、珠海、上海)。

    思考题:营销城市的切入点

    第五讲 公关实务(上)

    [关键词]广告 演讲 报告 会议 谈判

    一、公关广告

    (一)公共关系广告与商品广告

    1.公共关系广告的定义

    公关广告,实质上是一种带有某些广告特征的,但不限于商业活动的,不以赢利为目的的传播行为。

    2.公共关系广告与商品广告的区别

    (二)公共关系广告的类型

    1.形象广告;2.公益广告;3.观念广告;4.响应广告。

    二、演讲与报告

    (一)语言交流方式的特点

    1.口头语言交流的特点:

    1.直接性;随时性;双向性;反馈性;情感性;主观性。

    二)演讲与报告

    演讲与报告均是一种有准备的、较规范的言语传播方式。演讲是演讲者就某一问题向一定范围的听众发表讲话。报告则是演讲的一种形式。演讲是由演讲者、演讲的内容和演讲的听众这三大要素构成的。

    1.演讲传播的优势

    具有较强的劝服效果;有效的信息交流;表现力较强;有助于提高声望;直接宣传组织的观点;直接提供权威性资料。

    2.演讲技巧

    做好演讲的准备;选择优秀的演讲者,一个优秀的演讲者必须包括的条件:足够的权威性;演讲者具有较强的语言能力和技巧;演讲者的热情;演讲者的理智与智慧;演讲者的仪表仪态。

    3.运用演讲艺术

    腹稿、文字稿和立意

         

    •地球是人类的摇篮,但是人类不能永远生活在摇篮里。总有一天,人类要冲出大气层,开始是小心翼翼的,最后征服整个太阳系!

    三、会议、会谈与谈判

    (一)会议和会谈

    会议和会谈均是有组织、有目的的言语沟通活动方式。

    会议是围绕一定目的进行的、有领导、有控制的集会,有关人士聚集在一起,围绕一个主题发言、插话、提问、答疑、讨论,通过语言相互交流信息,交换意见,议论问题,解决问题。会谈是会议的一种形式。

    (一)会议的公共关系功能

    (二)举行会议的注意事项

    1.召开会议的现实需要;2.明确会议的特定目标和主题;3.做好必要的准备工作;4.积极引导会议的顺利进行;5.若有必要,可策划与会议配套的宣传活动。

    (三)谈判

    谈判是有关方面就共同关心的问题相互磋商,交换意见,寻求解决的途径和达成协议的过程。公共关系人员经常需要代表组织与特定的公众就相互关心的问题进行谈判、交涉;或者为组织的领导人组织、安排有关的谈判活动,因此需要了解和掌握这种特殊的语言沟通艺术。

    一般正规的谈判过程分为六个阶段:1.导入阶段;2.概说阶段;3.明示阶段;4.交锋阶段;5.妥协阶段;6.协议阶段。

     

    ★重点探讨: 广告的心理效应

    1 . 人性化广告

    影响人生态度的广告,拒绝平凡的广告——人性化的广告创意

    广告由“强攻”转向“智取”,注重和讲究广告的心理效果,适合消费者的“口味”,迎合消费者的愿望。“一切为了打动消费者”成为广告设计的宗旨。情感化、幽默、暗喻、联想、点到即止……成为广告表现的趋势。

    市场营销观念下的企业不再站在自己的立场上作表现自己的广告了,多采用强调感性诉求的软广告,以“一切为了打动消费者”作为广告设计的宗旨,从呆板的硬广告演变为“尽在不言中”的感性广告。

    通过展示9个公益广告和商业广告,阐明影响人们人生态度的广告在创意上更加注重人性的基本要求,以景感人、以情动人。在“说什么”和“怎么说”的问题上,表达得更为委婉,通过叙事性的情节感化受众,将商机与人生哲理、商业效益与社会效益结合起来,把广告的思想性与艺术性推向成熟的巅峰。

    2 . 幽默广告

    幽默广告是通过双关语、俏皮话、夸张和讽刺等表现手法,将严肃的广告推销目的包容在轻松诙谐的喜剧气氛中,使受众对产品或企业产生注意,并且在一种愉悦的心境中接受广告传播的信息从而改变态度的一种广告形式。

    通过展示10个幽默广告,阐明了幽默的内涵,幽默作为一种思维模式和广告创意的一部分,无疑是具有惊人的震撼力。但它绝不能误用和滥用,必须结合实际以及广告本身的特点,恰当地使用幽默,才能使它真正地发挥作用。

    3 . 情色广告

    男女情色这个主题本身很大,需要把它细分,分成几个小点,使它更加具有针对性。通过最令人心跳的几个方面考虑,可分为五个部分:爱情,魅力,本能,情色+USP,情趣。

        男女关系这类以情色为话题的广告,可以最直接的给人产生印象。不单从眼球,几乎是总全身的每个毛孔进入体内,很难不为其所动。当每个人最隐藏的好奇心得到满足,当每个人最迫切的需求得到解决,当每个人最想不通的问题得到答案时,还有不接受的理由吗?所以我们应该好好运用这个“最”字。在哪里找到这个字呢?(弗洛伊德的理论)没错,这些都会在我们刚才的广告中找到答案。

    分析就是顺着一个广告创作人的思维去走的,在这过程中,我们并不需要套上什么理论,也不必拘泥于什么框框。很自然的,我们从人的心理和生理需求上得到启发,顺着受众的需求去想象,按着受众所关心得话题去揣摩,于是成功的广告就出来了。然而回过头再分析,所有理论都可以在广告中体现出来了。通过展示10个情色广告,我们可以看到好的广告真是海纳百川的,它融入的各种各样的理论精华。

    思考题:谈谈广告能给我们带来什么深层次的思考?

     

    第六讲 公关实务(下)

    [关键词]:调查研究新闻传播 危机公关

    一、调查研究

    公关调查主要解决的关键问题是:(1)组织所处的环境(包括物质环境和文化环境);(2)组织所面对的各类公众关系的动态;(3)组织与某类关系不协调的公众的矛盾症结及成因。(4)与各种媒介组织的关系状况。

    (一)民意测验

    1.民意测验的优点

    (1)能够广泛地获得来自公众的反馈信息,以利于制订或调整组织的公关政策;(2)科学性强,而且简便易行,准确度较高;(3)便于整理统计,能迅速得到所需的信息资料。

    2.民意测验步骤

    (1)确定调查目标和公众对象:确定调查目标;确定调查对象。

    (2)抽样:抽样就是从大型的调查人口总体中抽取一部分作为调查样本,以便从样本的特征来推断整个人口总体的特征。

    (3)设计问卷。问卷的设计分为封闭式和开放式两种。

    封闭式问卷在每一问题下列出可供选择的备选答案,请调查对象选择。其形式主要有:两项选择;多项选择;对比选择;排序选择;意见程度选择。

    自由式提问没有备选答案,在问题后面留出空白供调查对象自由作答,充分发表意见。

    设计问卷须注意:一张问卷上的问题不宜过多(一般不超过30个);问题的措辞应该简洁、准确、易懂,不带倾向性引导性和强迫性;问题的顺序应按问题的类型、逻辑关系、对象心理合理安排。调查表的题目一般掌握在20分钟能答完的限额以内;问题简单明了,避免使人反感或戒备的提法。

    (4)实施调查。面访调查;通讯调查;电话调查;深度调查。

    (5)整理分析资料数据和撰写调查报告。

    (二)公众代表座谈会

    1.确定公众代表座谈会议题;2.选择与会代表和印发通知;3.举行公众代表座谈会;4.整理分析座谈会情况并撰写情况汇报。

    (三)资料分析

    资料分析对于了解某些历史牲的问题,是行之有效的。

    二、新闻传播

    (一)撰写新闻资料和新闻稿

    新闻五要素:新闻五要素(即五个w),即何时(when)、何地(where)、何时(when)、何因〔why〕、何人(who),这是新闻中不可缺少的五个方面

    要写好新闻稿,应掌握以下三个要点:

    1.新闻稿的结构

    常见的新闻稿结构有三种:倒金字塔结构、并列结构、顺时结构;其中最常见的是倒金字塔结构。

    倒金字塔结构由导语和事实两大部分组成,导语是新闻稿的灵魂,最新、最重要的内容即包含其中。导语之后是一般的新闻事实,按重要在前、次重要在后的原则排列。

    2.导语的写作

    导语在新闻稿中的地位十分重要,虽然只有一两句语,却要概括一篇新闻中最新最重要的信息,使人只看导语便可了解新闻的基本要点。

    3.新闻背景材料的运用

    新闻背景材料是对新闻人物和新闻事件起衬托补充、说明等辅助性作用的材料。

    (二)策划具有新闻价值的事件

    策划具有新闻价值的事件也叫做制造新闻策划新闻,是组织争取新闻宣传机会的一种技巧。即在真实的、不损害公众利益的前提下,策划、举办具有新闻价值的事件或活动,吸引新闻界和公众的注意力,制造新闻热点,争取被报道的机会,使本组织成为新闻的主角,以达到提高知名度、扩大社会影响的目的。

    (三)新闻发布会

    新闻发布会是组织与公众沟通的例行方式。它是一种两级传播:先将消息告知记者,再通过记者所属的大众媒介告知公众。新闻发布会对用于树立或维护组织形象,协调公共关系,引导舆论倾向。

    1.新闻发布会的工作环节

    确定主题;邀请记者;会前准备;主持会议;收集反馈信息。

    2.同新闻界协调关系的诀窍

    (1)主动传递本组织信息,真诚坦率提供情况,维护本组织和新闻媒介的良好信誉;(2)尊重记者和新闻单位,为他们的工作提供方便,无论大报小报,名记者一般记者,都要一视同仁,不能厚此薄彼;(3)指定专人负责,密切同新闻界人士的联系。   

    三、处理危机

    公共关系危机是指突然发生的、严重损害组织形象、给组织造成严重损失的事件,如公众的指责批评、恶性事故等。

        (一)组织行为不当引起的危机

    组织行为不当引起的危机是指在社会组织发展过程中,由于组织在指导思想、工作方式、运行机制等组织本身方面的原因引起的公共关系危机。一般是由于社会组织的政策失误、管理不善、产品质量等问题引发的危机。

    1.组织行为不当引起危机的原因

    (1)组织和公众双方的信任和合作的问题;(2)直接或间接损害公众的利益;(3)不能坚持不懈地努力,忽视小节。

    2.组织行为不当引起危机的类型

    (1)严重的内部事件;(2)工作失误;(3)决策失误;(4)纠纷事件。

        (二)突发事件引起的危机

    突发事年引起的危机是指由于非预见性、外在因素引起的突然发生的事件,导致组织公共关系形象受损的危机。如自然灾害、火灾、交通事故等引起的事件。

    1.突发事件引起危机的原因

    (1)出于保护自身利益的考虑,公众会远离受到破坏的组织;(2)公众对社会组织功能的恢复就会产生怀疑,对组织失去信心;(3)公众的逃避情绪和消极思维;(4)由于新闻媒体的报导的负面影响。

    2.突发事件引起的危机

    (1)由不可抗拒力导致的重大伤亡事故;(2)外在因素引起的事故;(3)外来的故意行为。

        (三)失实报导引起的危机

    失实报导引起的危机主要是由于新闻部门的报导失实,从而导致公众对组织的误解,使组织形象受损的危机事件。

    1.失实报导引起危机的原因

    (1)新闻媒体的信任度高,他们的报导习惯上被理解为事实;(2)社会公众对于事件的本身缺乏详细而全面的了解,对于事情的本质不会也很难进行科学的分析;(3)公众对某一时期存在的社会问题有一种痛恨的心理认同,很容易与新闻报导保持一致。

    2.失实报导引起危机的类型

    (1)失实和不全面的报导;(2)曲解事实;(3)报导失误。

        (四)危机的处理对策

    1.预防危机

    (1)灵敏的预警系统:为了预防危机的发生,防患于未然,组织应设立自己的情报信息网络,保持沟通联络,建立预警系统。(2)完善企业的管理系统:依靠健全的组织机构和完善的管理系统,将危机损失降到最低程度,或消灭于萌芽状态。(3)模拟准备:处理公共关系危机的模拟训练以锻炼员工在紧急情况下冷静处理问题的能力,积累处理公共关系危机的经验。

    2.危机处理过程

    (1)果断采取措施,有效制止事态扩大;(2)情况调查,收集信息;(3)成立专门机构,制订处理危机的方针和对策;(4)确定新闻发言人;(5)迅速、扎实、全面开展工作,并安抚好受害者;(6)认真做好检查,切实改进工作。

     

    ★重点探讨:

    1.法国兰蔻男士香水策划方案

    2.第五届明日之星影视新星大赛策划方案

    3.香港凤凰中文台的传播理念

    思考题:谈谈你对创意的认识?

    《公共关系学》成绩考核的评定

    1.平时作业

    平时作业占40%,堂上和课后作业。

    2.考试

    考试(闭卷)占60%

    教材: 《公共关系学》高等教育出版社 20003

    参考教材:谭昆智主编 《营销城市》中山大学出版社 20044

     
    展开全文
  • 某工业企业公共服务平台架构设计

    千次阅读 2011-01-26 14:51:00
    最近参与到的一个大的工业企业系统的架构设计,思路整理的过程记录下来

    平台背景

    XXXXXXXX平台需依托现有 IT系统及未来信息系统建设的要求,规划部署公共服务及基础计算资源,要求对现有业务系统平台进行全面的统一规划和翔实的梳理,建立高可用性、高性能的业务服务载体,提供不间断的业务统筹水平和实施监管能力,符合现代 IT 建设运维要求。

    系统多样化,采用技术平台也有其多样性,既有集中控管的业务系统,也有分布式运营的生产系统,从技术层面来看,存在多种异构应用服务,异构数据平台等多种计算资源。硬件层面涵盖了多中操作系统及主机环境的服务器和存储系统,网络交换及路由分布涉及到多种网络设备及核心汇聚。

    新的公共服务平台应该是一个具备高可用性的业务环境,这种高可用表现在业务运行的高可用性,而非单一的数据库层面或服务器系统的高可用性。

    新的公共服务平台应该是一个具备高性能的业务环境,这种高性能不但体现在业务响应时间和业务处理的速度,还体现在对业务并发控制及数据吞吐量的性能保障。

    新的公共服务平台应该是一个具备松耦合架构的可扩展的技术平台,该平台可以提供统一的标准来保障异构系统的读取接口和其他业务横联及流程系统所需的开放协议,此架构易于实现,原有业务系统改造可在此架构上实现平滑的重构,降低系统迁移的风险。

    新的公共服务平台应该是一个安全的、易于管理的、符合ITIL 运维建设思路的服务管理平台。

    总体思路

    基于以上背景和技术要求,架构设计的总体思路如下:

    由于这是一个新建系统且必须严格的考量其业务的高可用性、高性能,因此从设计之初务必考虑其系统载体所提供的服务类型及特征,比如此公共服务平台上运行的系统属于哪种性质的 IT系统,是计算密集型还是服务流转型,是高集中高频率的数据处理吞吐型还是并发访问控制型,是计算资源安全重于效率型还是为保证效率平衡系统瓶颈型,是总线服务入网即用的 ESB 类型还是面向服务流程保证高度统一的 SOA 类型,是分布式集中控管的私有云类型还是多层次的集中服务分发类型。根据这些我们有必要编制一个企业 IT 业务系统调查表并请用户方及系统实施方配合填写。

    当我们确认了系统类型后,结合业务情况,比如考虑应用吞吐量、分发HTTP 请求数量、 session 持久性、数据处理形式(逻辑读写、查询)等确认系统的初始架构,并以业务系统数据流为轴线,划分每一个层次的架构分布,结合容量管理充分考虑硬件及服务器存储数量和负载均衡的模式。

    涉及到数据库层面的东西我们还是要结合业务的特征,来确认在保证高可用、高性能的条件下,如何进行数据库的环境架构设计,是使用多库横联形成DW 便于使用 cube 查询并将其用于 BI 等业务,还是使用多实例同步方式保证性能和高可用,还是使用单实例多节点方式来保证性能,以上方式各有适合的方面,需要我们审时度势来分别考量。

    技术架构思路

    本小节旨在描述技术架构,不涉及任何厂商产品配置,您可以使用任何厂商的产品来配置此技术架构的搭建。本技术架构适用用于目前的主流厂商和开源厂商产品。并已经过实际项目的论证。

    业务的高可用性这一点上,我们以 2点设计来实现这个要求。

    1、 我们将数据流向作为轴线,划分了几个层次,对每个层次中的应用服务提供HA/LB 的集群设计,用以避免单服务的单点故障,并在集群设计的时候考虑故障切换和负载均衡的设计属性,包括链接上级服务和下级服务的链路均衡并采用适合的链接方式,如采用 JDBC/OCI POOL 方式及含有 LB/HA 特性的连接字符串 XE 的驱动模式。

    2、 我们从整个系统来看,对于业务流程,如HTTP 分发过程中,静态页面及 J2EE MDB SESSION 会话、 Spring Framework 中涉及到的数据持久化设计中对于 HTTP 会话性能和应用服务器处理时的路由过程是不一样的,在前端页面中及时采用了 JSON 或其他 AJAX 方式的页面对于 webcache 的处理产生了业务响应速度的不同影响,因此在整个横向的轴线上,我们有必要对进入 HTTP 服务的数据进行 cache 的缓存设计,用以保证 HTTP 的高可用。对于应用服务层面,如何涉及到异步数据传输的层面的东西,为了考虑更好的可用性和可靠性,必要将 JMS 服务作单独的冗余设计,同理,如果业务系统中发现应用服务中涉及到的流程 BPEL 的服务占有率很高,那么单一的设计应用服务器的冗余和负载均衡已经无法解决业务流程上的可靠性了,那么有必要对流程曾面上的 BPEL 的处理进行冗余设计了,再进一步来看,如果这些应用层面的服务还涉及到了流程集成和页面集成是否还需要对异步响应发布订阅、页面集成等技术要点进行冗余设计都值得大家考虑。

    业务的高性能这一点,首先不能为了性能而设计性能拓扑。这一点对于复杂系统设计来说不具备好的耦合度,很容易和可用性设计产生重复投资。架构产生冗余。因此最好的性能设计在设计高可用的时候架构已经考虑了性能的规划,如缓存服务的设计,集群设计等。

    松耦合和高度开放的可扩展性是以架构设计之初就需要拿捏的,松耦合需要进行设计上的迭代和测试,优化才能满足。实践是检验耦合度的唯一标准,再次不作赘述。可扩展性这一点对于不符合标准规范的私有协议,我们设计的时候一概不采用,不考虑,必要有开源组件的兼容和替换使用,其次使用有标准支持规范的设计模式,最后使用具备API 接口调用的架构组件。以上三点保障可扩展性的成功实施。

    易于管理监控维护是架构设计的必备考虑,标准化后的组件、流程、服务均有对应的管理方法、工具来维护,因此松耦合可扩展成为了易于管理维护的基础。

     

    以上架构图是一个典型的应用数据流的系统流程图,我们可以看到这些标注了数字的部分所需的高可用性方式,一般来说我们可以从技术上考虑以下 cluster模式:

      第一种模式(如图左所示)也称为  青铜拓扑 。 这种模式包含一个应用程序服务器集群,其中,形成系统集成总线( SIBus )的  WebSphere Process Server  业务应用程序、 CEI  和  BPC Explorer  等支持应用程序、以及托管消息传递引擎( ME )的消息传递基础设施全部驻留在构成集群的每个应用程序服务器中。

    青铜拓扑适合这样的解决方案:只包含同步 web  服务和同步  SCA  调用,最好只有短期运行流。

    第二种模式(如图中所示)也称为  白银拓扑 。这种模式拥有两个集群:第一个集群包含  WebSphere Process Server  业务应用程序和支持应用程序,第二个集群包含消息传递基础设施。

    白银拓扑适合这样的解决方案:使用长期运行流程,但不需要 CEI 、消息排序、异步延迟响应、 JMS  或  MQ  绑定、以及消息排序机制。

    第三种模式(如图右所示)也称为  黄金拓扑 。与前面的模式不同,支持应用程序被分隔到第三个集群中。

    黄金拓扑适合其余的所有情况,其中,异步处理在解决方案中发挥举足轻重的作用。这种拓扑还为应该在这种环境中运行的业务流程应用程序提供大部分 JVM  空间。如果可用硬件资源允许设置一个黄金拓扑,建议使用这种拓扑模式从头开始,因为它是用途最广的拓扑。

    构建 cache服务非常有必要,有效的网络 Cache 系统可以大大地减少网络流量、降低响应延时以及服务器的负载。但是,若 Cache 服务器超载而不能及时地处理请求,反而会增加响应延时。所以, Cache 服务的可伸缩性很重要,当系统负载不断增长时,整个系统能被扩展来提高 Cache 服务的处理能力。尤其,在主干上的 Cache 服务可能需要几个 Gbps 的吞吐率,单台服务器(如 SUN 目前最高端的 Enterprise 10000 服务器)远不能达到这个吞吐率。可见,通过 PC 服务器集群实现可伸缩 Cache 服务是很有效的方法,也是性能价格比最高的方法。 基于LVS 可伸缩 Cache 集群的体系结构如图 2.3 所示:在前端是一个负载调度器,一般采用 IP 负载均衡技术来获得整个系统的高吞吐率;在第二层是  Cache 服务器池,一般 Cache 服务器放置在接近主干 Internet 连接处,它们可以分布在不同的网络中。调度器可以有多个,放在离客户接近的地 方,可实现透明的 Cache 服务。

     

    Cache服务器采用本地硬盘来存储可缓存的对象,因为存储可缓存的对象是写操作,且占有一定的比例,通过本地硬盘可以提高 I/O 的访问速度。 Cache  服务器间有专用的多播通道,通过 ICP 协议( Internet Cache Protocol )来交互信息。当一台 Cache 服务器在本地硬盘中未命中当前请求时,它可以通过 ICP 查询其他 Cache 服务器是否有请求对象的副本,若存在,则从邻近的 Cache 服务器取该对象的副本,这样可以进一步提高 Cache 服务的命中率。

    对于是否有必要对于系统采用 SOA化,我们首先来归纳一下目前的 SOA 优点、缺点,如下表:

    表 1.  优点、缺点、糟糕之处
     

    SOA 的良好业务影响

    SOA 的不良业务影响

    SOA 糟糕的业务影响

    敏捷性- SOA  支持更加快速地开发业务流程以及更加轻松地对业务流程进行改变。它可以使组织更迅速地适应他们业务环境的改变。这就转化成为实际的市场优势,因为它能够使产品和服务比竞争对手更快速地推向市场。

    组织结构的改变 在每个  SOA  的中心都有一个卓越中心( COE )。 COE  就是一个控制  SOA  技术开发以及向组织的其他人员提供专业知识的新实体。 SOA COE  是对任何组织来说都是新增加的,并且由此推出,当它实力雄厚并且在这里所做的决定会影响组织的其他人员时,它的引入可能会导致冲突。

    转变并不容易 转化和组织成为以服务为中心并不容易。过渡到  SOA  的特点是演变而不是革命。以孤岛的传统形式创建的组织需要改变它们的结构,以充分利用成为以服务为中心的优势。这种转变是复杂的、昂贵的,而且从来不缺少这种变革的反对者。

    一致性 业务与  IT  之间更加紧密的合作关系抛开了阻碍  IT  实现业务需求的传统障碍。业务领域中的服务足迹是一项业务功能,并且用业务术语对其进行了描述。它实现的细节是隐藏的。

    组织权力结构的改变将服务的所有权和控制权放到业务领域中,会改变组织中的权力结构。这样做通常会遭遇来自那些有维持现状特权的人的阻力。

    文化改变- SOA  不仅仅代表着技术的改变。伴随着这种改革产生了一个组织的文化变革,因为它成为了价值的驱动。组织必须明白敏捷意味着什么以及如何充分开发其自身的敏捷性。糟糕的事实是,这是最难学习的课程之一。

    业务流程的改进 一般而言,任何  SOA  与业务流程的再次思考都是相关的。这种业务流程重构对优化组织运营业务的方式而言是一次机会。良好的重构工作能够使业务的运营效率得到显著提高。

    业务面临的新挑战 业务必须给予  IT  更多的指导。业务线必须对服务及增强行使所有权并对其负责,从而启动开发与变化周期,因为它们将推动这一进程。这不是一种典型的由业务线进行补充的作用,这将会导致不合适的改变。

     

    灵活性 在  SOA  中坚持良好的软件工程实践能够提高  IT  对业务需求的响应。缩短了产品和服务的上市时间,降低了开发与改变流程的成本。

    IT 在变得更简单之前会越来越复杂 利用一套如业务流程执行引擎和  ESB  的技术来实现  SOA 。把这种技术添加到  IT  规划中并不会让它更加简单,即使当它的优势远远超过了它的成本。然而, IT  规划更复杂并不意味着它就不能以更简单的形式出现。这种服务的推出让  IT  的复杂性成为秘密。这些服务的消费者不需要知道服务内部是如何运行的。结果,任何发生在后端的的合理化操作,都可以隐藏在服务界面之后。

    技术本身不会体现价值 专注于基础架构和技术的  SOA  是很可能失败的。 SOA  举措是建立在比以往更快速更低成本地提供业务价值的承诺之上的。一种过于重视技术的  SOA  是不可能实现该承诺的,因为它们不会显示出业务人员希望看到的价值。灵活性只有在加速运营性业务需求,或者通过支持业务的合理性来降低操作系统成本时才会 被认为是业务价值。以技术为中心的举措一般不会这样做。

    数据统一 服务接口可提供统一数据特征的机会,以使服务接口使用遵照统一的数据模型的数据。统一在这里的意思是通用: 

    结构  元素之间的结构关系是相同的,因此例如地址一贯地包含门牌号、街道、城市、地区和邮政编码。

    语义  语义是指含义以及数据的使用。数据必须有统一的含义,并且必须以不会产生歧义的方式使用。例如客户的概念可能会在网站上遇到,与帐户所有者形成对比。

    格式  数据的表现方式很重要。 DDMMYYYY  格式的日期不能与  MMDDYYYY  格式混淆。

    类型  类型是由数据的表现形式以及一套可以执行的行为决定的。

    时间  时间指的是属性更新的时候。在某些情况下属性会在前端系统进行实时更新。然而一些属性只在定期的批处理时进行更新。

    生命周期  在什么情况下将数据添加到数据库中,什么时候进行更新,以及什么时候、以什么方式最终从数据库中删除数据。

     

    没有数据视图 服务的标准接口需要统一的数据视图。这种统一视图通常不存在,并且设法开发统一视图时往往会发现组织中的视图非常不同。

    可能无法实现统一 使数据的所有特点一致几乎不太可能实现。除了上述问题之外,与  脏数据 ”  相关的问题也总是存在。处理一致性是设计服务接口面临的巨大挑战之一。尴尬的事实是建立统一的服务接口是一件非常困难的事情。

    运行监控 用于支持  SOA  的技术和原理使对业务流程的监控更加轻松。这种监控类型支持来自日常运行的反馈。该反馈可用来衡量组织对其战略目标的实现情况如何。 

    传统的业务流程(BP )与表现逻辑都写入了包含业务逻辑的相同程序。所能希望的最好结果就是至少将不同逻辑类型组合在一起,但是即使这一点也往往难以实现,其结果是很难监控逻辑范畴。例如业务流程只能作为应用程序的一部分来监控,因为它不能被分离出来。

    SOA 通常伴随着业务流程执行引擎。这种技术的引入可促进业务流程逻辑被分配到一个点上。在一个点上拥有  BP  使  BP  监控成为可能,而无需在应用逻辑中使用  BP  逻辑。这不是  SOA  的专有技术,但是用于支持  SOA  与来自  SOA  良好软件工程实践规则的技术能够使该技术在  SOA  中更加轻松地得以实现。

    监控复杂性 开发一个针对组织目标提供反馈的业务流程监控模型是一项需要专业技能的重要工作。

     

    利用操作平台- SOA  使用操作平台为服务提供业务功能。这意味着对现有系统的投资可通过将其重新包装到服务中来使用。

    技术不匹配 在某些情况下并不能轻松地对操作平台进行重新打包,原因是业务功能结构与需求不匹配。例如,如果一个添加新客户的事务在姓名和地址添加到客户数据库之后有一个提交点,并且在安全数据被添加之后有第二个提交点,那么这两种操作将紧密链接。

    可能需要做出改变 在某些情况下可能需要改变操作平台。当需要在  ERP  中作出改变时,供应商非常不情愿做出改变。如果组织决定在内部作出变革,服务资金必须考虑维护成本。

    那么我们的系统是不是一个适合做成 ESB企业服务总线形式的系统架构呢?回答是否定的。 ESB 有时被描述为 分布式 基础架构,这与其他的解决方案形成了对比,比如消息代理技术一般被 描述为 中心辐射型(hub-and-spoke) 。然而,这并 不是真正的差别。正在研究两个不同的问题: 控制的集中 基础架构的分布 ESB  和中心辐射型( hub-and-spoke )解决方案都集中控制配置,比如服务交互的路由、服务命名等等。同样,这两个解决方案可能部署在简单的集中式基础架构中,也可能采用更复杂的分布式方式进行部署。毫无疑问,不同的技术对它们所支持的物理部署模式有不同的约束 —— 有些可能适合于非常广泛的分布,以支持在很大的地理范围内进行的集成,而其他的可 能更适合于部署在本地群集中,以支持高可用性和可伸缩性。使物理分布需求与候选技术的功能相匹配是  ESB  设计的一个重要方面。另外的一种能力也是非常重要的,就是以增量方式扩展最初的部署来反映不断变化的需求、集成附加的系统或扩展基础架构的物理范围。 如下图: 分布式 ESB  基础架构的集中控制
     

    产品架构思路

    基于上的思路,我们按照以下关键字来定义我们的产品架构设计:

    产品架构

    下图是符合我们的业务系统架构需求的一个产品架构图,该架构图采用的的 Oracle产品线,当然,开源和 IBM 厂商也可以提供此架构的产品,而且性能和价格会更便宜些。我来解释一下这个图:

     

    自顶向下来看,我们防火墙以下首先 web请求需要通过负载均衡设备,此设备可以是硬件的 F5 等设备也可以是例如 IBM 产品中的 websphere edge server 服务,可以将此服务配置成为 HA 模式,第一条虚线表示此层次的 web 负载分发已经完成并很高效了,第二层,这里使用的是 10.1.2 版本的 Oracle web cache ,这就是缓存的作用,在 Websphere 中也有此产品,使用 HA 设计,第二条虚线表示此层将 HTTP 会话进行了分类和静态缓存,提升了性能和高可用,到了第三层, HTTP SERVER ,这里对应 IBM  HTTP SERVER ,提供静态页面解析,缓解应用服务器的压力,并提供反向代理的负载均衡。如果涉及到 OCI proxy 方式的数据库操作,实时性高以及管理维护的需求,包括业务中涉及到数据库的事务 / 回滚段可以 PLSQL 直接操作数据库,否则就将请求交给对应的 servlet 交给相应的 javabean 去出去,这些 bean 可以去进行数据库读写,那么就走 jdbc/jdo 的路径去 oracle rac ,可以去关联某个流程 BPEL 处理 BPLM 的数据,那么就走 process server 去走流程,当然这里的 process server 也可以根据情况设计成 HA 方式,可以去关联某个异步文件传输同步服务,那么就可以管理 JMS 组件,如 MQ 服务,涉及到订阅和发布的就设计为 MESSAGE BROKEN 。应用服务出口可以有安全审计模块,对应 IBM TAM SSO 等组件,无此安全要求的可以去找 DB ,这里的 DB 可以设计为单实例多节点的 ORACLE RAC 形式。如果涉及到多个 RAC 形式可以考虑使用 gird 做,那就是管理层面的问题了。

    缓存

    大型互联网应用,例如门户网站、在线商城以及联机交易系统等等,往往需要处理大批量、高并发的用户访问请求,这对应用程序的性能提出了比较高 的要求。性能问题一般可以在开发和部署两个阶段加以解决。在应用部署阶段,通过增加软硬件投入的方式比较常见,但其费用往往较高;而在软件开发阶段如果能 够提前定位并解决性能瓶颈,则会减少大量成本。在开发阶段提升性能,一种常用的思路是降低瓶颈资源、业务模块的访问压力,因而在应用程序中加入缓存机制则 因成本低、实现方便等优点成为常见解决方案。

    缓存(Cache )在计算机科学领域指的是一些数据副本的集合。当原始数据访问速度较慢或代价过高时,可以通过使用在高速存储区域中保存原始 数据的常用数据副本,从而提升访问速度。常见的硬盘缓存, CPU  缓存,网页缓存等等都是缓存概念的应用。在企业应用开发时,开发人员也可以基于缓存的概念,使用应用程序级别的缓存,从而来提升应用性能。

    常见的开发方式为在 Java  虚拟机里通过  Static  成员变量、 Context  对象或者用户  Session  中,保存常用的业务数据。一旦有访问需求,则先从缓存中尝试获取数据,如果尝试失败,再从实际模块获取数据并更新缓存。

    此类方法实现简单,但容易遇到扩展性方面的问题:为了满足业务增长需求,用户可能需要在  多台  主机组成的  集群  中部署应用。此时 JVM  级的缓存会面临服务器间缓存同步的问题,处理不好,会导致数据不一致等严重错误。其他可能的问题还有:

    ·  应用开发模式的改变:应用程序需要在相关业务处理逻辑处加入缓存相关处理。

    ·  配置管理:需要在缓存的有效期、大小等方面,如果要求可配置,则需要开发人员一定的工作量来满足此类需求。

    针对这些常见问题,IBM WebSphere Application Server  则提供了一套动态缓存框架,能从不同方面加以解决。

    IBM WebSphere Application Server 动态缓存机制介绍

    动态缓存机制是 WebSphere Application Server  为应用程序开发人员提供的一套扩展服务,其主要功能组件如下图所示:

    WebSphere Application Server 动态缓存的主要功能组件
        动态缓存机制架构如上图所示。动态缓存机制的核心功能为:在内存中缓存 Java  对象,应用程序可以通过  API  来访问这些对象。为了减少内存消耗,动态缓存服务也采用一些缓存替换机制(例如  LRU-  最近最少使用算法)来实现。对应不同的应用类型,动态缓存机制为应用开发人员提供了不同层面的缓存服务:展示层的  Portlet  和  Servlet  缓存服务和业务层的  WebService  缓存服务、 Java  命令缓存服务和对象缓存服务。

    动态缓存服务部署示意图
     
    为多服务器环境下动态缓存机制的部署示意图。应用程序只需通过 API  来调用缓存服务即可,动态缓存服务会 自动 在不同服务器之间根据定义好的策略进行缓存数据同步。当收到应用程序缓存访问请求时,缓存服务会首先在本地缓存中查找相应对象提供服务。一旦被请求的对象 位于其他服务器时,动态缓存服务会通过数据复制服务(Data Replication Service, DRS ),来从其他服务上获取相应数据。如果对象在本服务器上有改动,如缓存更新或者缓存删除,动态缓存服务也会通过数据复制服务通知其他服务器。

    以下为不同种类动态缓存服务之间的功能比较 :

    缓存服务功能比较及使用 动态缓存服务模块功能比较
     

    服务名称

    应用范围

    优点

    缺点

    Portlet 缓存

    对 Portlet  的页面输出进行缓存

    使用方便,仅需配置即可。

    适用范围有限。

    Servlet 缓存

    对 Servlet/JSP  页面输出进行缓存,包括对  Struts  和  Tiles  标签的输出结果进行缓存。

    使用方便,仅需配置即可。

    适用范围有限。

    Web Service 缓存

    缓存 Web Service  的执行结果

    使用方便,仅需配置即可。

    适用范围有限。

    命令缓存 (Command Cache

    缓存某个 Java  类的方法的执行结果。

    通过 API  访问,适用面广,配置简单。

    需要修改编程模型,实现特殊的缓存接口,并需要一定的开发工作量。

    对象缓存(Object Cache

    缓存应用程序数据。

    通过 API  访问,适用面广,使用方便。

    需要一定的开发工作量。

    如需使用 Portlet  和  Servlet  缓存,需要以下步骤

    ·  在 WebSphere Application Server  管理控制台中,启动动态缓存服务,并在  Web  或者  Portlet  容器配置界面中,启动相应缓存选项。

    ·  根据规范,完成缓存策略配置文件 cachespec.xml 。该文件中一般包含缓存  id 、要缓存的  Servlet url 、缓存有效时间等等内容。

    在缓存策略配置文件中,以下一些高级属性也可以被使用:

    ·  缓存输入参数:如果某个 Servlet  的输出是由输入参数决定的(例如;查询汇率的  Servlet  输出,是由源币种、目标币种和时间三个参数决定),因此在获取缓存结果时,需要考虑当前的输入参数值。这些输入参数可以配置在策略配置文件中。

    ·  缓存失效条件:在某些场景下,缓存需要立刻失效。例如返回产品列表的 Servlet ,一旦用户在添加产品  Servlet  中作了某些操作,则需要缓存立刻失效。这些发出失效的动作,也可以配置在缓存配置文件中。

    动态缓存应用场景分析

    应用场景分析 1

    需求

    某网上商店应用访问速度过慢,经过分析,是由于产品列表和购物车处理模块由于逻辑复杂,执行效率不高引起的。

    解决方案:

    在优化相应代码外,也可以利用动态缓存机制,缓存一些常用页面的输出。动态缓存机制能够自动根据配置缓存某些页面的输出结果,这样该页面在下次访问时,Web  容器可以直接返回页面输出结果,而不用再次执行相关业务逻辑。

    需要注意的一点是,一些页面的输出内容跟当时的某些数据和环境信息相关,例如:http://www.shop.com/products.jsp?category=books  中, products.jsp  的输出就与  Category  参数决定。因此,在进行缓存定义时,需要将相应的参数作为缓存  key  定义的一部分。

    除了请求参数外,WebSphere Application Server  动态缓存的  key  定义还支持将  request  对象的属性、相应页面路径、 Session  值、 Http Head  信息、 Locale  和  Cookie

    应用场景分析 2

    需求

    假设在集群环境下的企业应用中,存在一系列 XML  格式的元数据,数据量为  100  条左右。由于该数据经常被访问,项目组希望能够通过某种措施,减少数据访问和  XML  解析的开销,进而提高系统性能。而且一旦元数据被操作员修改(例如访问  http://www.app.com/changeMetadata.jsp ),缓存内容需要立即得到更新。

    解决方案:

    在这种需求下,一种简单的做法是使用 JVM  级  static  对象来做缓存,具体做法为:定义一个  static HashMap  对象,应用程序读取数据时,首先检查该  HashMap  中是否存在缓存,如果存在,则直接从缓存中读取。在这种情况下,一些相应的缓存控制机制也必须被实现,比如缓存大小的控制、缓存过期等等。在数据被修改 时,通过修改相应的代码(如在  changeMetadata.jsp )来更新缓存内容。

    这种做法的问题在于,在集群环境中,操作员实际的访问请求是被某一个 JVM  上部署的应用所服务的。当操作员更新数据时,相应的更新代码,只会更新当前  JVM  上的缓存内容,而不会通知其他服务器,这样会导致数据不同步现象。而实现该数据同步,可能需要应用程序人员基于网络接口,开发相应的通知功能。

    而在 WebSphere Application Server  中,动态缓存服务已经支持数据复制的缓存服务,我们只需要调用相应接口即可。而由于不同层面的应用程序模块,如前台用户界面和后台业务逻辑都需要访问该元 数据,因此我们只能在动态缓存中的  Java  命令缓存和对象缓存中选择其一。鉴于应用中已经有类似的命令框架,因此无法简单的扩展该框架以使用  Java  命令缓存,因此对象缓存可以被用来解决此类问题。

    集群环境下的动态缓存应用部署

    将开发完成的应用部署到集群环境,一般有以下几步:

    ·  集群环境的安装和部署

    ·  创建复制域

    ·  启动动态缓存服务,并指定复制策略

    ·  安装应用

    注意:  只有在 WebSphere Application Server Network Deployment  版本中才支持服务器间的缓存复制。

    服务器间缓存复制策略分析

    缓存复制策略有以下几种:

    not-shared 不共享

    缓存内容不与集群中其他服务器共享。在这种模式下,缓存的数据内容可以不实现序列化接口 java.io.Serializable

    shared-push 共享 

    缓存中的数据在多台服务器之间共享,且每台服务器均存放一个复本。一旦缓存内容发生变化,会自动同步到其他服务器中。这种模式下,缓存中数据必须实现序列化接口 java.io.Serializable

    shared-pull 共享 

    缓存中的数据在多台服务器之间共享,任何一个被缓存对象在所有服务器中,存在且仅存在一份。当一个服务器读取缓存中数据时,会首先检查本地受否存在复本, 如果不存在,则会尝试从其他服务器缓存中读取该数据。如果该对象在所有服务其中都不存在,则该服务器会创建该对象。这种模式下,缓存中数据必须实现序列化 接口 java.io.Serializable 。该模式已  不建议使用

    shared-push-pull 共享  推拉

    缓存中的数据在多台服务器之间共享,任何一个被缓存对象在被创建时,会保存在本地服务器的动态缓存中,并且将缓存 id  广播到其他服务器中。一旦某个对象被请求,当前服务器会根据本地缓存信息和广播信息立刻得知被缓存对象的位置,从而完成读取工作。这种模式下,缓存中数据 必须实现序列化接口  java.io.Serializable

    如果应用中要缓存的数据量比较小,则可以采取 shared-push  方式,以空间换取性能。假如被缓存的数据对象比较大,或者服务器内存比较紧张,我们则可以考虑采用  shared-push-pull  模式。

    当我们 完成了基于对象缓存技术的应用部署步骤。我们也启动了缓存复制机制,使一台机器上的缓存改动,能够复制到所有其他机器上。

    集群

    在构建强大而灵活的可扩展 J2EE  应用程序时,您需要考虑一些相关因素。一个重要的注意事项是允许应用程序在集群环境中高效地运行。本文讨论了在  WebSphere Application Server  集群环境中设计基于  Web  的应用程序时需要考虑的事项。

    WebSphere Application Server 集群机制允许将整个应用服务器(包括  EJB  容器、 EJB Web  容器、 Web  模块和  Servlet )作为一个集群进行复制。集群提供了工作负载管理以及  URL  和  EJB  请求故障转移。各个集群成员是该集群中完全相同的副本,它们可以运行于  WebSphere  单元中的节点。集群可以位于相同或不同的节点。 Network Deployment  单元可以不包含集群、或者包含多个集群,这取决于该单元的管理需求。有关  WebSphere Application Server  集群的信息,请参见  WebSphere Application Server  联机帮助。

    集群拓扑有两种类型,垂直集群或水平集群。垂直集群在同一节点或物理计算机上具有多个集群成员。水平集群在计算单元中的很多计算机的多个节点上都具有集群成员。本文将讨论如图  所示的水平集群拓扑。


    图 1.  集群拓扑
     

    我们将讨论在设计基于 Web  的应用程序时的三个注意事项:

    ·  实现应用程序文件同步:我们将研究常用的机制是什么,以及如何利用 WebSphere Application Server 6.0  的新特性来实现它。

    ·  序列化会话对象:因为会话中包含的对象将在集群内的节点中进行同步,所以必须实现它们的 serializable  接口。本文提供了一个示例,以介绍如何强制完成这项工作。

    ·  使用动态缓存:我们将讨论如何使用 WebSphere Dynamic Cache  和  Data Replication Service  在集群中共享  Java™  对象。

    实现应用程序文件同步

    在企业应用程序的生命周期中,通常可以通过应用修复程序、添加新的 Web  内容或更新应用程序行为来对已部署的应用程序进行更新。一般来说,应用程序提供了允许用户上传在服务器端更改或创建的文件的用户界面。

    将下面的场景作为一个示例:用户希望更新 Web  站点徽标图像文件,并且将原始文件作为  .war  文件应用程序的一部分进行存档。该应用程序提供了相关的功能和用户界面,以便用户完成这项任务。然后,用户选择一个新的图像作为  Web  站点的新徽标,并且上传该文件。系统使用新的文件替换原始的文件,并且当用户再次访问他的  Web  站点时,可以看到相应的更改。在单节点环境的应用服务器中,所有这些工作都可以顺利进行。然而,在集群环境中却存在一些问题。

    在集群环境中,如图  所示, WebSphere Application Network Deployment  服务器中的  Deployment Manager  将接收到用户的上传请求,然后该请求被发送到  Node A Node A  将执行相应的业务逻辑并使用本地文件系统中的新图像文件替换原始图像文件。然而该集群中其他的成员并不清楚这项更改,其本地副本并没有得到更新。因此,该 集群中各个成员之间的这个图像文件就出现了不一致的情况。如果  Node A  因为致命错误而停机,而  Node B  接收到了该请求,那么仍将使用原始的  Web  站点徽标。看上去客户似乎丢失了他所做的更改。

    图 2.  集群环境中不一致的文件
     

    这意味着,当应用程序运行于 WebSphere Application Server  时,需要在集群成员之间同步配置文件、二进制文件和资源文件。有一种机制可以处理上述问题。解决方案是使用共享的文件系统(例如, NFS )或共享的数据 库。在这个解决方案中,所有经过更改或更新的文件都位于同一个共享文件系统或同一数据库中。对于共享的文件系统,所有应用程序都使用相同的位置,因此对于 这些应用程序来说,任何文件更改都是可见的。对于共享的数据库,应用程序可以从数据库中获得相应的更改。

    上述解决方案的缺点包括:

    ·  共享的文件系统和数据库导致一个新的单点故障。

    ·  它增加了编程和配置工作的复杂性。

    ·  它引入了一个新的性能瓶颈。

    另一个解决方案是使用细粒度 WebSphere Application Server  应用程序管理  API ,在集群的各个成员之间实现文件同步。 WebSphere 6.0  中提供了这一特性。 WebSphere 6.0  中包含许多改进,从而使得应用程序的部署更加容易并且更加高效。其中一个重要的改进是允许向系统提供部分经过更改的应用程序代码。不需要停止当前正在运行的应用程序。 WebSphere 6.0  还提供了灵活的应用程序文件管理。它允许应用程序通过以下方式进行更新:

    ·  替换整个应用程序(例如,整个 .ear  文件)。

    ·  替换、添加或删除应用程序中的单个模块(例如,.war EJB.jar  或  .rar  文件)。

    ·  替换、添加或删除单个文件。

    ·  替换、添加或删除多个文件。

    在对集群中的某个成员上的应用程序文件进行更新之后,将使用另一个新的特性 Rollout Update  对集群中各个成员的文件进行同步。它通过以下方式对应用程序进行更新:

    ·  保存更新的应用程序配置。

    ·  停止给定节点上所有的集群成员。

    ·  通过同步配置和重新启动该节点上停止的集群成员来更新该节点上的应用程序。

    让我们回到前面关于 Web  站点徽标更新的示例。在这个场景中,徽标的更新和同步对于用户来说应该是透明的,无需  WebSphere  管理员进行人工干预。这就意味着,应用程序必须控制应用程序的更新,如替换存档于  ear  文件中的原始文件,并在集群的成员之间执行文件同步。您可以通过调用  WebSphere  提供的  Java Management Extensions (JMX)  接口来完成这项任务。 JMX  是一项  Java  应用程序资源管理标准。图  显示了使用细粒度更新特性进行文件更新和同步的流程。
    图 3.  使用细粒度特性更新和同步文件
     

    应用程序在接收到用户上传的文件之后,它将调用 File Updater  以构造增量  EAR  文件。这个增量  EAR  文件是一个存档文件,它具有与完整的应用程序  ear  文件相同的结构。增量  EAR  文件和完整的应用程序  EAR  文件之间的区别在于,该增量  EAR  文件仅包含要进行更新的文件。 File Updater  将构建这个增量  EAR 。它可以是封装了增量  EAR  生成逻辑的简单  Java  类,或者是添加了验证逻辑和生成文件的相关复杂组件。

    序列化会话对象

    使用集群方式的应用程序可以提高系统的可靠性和可用性。然而,这也引入了一些挑战,如会话管理。HTTP  会话是包括用户特定信息的集合。从用户开始访问到用户最后一次访问结束的这段时间内,由容器对会话进行维护。会话由一系列的会话属性组成。事实上,这些属 性都是由系统或开发人员创建的  Java  对象。

    在集群环境中,开发人员必须清楚,HTTP  会话可能运行于多个  JVM  中。这些会话属性应该在每个  JVM  中保持一致。否则,当应用程序运行于不同的节点时,相同的输入可能产生不同的结果,这是因为与用户相关的数据在这两个节点中不一致。

    WebSphere 为集群方式的应用程序提供了实时的、完全一致的数据共享。然而,前提是必须对所有共享的属性进行序列化和反序列化。当您将  Java  对象放入到会话中并希望在所有的节点之间共享该对象时,需要将这个  Java  对象声明为一个  serializable  接口。下面的代码显示了在将对象放入到会话属性时进行的验证工作。

    public class MySession{ 

          public static void addObjectToSession(HttpServletRequest req, String key, 

          Object value) 

          { 

               HttpSession session = req.getSession(true); 

               if(value instanceof Serializable) 

                    session.setAttribute(key, value); 

               else 

                    throw new NonSerializationException (); 

          } 

          public MySession() 

          {

          } 

    }

     

    在上面的示例中,您创建了一个名为 MySession  的新类,用来将对象添加到会话中。您可以通过调用  addObjectToSession()  方法来添加它。首先应该检查该对象是否实现了  serializable  接口。如果已经实现,可以随后将这个对象添加到当前的  Http  会话中。否则,将会出现  NonSerializationException 。有些时候,在运行于另一个  JVM  中时,会话属性中包含的信息无关紧要,如文件的绝对目录。在这种情况下,通过将其声明为瞬态属性可以使得这些字段不使用集群方式。

    使用动态缓存

    如上所述,将应用程序数据保存在中央数据库中可以确保在集群环境中写入和一致地读取数据。这种解决方案的缺点是,数据库服务器引入了新的单点故障 (SPOF) ,并且不适合那些需要高性能的应用程序。另一种解决方案是使用  WebSphere Dynamic Cache  和  Data Replication Service (DRS) 。您可以在基于内存的对象缓存的方式下,通过共享整个集群中某些服务器上的对象,来实现这个解决方案。图  显示了带  Data Replication Service  的  WebSphere Dynamic Cache  的体系结构。
    图 4. WebSphere  动态缓存概述
     

    WebSphere Dynamic Cache 是面向  J2EE  体系结构和缓存对象的解决方案。表示层中  Web  服务、 Servlet  和  JSP  的输出、 WebSphere  命令类以及  Java  对象都可以使用应用程序编程接口  (API)  进行缓存,或者声明一些缓存策略并将其添加到应用程序中。

    Data Replication Service (DRS) 是用于复制数据的  WebSphere Application Server  内部组件。 DRS  使得集群中的各个服务器都可以使用会话管理、动态缓存和无状态会话  Bean  的数据。动态缓存可以利用应用服务器中的  DRS  在集群的各个服务器中复制缓存的数据。在集群范围内传输数据失效通知,以保持数据的一致性和有效性。图  显示了如何使用动态缓存和  DRS  在集群中共享应用程序数据。

    图 5.  在集群中共享对象
     

    首先,应用程序运行于 Server One ,并通过调用  DistributedMap API  将  Object A  放入其本地缓存中。通过合适的配置, DRS  可以在整个集群范围内复制缓存的对象并保持缓存数据的一致性。因此,将  Object A  复制到  Server Two  的本地缓存。当应用程序运行于  Server Two (假如  Server One  遇到问题或根据负载平衡策略将事务提交到  Server Two )时,应用程序可以从  Server Two  的本地缓存中获得  Server One  的  Object A

    WebSphere Application Server 通过使用缓存实例存储和管理缓存的  Java  对象。缓存实例还可以用于对相关的对象进行逻辑分组。特定实例的缓存中存储的对象不会受到其他缓存实例的影响。如上所述, DistributedMap  公共接口使得应用程序可以直接访问缓存实例。

    JVM性能和可靠性

    在我的讨论中,将最大堆容量超过 2GB  的任何  JVM  都视为 大型  JVM”

    64 位  JVM  是否适合您?

    IBM JVM 性能优化 中, 文章 指出:

    请记住,很多从  32  位迁移到  64  位的人并没有实现性能的优势,相反带来了更大的内存占用,因为  64  位地址所占用的空间是  32  位地址所占用空间的两倍。

    占用较大的空间就意味着计划向服务器添加更多 RAM  的可能性极大。所需的额外  RAM  的具体量将取决于您当前所使用的  RAM  量以及当前具有的可用内存的量,但最后会毫不意外地发现,最终必须在服务器上使用双倍的  RAM  才能运行与当前  32  位  JVM  具有相同堆大小的  64  位  JVM 。例如,最近的一个客户以前在  RAM  为  2GB  的系统上运行正常运行最大堆大小为  768 MB  的  32  位应用服务器  JVM ,但过渡到  64  位  JVM  时,最终需要  4GB  的  RAM  才能使用相同大小的应用服务器  JVM

    您可能会想 最大堆大小为  768 MB  的  JVM  怎么会导致进程占用内存超过  768MB  呢?这完全没有道理嘛! 堆 只是 JVM  的一个部分,另外还有解释程序;根据操作系统、 JVM  和堆大小的不同,解释程序在进程内存占用方面会在最大堆大小上增加  20%  到  50% 。因此,对于此客户,对于最大堆大小为  768 MB  的  32  位  JVM ,其硬件和软件配置所占用的内存约为  950MB ,而其对应的  64  位  JVM  所需的内存量约为  1.9GB ,而在只有  2GB  的  RAM  的情况下就没有任何内存供操作系统或系统上运行的其他进程使用。

    除了添加 RAM (或至少确保拥有  64  位  JVM  所需的足够  RAM )外,还将需要花时间调整所使用的  JDK  的垃圾回收  (GC)  算法。 IBM  为  WebSphere Application Server  开发的  J5SE  实现  (Java™ 5) (即在  Windows® Linux® AIX® iSeries®  和  System z  上运行的  J5SE) 提供了两个  GC  内存模型,缺省为 内存模型,此模型一直在  IBM  开发的  Java  实现之前的版本( JDK 1.4.x  和更早的版本)中使用;另一个模型为分代  GC  内存模型。

    考虑到性能因素,在处理大型堆时,将要使用分代 GC  内存模型(在  Sun™  和  HP  上, JDK  仅提 供分代 GC  内存模型) 此模型在 IBM JDK  上通过命令行参数设置:

    -Xgcpolicy:gencon

    之所以首选分代 GC  内存模型,是因为大型  JVM  必须尽可能减少执行  GC  的时间。在分代  GC  内存模型中,对象最初在年轻代  (young generation)  空间(通常称为 保育室 ”(nursery) )中创建,如果对象在多次  GC  操作之后仍然存在,然后会将其移动到年老代  (old generation)  空间中。另外,在分代  GC  中会涉及两种类型的  GC  操作:

    ·  小回收 (Minor Collection)  仅在年轻代中进行,这通常通过直接复制进行,因此非常高效(迅速)。

    ·  大回收 (Major Collection)  在年老代中进行,将使用通常的标记与清除算法。

    正如您可能已经猜到的,正确地确定 保育室 和年老代空间的大小是减少小回收或大回收操作所耗时间的关键;对于大型缓存的 情况,您会希望调整年老代空间的大小,以保存所有缓存内容和其他长时间存在的对象。年老代太小将会导致  GC  操作过多,甚至出现内存不足的情况。要确定年老代空间大小,最佳方法可能是在每次采用缺省模式进行  GC  操作之后查看可用堆的量(可用堆百分比乘以总堆大小)。还应该分析  GC  日志,以了解年老代空间回收的频率;最优的分代应用程序进行年老代空间回收操作的频率应该非常低。

    年轻代空间的大小通过 -Xmn (-Xmns/-Xmnx)  设置,而年老代空间的大小通过  -Xmo (-Xmos/-Xmox)  设置。

    大型保育室通常适合处理吞吐量较大的情况,而小型保育室通常能提供较短的暂停时间,而要获得较高的 WebSphere Application Server  性能(吞吐量)通常需要相当大的保育室。一种不错的做法是,从  512MB  开始,然后逐步向上或向下,以确定最优值、测定吞吐量或响应时间,并分析  GC  日志,以了解进行清除操作的频率及时间。

    ObjectGrid 是否适合您?

    如果您需要为应用服务器使用大型 JVM ,则有必要认证考虑一下  ObjectGrid 。我在前面提到过,对于此讨论,我们将任何堆大小为  2 GB  及更高的  JVM  都视为 大型 ”JVM 。这并不是说要从  ObjectGrid  获益就需要使用大型堆,远不是这个意思。任何大小的缓存都可以帮助提高性能和吞吐量,但是  ObjectGrid  能够存储大量数据,而且使用  32  位  JVM ,这就使其成为了一个非常理想的方案,不用过渡到相关内存开销大的  64  位  JVM

    正如前面提到的,ObjectGrid  属于  WebSphere Extended Deployment (而且作为  Data Grid  单独提供)。如果您对其不了解,在此我对此作一下极为简单的介绍: ObjectGrid  是用于  Java  应用程序的启用了网格的灵活内存数据存储,提供了一系列部署和编程选项。最简单的选项是,将其作为内存内数据库使用,或作为  Java Platform Standard Edition (Java SE)  或  Java Platform Enterprise Edition (Java EE)  应用程序的缓存使用。每个  ObjectGrid  都由一个或多个映射组成,而每个映射又由一组键值对组成。在本讨论中,特别有意义的是两项  ObjectGrid  功能:

    ObjectGrid 可以通过使用静态集群或动态集群采用客户机 - 服务器部署模型部署。动态集群使用目录服务来维护服务进程  JVM  列表, ObjectGrid  应用程序容器就承载在其中。目录服务为  ObjectGrid  部署提供多项服务(位置服务、放置服务、运行状况监视以及管理访问)。反过来,客户机可以与这些  ObjectGrid  服务器交互,以访问缓存内容(图  1) ,而这样又允许应用服务器 客户机 将缓存的主要内容分流到其他进程,而且同时仍然将访问最频繁的数据保存在本地缓存中。
    图 1.  采用客户机 - 服务器部署模型部署的  ObjectGrid

    ObjectGrid 能够跨多个  ObjectGrid JVM  对映射进行自动分区,此功能是维护大量数据的关键:将数据分散在多个  ObjectGrid  服务器上,每个服务器都在  32  位  JVM  中运行,而且没有  64  位  JVM  的巨大的内存开销。此外, ObjectGrid  还提供数据复制功能,消除了由于单个服务器而造成单点故障的情况。图  显示了分区和复制功能的情况。这些功能对于考虑将  ObjectGrid  作为  64  位  JVM  的企业级替代方案时非常重要。
    图 2. ObjectGrid  跨多个  JVM  对映射进行分区

    创建 ObjectGrid  集群的能力取决于应用程序客户机,而此能力支持在应用程序客户机之外部署  ObjectGrid  服务器层,如图  中所示。尽管图中显示了多种应用程序客户机类型,但在本文的讨论中,客户机将为  WebSphere Application Server ,此客户机将不再需要各自维护缓存的副本。而这将消除将应用服务器作为  64  位  JVM  运行的需求。此外,跨多个  ObjectGrid  服务器实例对  ObjectGrid  映射中的数据进行分区的能力可以作为  32  位  JVM  实现,而且每个服务器可存储的缓存内容量可达  4GB (总缓存量大得多)。这样可以节约大量的  RAM ,因为  32  位  JVM  并不会带来  64  位地址所带来的内存开销,每个应用服务器都不再需要维护整个缓存的副本(尽管可以在需要的情况下维护本地缓存)。

    图 3. ObjectGrid  集群
     
    对于当前维护大型缓存的应用程序,迁移到基于 ObjectGrid  的解决方案应该非常简单,因为  ObjectGrid ObjectMap API  与现有的基于映射的标准  API (如  HashMap )非常相似。应用程序流通常可以采用任何缓存实现模式。实际上,使用  ObjectGrid  时,应用程序将按照以下顺序操作:

    开始 ObjectGrid  会话。

    获取 ObjectMap

    将数据放入 ObjectMap

    提交会话。

    ObjectMap 是应用程序本地的映射,也就是说,映射存在于应用程序运行所在的堆空间中。当应用程序将数据放入  ObjectMap  中时,数据放置在本地堆中。应用程序提交会话时, ObjectGrid  会将数据复制到  BackingMap  中。 BackingMap  属于基于  ObjectMap  的  API  集,驻留在  ObjectGrid  服务器(例如,容器服务器)的堆空间中,其中包含所提交的数据。通过将数据提交到  BackingMap ,应用程序可将数据提供给其他应用程序(或者,如果应用程序在并发环境中运行,则为其他应用程序线程)访问。最重要的是,与很多其他 分布式缓存解决方案不同, ObjectGrid  集群的配置以及服务质量(如同步或异步复制、按 区域 的重复放置、分区的数量等)都由数个  XML  属性文件进行控制,而这些属性文件可以方便地根据需要进行更改

    缓存之外的应用

    或许您需要大型 JVM  的原因并不是因为应用程序缓存,而是需要处理大量  HTTP  服务器对象或大型  HTTP  会话对象,因为  HTTP  经常作为隐式应用程序缓存使用。 ObjectGrid  提供了用于通过  Servlet  筛选器分流  HTTP  会话数据的内置机制。 Servlet  筛选器以  J2EE EAR  文件的形式为应用程序提供  ObjectGrid HTTP  会话管理器,而且通过  addObjectGridFilter  脚本采用管理方式添加,此脚本以  Servlet  上下文初始化参数的形式向  Web  应用程序添加相应筛选器声明和配置 —— 而不用进行任何应用程序更改。图  中显示了使用  ObjectGridFilter  为  HTTP  会话数据部署的应用程序。

    图 4.  使用  ObjectGridFilter
     
     

    通过这种方式使用 32  位  JVM  分流  HTTP  会话,同样可以通过避免  64  位寻址的开销而节约大量的内存。

    DynaCache 和  Distributed Map

    我并没有忘记这两项,不过对于需要大型应用程序服务器堆的情况,DynaCache  和  Distributed Map  都没有提供  64  位  JVM  的替代方案。 DynaCache  是  WebSphere Application Server  的功能,可缓存  Servlet JSP Web  服务和  WebSphere Application Server  命令生成的结果,而  Distributed Map  提供用于在  WebSphere Application Server  实例中创建本地或远程缓存的  API 。由于这些  API  都依赖于  WebSphere Application Server  运行时,因此缺少将缓存分流到独立缓存层的能力。因此,它们并不提供使用  64  位  JVM  保存缓存数据运行应用服务器的替代方案。虽然  Distributed Map  提供了磁盘分流(可以用于将缓存的大小限制为在  32  位磁盘空间内),但通过这种方式进行分流带来了在磁盘上写入和检索数据的延迟,其性能可能不为某些时间敏感的应用程序所接受。此外,正如我们提到 的, DynaCache  特定于应用程序构件生成的输出,因此没有用于检索底层应用程序数据用于其他用途的机制。

    安全

    对于网络方面的安全问题,不同的开发者和设计者有不同的认识和见解, 我试图采用 和《 JAVA  探索者: JAAS  和  JSSE  的  JAVA  安全》相同的分类方法,将  Web  系统的安全问题分为三个类别:认证、授权和传输。认证和授权是任何一个应用系统中的基本安全问题,认证过程是首先通过各种形式的认证表单或途径获得使用者 认证数据,然后根据认证数据确定对方身份的过程,对于  Web  认证安全数据提交形式包括普通表单、证书等;授权过程则是对确认了的认证身份的主体进行判断的过程,判断认证了的主体是否有对客体实施某种操作的权限;相 对于传统的  C/S  应用系统, Web  应用系统采用  B/S  结构, B/S  得以广泛使用和迅速发展很大程度上依赖于其瘦客户端的标准化脚本解析和传输的标准化,然而标准化的  HTTP  协议传输方式一方面使得开发网络应用快速而简单,另一方面  HTTP  协议的网络传输问题也暴露很明显,因此传输过程中的安全问题成为亟待解决的  Web  三大安全问题之一。

    图 1.  网络安全问题
     
     

    上图  详细刻画了  Web  安全三个方面的问题,三者之间的关系可以表述如下:

    首先,服务器端需要确认客户端用户的身份;其次,当客户端请求访问服务器端某一受限的访问资源时,服务器端需要根据客户端提交的身份确认其 是否有足够的权限访问该受限资源;最后,客户端和服务器端的交互访问方式需要通过网络完成,传输过程中的数据可能被非法获取、篡改,当然也存在不能确认传 输双方的身份等问题。

    WebSphere Application Server WAS )结合的计算机安全近  40  年的成果,在网络安全、操作系统安全、 J2EE  安全等方面提供了坚如磐石般的安全体系的同时,还保持了极其灵活的特点,成为  Web  领域解决方案的重要利器。本文接下来的章节,将从以上描述的三个方面为出发点,对  WAS  安全机制进行概述,包括  WAS  整体安全架构和各个层次上的安全解决方案。由于每个层次上的安全问题都是一个安全领域独特的知识,本文对每个层次的安全方案进行简介,并探讨其与其它层次 之间的关系。更深入的讨论将在本系列文章的其它文章中进行阐述。

    WAS 安全体系架构

    对于 WAS  的管理,常用的管理方式包括管理控制台、 JMX Java JNDI  等, 管理内容相应的包括命名、用户注册表、 JMX  管理资源以及常见的  Web  资源,包括  Html JSP Servlet  等,按照上一节中对于  Web  中安全的阐述的观点,这些资源为受保护的服务器资源,而对于这些资源的访问控制则为  Web  安全的管理对象,在图  中统称为  WAS  资源,在本节下面的篇章将依次介绍各个安全层次对于这些受保护资源控制。

    图 2.  自底向上的安全体系结构
     
     

    从安全技术使用范畴的角度,将 WAS  的安全体系结构自底向上的划分方式分为,平台安全、 Java  安全、 WAS  安全,详细的架构体系层次关系如图  所示。

    平台安全 包括两部分,即操作系统安全和网络安全。网络安全解决网络传输中的安全问题,包括网络传输中的 完整性交验,机密性保证等网络传输中存在的问题,在 WAS  中通常通过配置对  SSL  和  VPN  安全配置解决传输中的安全问题。对于操作系统层次上的安全,除了通常意义上的依赖于不同的平台本身的安全特点,对于  WAS  文件系统和进程等进行的安全访问控制, WAS  提供了基于操作系统帐户的  WAS  安全控制管理,大大提高了  WAS  的安全管理的便捷性和易用性;此外在不同的操作系统平台上,提供了具有平台相关性的安全特点,在影响着  WAS  的安全管理。

    对于网络安全中的 SSL  安全和操作系统上的安全机制在以后的篇章中将进行介绍。

    JAVA 安全 ,由于 WAS  是  J2EE  认证服务器,因此  WAS  遵从  JSR  社区的  JAVA  安全规范,从  JDK  到  Java2  安全体系结构, JAAS ,再到  J2EE  安全模型等等,因此  JAVA  中的安全管理也适用于  WAS  中。对于  Web  安全的三个问题中的认证与授权,《  JAVA  探索者: JAAS  和  JSSE  的  JAVA  安全》认为, JAVA2  安全体系结构主要解决授权问题,而  JAAS  主要解决认证问题。 J2EE  也提供了  class  级别的安全授权模型,并提供了对上层的  J2EE  资源的安全管理规范,因此对于  Web  的安全认证与授权问题本文主要介绍  Java2  安全体系结构、 JAAS  和类级别的安全授权模型。

    对于这一层次的安全本文着重于 JAVA2  安全架构、 JAAS  和  J2EE  安全角色三个安全层次的介绍,这三个安全层次的安全策略为属不同的领域,可以相互补充使用,本文在其后章节予以介绍。

    WAS 安全: 对于图  中  WAS  安全层上的安全主要是强制使用统一的安全访问控制方式对  Web  资源、企业  Bean  和  JMX  管理资源。可以理解为对于  WAS  服务器资源的访问时, WAS  安全层强制自顶向下依次调用安全架构中各安全层次进行访问控制,从而保证了任何一种资源的访问都采用了统一的完整的安全控制,此外配备了对于不同的安全层 次的管理具体控制选项设置,这些设置可以被运用于管理当中。在访问控制内容上,安全访问控制的内容包括  JMX Bean Web  资源等;在访问控制方式上则包括, JMX  访问、控制台、 WSadmin 、纯  JAVA  的  JNDI  访问等等;在访问控制的层次上,则对于不同的访问方式, WAS  安全提供了从传输到上层的用户角色等的自底向上的访问控制方式 。

    从上下层的关系看,WAS  提供了自底向上的安全管理模型,在实际的应用中,使用者可以根据具体需求对安全层次的选取进行设定和管理,图  所示的为在  WAS  管理控制台中对于不同层次安全的管理控制设置,如  Administrative Security  中则主要应用  J2EE  角色安全的方式进行控制; Java2 Security  则是  JAVA2  安全体系; User Account Repository  则可选操作系统安全或者其他安全方式; Java Authentication and Authorization Service  为  JAVA  安全层次中的认证机制。

    从 Web  安全三大问题的角度看,如图  介绍,对于  Web  安全授权分别由  JAVA  安全层次中的  J2EE  安全模型,  Java2  安全模型来完成;对于  Web  认证则由操作系统用户认证方式、 JAAS  认证模型,以及  WAS  统一的  LTPA  等的认证机制;而对于  Web  传输则主要由图  中展示的  SSL  传输安全机制来完成。

    图 3. WAS  中的安全认证与授权
     
     
    图 4. WAS  中传输安全
     
     

    WAS 安全体系中各层次安全简介

    在本章中将分小节对三个安全层次中的主要安全领域问题进行重点介绍,主要介绍内容包括,平台安全中的操作系统安全和网络;JAVA  安全中的  JAVA2  安全、 J2EE  角色安全和  JAAS  安全。

    SSL 安全介绍

    SSL 安全属于  WAS  安全体系中的平台安全层, 在  WAS  中,对于网络传输安全主要采用的是  SSL  协议,在  WAS  安全控制启动后,不论以  Web  控制台方式、 JMX  方式访问  MBean  还是对于  wsadmin  方式管理  WAS ,启动的访问进程都必须遵从  SSL  协议进行通信。

    对于浏览器访问 WAS  管理控制台的方式, WAS  会完成自动跳转,启用  Https  协议进行传输;对于  wsadmin  和  JMX  则在正常的管理控制用户认证开始前进行  SSL  的握手过程,握手过程完成后,整个交互过程采用  SSL  握手时建立的安全通道进行通信。

    SSL Secure Socket Layer )即安全套接字协议, SSL  协议结合了对称加密算法和非对称加密算法进行传输过程中的数据加密、解密,保障了数据传输过程中通信双方的身份认证、数据的机密性和完整性等问题。

    对称加密算法是较为最为经典且古老的加密算法,这一加密算法最大的特点是在实际的加密、解密过程中,加密、解密运算互为逆运算,这两个运算 过程中用到的密钥相同,这一过程可用图  予以解释。由于对称加密算法要求通信双方使用相同的密钥并约定加密算法,因此在实际的网络传输应用中对称加密算法面临着密钥传输和算法约定等问题,降低了 这种加密算法使用的可用性。但是这种经典的加密算法执行效率高,加密快。

    图 5.  对称加密算法
     
     

    非对称加密算法也称作公钥加密算法包含一对密钥,分别称作公钥和私钥,在加密和解密过程中,这对密钥互为反运算的密钥,即假设用公钥对明文 进行加密的密文,则只能用私钥密钥进行解密得到明文,非对称密钥的这一特性可以用图  予以解释。在实际的运用中,非对称加密算法的这种特性得到了很好的运用,将公钥公布、私钥个人保留,解决了传输网络过程中的身份认证问题,同时解决了公钥 的物理传输问题,不足之处在于非对称加密算法较为复杂,计算过程较慢,效率不及对称加密。

    图 6.  非对称加密算法
     
     

    基于这两种算法的特点,SSL  协议的安全网络传输协议应运而生,利用非对称加密解决身份认证问题、密钥传输、算法协商等问题,这一过程也称作握手过程,握手过程结束后,通信双方得到了 协商好的对称加密算法和加密钥,从而建立了一条安全的通信信道;安全的通信信道建立成功后正常的通信过程开始进行,这一过程中通信双方的请求与应答内容都 采用对称加密算法完成后进行网络传输。

    在 WAS  管理过程中, WAS  服务器强制客户端(浏览器或者  JAVA  程序)与  WAS  服务器采用  SSL  协议进行安全通信,当然这一过程中涉及了网络传输安全中的认证授权、机密性、完整性以及不可否认性,采用的算法除了本节所讨论的对称加密算法和非对称加密 算法外还采用了不可逆加密算法,对于非对称加密算法引入了证书和证书授权机构等概念,这些不在本文进行阐述,将会在以后篇章中进行较为详细的阐述,并结合  WAS  对于证书和算法的管理进行阐述。

    操作系统安全

    操作系统安全也属于 WAS  安全层次的平台安全层,作为底层操作系统为  WAS  提供了安全基础设施,操作系统定义并管理着后台启动的任务,建立启动概要文件,并是访问底层的基础系统资源例如文件、安全套接字等的基本设施。除此之外, 底层操作系统为  WAS  提供了可信的认证服务用户注册表,这一部分内容将在本文后边的章节有所介绍。对于授权服务,本地底层操作系统提供了  SAF System Authorization Facility )服务为运行在  WAS  内的控制台、应用程序等提供了授权服务,

    由此可以看出对于 WAS  的运行管理,甚至于  WAS  使用时的认证授权都必须协调操作系统的安全配置管理来完成,例如对于使用本地操作系统的用户注册表时候,则需要登录用户或者启用用户具有相应得操作系统的 一定的管理权限来完成,否则会造成  WAS  不能正常运行,进而应用程序不能正常运行,因此对于  WAS  的管理一部分工作实际上是对于操作系统的管理工作。

    对于 WAS  的管理在不同的情况下可能需要本地受限用户进行管理工作,因此对于本地受限用户操作  WAS  的管理工作就涉及到操作系统的限制和  WAS  的限制,充分了解操作系统的安全认证、与授权是管理  WAS  安全工作的一部分。从某种程度上讲,操作系统安全在  WAS  整个安全管理体系中相当于为其他安全和  WAS  本身的正常运转创造一个正常有序、合理安全的运行环境,而维系这中正常的运行环境在以  WAS  启动、运行、停止为周期过程为基本指导原则的,在充分考虑  WAS  运行声明周期中各个环节的安全特性,结合操作系统的安全认证、与授权的特点的前提下来最终完成。

    JAVA 2 安全架构及在  WAS  中应用

    JAVA2 安全属于  WAS  安全架构中的  JAVA  安全层上, JAVA  语言发展迅速除了其本身的面向对象的强大特点之外,其坚如磐石的架构设计理念也不容忽视的,强大的安全设计架构使其能够适用于企业级安全需求。 JAVA  的安全模型主要保护功能是保证系统资源不被非法程序所接触,这些系统资源包括文件、网络等资源,与此同时提供较为完善的访问控制模型使得得到授权的程序可 以正确访问资源,因此《  J2EE  探索者》的观点认为  JAVA2  在  Web  应用安全中解决授权问题的。

    JAVA2 安全架构模型相对于  JAVA1  安全模型提供了更为强大的安全管理模型,如图  所示的  JAVA2  与  JAVA1  的安全对比模型。 JAVA1  的安全模型认为本地程序是安全程序可以自由的通过  JVM  访问受限的系统资源,而对于远程程序则要对远程程序进行签名验证,可信签名的程序可以和本地程序一样正确访问本地资源,而对于没有得到认证或者没有签名的 程序则会进入沙箱进行运行,进入沙箱的程序对本地资源访问受限,只能运行普通功能。

    图 7. Java1  安全模型和  Java2  安全模型
     
     

    JAVA2 安全模型在对程序可信方面做了调整。对于本地程序同样要进行签名验证和管理,对于不可信的本地的资源同样进行首先控制,使得本地非法程序仍旧不能访问本地资源。

    JAVA2 提供了更为灵活的安全控制模型,开发者可以通过定制安全策略、安全类装载器从而保证了开发人员可以动态定制开发出更为灵活的安全管理架构。比如开发出使用时间受限的应用程序。

    JAVA2 提供了更多的域概念,除了可信和进入沙箱的程序, JAVA2  安全模型提供了更为细分的安全域,不同的应用程序根据不同的应用签名和安全策略制定相适应的安全域, JVM  通过调度使得应用程序进入进入相应的安全域访问受到约束的部分本地资源,在保证了安全前提下,提供了更为细分的权限分配,满足了对于企业级应用的安全需 求。

    从可信任层次上看, JAVA2  安全模型认为可信的  JAVA  代码是  JVM  本身的  JAVA  代码;从控制方式的角度来看, JAVA2  安全模型以交验  JAVA  代码的运行路径、 JAVA  代码本身的签名,因此  JAVA2  模型更多强调代码的所有权,从而保证系统的安全性。

    基于 J2EE  角色安全介绍

    J2EE 安全属于  WAS  安全架构中的  JAVA  安全层上。 J2EE  提供了基于角色的安全授权控制模型,基于角色的安全授权模型主要是提供基于角色的安全控制检查,确保只有足够权限的安全角色能访问相应的受限资源。角色是 一组权限的逻辑集合,这组逻辑集合可以被赋予真实用户注册表环境中一个或者多个合法用户或者组,在系统程序运行时,通过检查某一个真实用户所属的角色或者 真实用户组所属的角色来完成相应的安全检查。

    对于授权检查方式上,J2EE  提供了声明型和程序型授权性安全检查策略,由于  J2EE  的安全保护对象为  J2EE  资源,因此声明型的授权模式对不同的保护资源通过不同的声明文件进行控制,常用的  J2EE  资源一般通过  web.xml 进 行控制,控制的标签为 <security-role-ref>  和  <security-role-ref>  等协作完成,对于  EJB  的控制则通过配置  ejb-jar.xml  来完成,通过这种配置方式从而达到保护指定的受限资源的目的。

    值得一提的是 WAS  本身控制台的安全管理角色授权机制就是基于  J2EE  的安全模型管理机制的,如表  中所示,列出的为基本的  WAS  控制台角色以及相应的权限,这些用户角色可以根据不同的真实用户注册表情况映射到不同的用户和用户组。

    表 1. WAS  控制台的角色
     

    角色

    权限

    监视员

    监视员可以查看 WAS  中的各种配置信息,运行状态,但是不能做任何更改

    操作员

    操作员可以触发运行时状态改变,例如启动、停止服务器,但是不能做任何配置的改变

    配置员

    配置员可以修改配置信息,但是不能更改运行状态。

    管理员

    管理员具有操作员和配置员的权限,除此之外还能修改敏感的安全配置信息和服务器安全策略等,例如服务器 ID  和密码,启动和禁用管理安全, JAVA2  安全等等。

    除了 WAS  控制台使用安全角色模型,正常的  J2EE  应用自然适用于这种安全控制模型。如图  所示,该应用中定义了  个角色, WAS  提供了机制对这些在应用中预定义的角色从用户注册表里进行分配管理,通过应用程序预定义抽象的角色,在实际应用中对这些抽象的角色进行用户分配,大大提高 了应用的灵活性。

    应用程序在实际的运行过程中通过声明型和程序型管理方式直接或间接操纵这些抽象对象,这部分安全管理工作可以通过声明的方式进行管理,这样 WAS  可以来处理这部分角色级别的安全认证、授权管理;当然有时候基于角色不能解决实际问题,那么需要更为灵活的程序型安全授权管理方式, J2EE  资源可以直接操纵这些委托  WAS  容器进行认证的用户。

    对于 Servlets

    isUserInRole() 用来检查登录用户是不是在某个角色中。

    getUserPrincipal() 用来得到登录用户实例,通过实例可以获得姓名等。

    对于 EJBs

    isCallerInRole() 用来检查登录用户是不是属于某个角色。

    getCallerPrincipal() 用来得到登录用户实例,通过操纵实例完成相应的动作。

    图 8.  应用的安全模型角色
     
     

    基于 JAAS  安全认证介绍

    JAAS 属于  WAS  安全架构中的  JAVA  安全架构层上,全称  Java TM Authentication and Authorization Service JAVA  认证与授权服务,故名思义用来解决安全认证与授权的问题。

    PAM Pluggable Authentication Module )可插拔认证模块,PAM  是一种认证授权框架,这种框架提供了一种认证机制,使得上层业务应用程序的开发使用不依赖于底层的认证授权机制, JAAS  正是  PAM  的  JAVA  版应用框架。

    JAAS 的认证机制是通过检查  JAVA  代码的执行者身份,这些  JAVA  代码包括  Servlet

    、应用程序、Applet  等等; JAAS  的授权机制主要是用来检查并确保执行者有足够权限进行相应的动作, JAAS  可插拔认证模型关系如图  所示。

    图 9. JAAS  可插拔认证模型
     
     

    根据 JAAS  的运行机理,本文将  JAAS  的认证授权模型分为四个层次,自上向下依次为应用层、授权层、通用认证对象层、认证层。由于授权层是外部和内部结合的控制方式,因此跟上层业务应用程序本 身之间没有直接的耦合与调用关系,按照分层架构模型设计原理,在运行时,授权层通过访问安全控制策略只能访问通用认证对象模型,而通用对象层的认证对象凭 证是在运行势态动态生成的,跟底层的认证层没有依赖关系,因此上层应用对底层也没有依赖关系,从而达到了上层商业业务逻辑和下层认证模块之间没有直接耦合 的关系。

    JAAS 机制与  JAVA2  安全模型相比,两者解决不同的问题,面向的侧重点不同。从保护对象角度来看, JAVA2  安全模型提供内嵌的系统资源保护模型,当然开发者可以开发更多的面向业务的保护对象,而对于  JAAS  则提供更灵活的认证授权控制,除了保护业务对象,也可以面向业务操作进行保护;从授权检查机制的角度, JAVA2  安全模型更多强调安全代码的所有权,而  JAAS  则强调的是代码的使用权;从检查形式来看, JAVA2  的安全模型属于声明型的管理模式,而  JAAS  的管理模型可以声明型和程序型相结合;从安全检查级别来看, JAVA2  安全模型属于角色级别的检查控制,而  JAAS  可以提供基于角色和基于实例的安全授权控制。因此两种安全认证模型可以结合使用,保证更为安全和灵活的管理控制。

    WAS 开放认证授权架构介绍

    前面介绍了 WAS  安全架构中的自底向上的安全层次,不同的安全层次有着不同的安全管理控制方式,然而这些安全层次之间如何交互,则需要从交互关系来看。 WAS  的开放认证授权架构如图  10  所示,在一个  WAS  中对于认证、授权是相应的  Security Server  和  Access Manager  两个模块来完成的,而其中对于认证模块又包括两部分  JAAS  登录和  User  注册表两部分组成,因此常规的安全登录实际过程是首先采用某种机制通过  JAAS  登录模块进行登录认证, JAAS  登录模块利用得到用户登录数据到相应的选定的用户注册表里进行验证。从而完成相应的认证工作,当然对用户进行一系列的映射动作,完成映射动作后用户如果要 访问相应的受限访问资源,则  WAS  对其角色进行验证,从而完成授权检查等动作。

    图 10. WAS  开放认证授权架构
     
      对于 JAAS  的常规实现是每个  JAAS  是一个认证方式,从而保证了业务高层和登录模块的分离,因此大部分的认证实现直接完成了对于某一个用户注册表的认证。而  WAS  对于这一问题进行了较为灵活的设计,对于每一种  JAAS  登录模块都是一种登录机制和映射机制,每种登录机制会控制登录的  Cookie/taken  等的格式,以及多个  WAS  间共享登录信息的格式等等,这些机制对于各种登录机制是不同的,但是对于同一个用户注册表管理方式可能会使用同一种登录机制。因此  WAS  的灵活认证架构设计在对于认证机制和用户注册表之间采用桥模式进行设计,如图  11  所示,保证了认证机制和用户注册表的选取之间的组合方式。

    图 11.  灵活的  WAS  认证机制
     
    WAS 安全体系的认证机制

    认证在 Web  安全中主要解决是谁的问题,而对于授权则是解决有没有权限进行某种操作的问题,如图  12  所示,对于  WAS  中的认证与授权之间的关系, WAS  作为  Web  容器,是应用程序运行的管理和调度者,对于应用程序的认证则不能局限于  WAS  本身内部,因此对于认证问题委托给了用户注册表。同样对于授权方式,每个应用程序有着不同的授权方式,对于声明型的授权管理工作, WAS  通过读去应用程序的授权声明进行调度和监控;对于程序型的授权管理,应用程序通过与  WAS  进行交互得到登录用户的信息,进行授权管理。因此应用程序对于授权工作都要最终依托于相应的应用程序进行授权工作, WAS  作为容器提供管理和调度交互工作,最终的认证与授权的方式和具体内容细节则交由应用程序来管理和控制,一方面降低了开发难度,对于应用程序保证自底向上的 安全性的开发工作是复杂和庞大的;另一方面在使用  WAS  提供强大的安全控制时保证了安全性的同时,提高了开发效率。

    图 12. WAS  中的认证授权
     
     

    在 WAS  中的具体认证过程如图  13  所示, Web  客户端在得到服务器认证响应后进行认证数据提交,对于认证数据提交的方式一般的包括三种形式, Http  基本认证、 Https  客户端认证和自定义表单认证,一般的自定义表单认证具有自定义的界面,因此这种模式适用的比较多。

    认证数据同过网络传输到服务器,根据前一节对于 WAS  认证架构的认识与了解, WAS  会使用一种在服务器中选定的认证机制进行认证管理,认证数据通过认证机制进行一定的处理提交到用户注册表进行验证,认证后的认证凭证存在  WAS  对于  JAAS  的扩展中,在登录用户访问需要进行授权时即从凭证中取得相应信息进行授权管理。

    对于 WAS7  中使用比较多的是  LTPA  认证机制, LTPA(Light Weight Third Party Authentication)  第三方轻量级认证,对于  SWAM  则将在以后的版本中放弃使用。

    对于用户注册表,目前支持的主要为四种类型。本地操作系统,如果用户选择本地操作系统的认证方式,那么用户需要有本地用户才能成功进行认 证,对于 Windows  的域环境,这种管理方式更是有其绝对优势,一方面对于任何本地用户不用分配额外的帐号易于使用和管理;另一方面由于不使用额外帐号,对于授权了访问操作系 统的本地用户,直接可以访问应用程序降低了管理成本。 LDAP  轻量级目录访问协议,通过  LDAP  的控制管理方式,保证了对于  LDAP  应用企业的应用的兼容性,大大改善了以往应用程序对于  LDAP  支持的难度。联合用户注册表提供了一种多种存储方式并存的管理模式,大大改善了对于多用用户注册表并存系统的集成和兼容。最后一种用户注册表是自定义注册 表,对于任何一个应用,如果前面三种用户注册表策略仍旧不能满足相应的需求,用户可以通过自定义注册表的方式,和系统中已有或者新开发的登录机制相结合完 成特殊的登录认证需要。

    图 13. WAS  中的认证过程
     
    WAS 安全体系的授权机制

    授权主要是用来满足对于受限资源的访问控制问题,如图 14  所示的授权管理工作,当用户需要对受限资源进行某种操作时,操作请求信息会发送到  WAS  服务器中,根据上一节中所介绍的  WAS  服务器通过认证进程对用户信息进行管理和控制,如果用户没有进行认证,则按照上一节中讨论的方式进行认证管理,认证后得到用户认证凭证,用户认证凭证和请 求操作被转发到相应的授权管理进程,授权管理进程将用户认证凭证和请求的操作通过授权矩阵进行评估,从而判断用户是否有权限进行请求的操作。

    图 14.  授权逻辑视图
     
    对于基于 WAS  的应用程序的授权管理工作,依照上一节中介绍的观点, WAS  直接或者间接的委托于应用程序, WAS  在其中进行管理、协调和监控, WAS  对于授权管理工作遵守  J2EE  授权的管理模型,即基于角色的授权声明性授权管理和更为灵活的程序性授权相结合。那么对于授权的实施过程可以参考图  15  所示。

    如图 15  所示的为从安装、使用的自左向右的顺序,但是先开发后进行安装部署的角度,则是从右到左的顺序。按照  J2EE  安全授权模型的设计思想,首先对于应用程序抽象出用户角色,然后对于抽象的用户角色进行声明性和程序性授权控制,因此程序具有很强的健壮性和兼容性,不依 赖于任何某种用户注册表,进行合理的配置可以应用于不同的用户注册表以满足不同注册表用户对于程序需求。对于部署阶段则是映射实际的用户到  J2EE  中定义的用户角色,依照  J2EE  安全授权模型的定义,用户角色实际上是一组权限的逻辑集合,这些集合可以是一个用户或者是一个用户组,因此对于映射工作实际上是角色的认定过程。

    因此对于一个应用程序从开发到实际的运行环境需要至少需要经过开发和部署两个阶段,开发阶段应用程序对抽象用户角色进行依赖与交互,而对于 部署阶段则是将开发阶段预定义好的用户角色实际运行环境中的用户注册表进行映射,在完成了基于抽象用户角色的用户权限控制开发和抽象用户角色到实际用户注 册表中的映射部署才最终完成了应用程序的授权过程。

    图 15.  授权实施
     

    重难点分析

    时间有限不作分析。

     

    1.  业务系统的架构分析需要深入的剖析,这个准备工作要早,对于项目管理人员来说,如何更早的知道这个系统的预期架构的全貌是重点。

    2.  Edge server的集群和 F5 设备的 PoC 测试中集群搭建的重点,动态扩展方面是项目经理在性价比上进行讨论的重点。

    3.  缓存设计是难点,难度在于如何降低开发人员的难度但同时不失缓存特性的优势。

    4.  WAS和同一层的 WVE MQ WPS 等集成是一个重点。

    5.  系统全局后的应用架构环境测试是一个耗时长的重点,需反复修正达到3 个要求,完全可用,高性能, webservices 高效。

    6.  运维监控匹配的IBM Tivoli 其他产品比较庞大,需专业匹配。

    7.  数据库层面的性能问题不能简单处理,可用性也不能单纯依赖RAC 来做,可以结合用户系统情况,充分利用 Oracle11g 中的新一代高可用性技术以及 RAT 来验证。需专业 DBA

    展开全文
  • 对象关系映射(Object/Relation Mapping)提供了概念性的、易于理解的模型化数据的方法。ORM方法论基于三个核心原则: 简单:以最基本的形式建模数据。 传达性:数据库结构被任何人都能理解的语言文档化。 精确性:...
  • 对象关系映射(Object Relational Mapping,简称ORM)是一种为了解决面向对象关系数据库存在的互不匹配的现象的技术。 简单的说,ORM是通过使用描述对象和数据库之间映射的元数据,将java程序中的对象自动持久化到...
  • C++-面向对象编程-000-面向对象

    千次阅读 2020-03-16 19:14:28
    C+±面向对象编程-000-2020-3-16
  • 上一篇文章说到在LotusScript编写类时采用继承有两类情况,接下来的几篇文章介绍的就是其中的一种:为了重用代码。将Notes数据导出到Excel就是展现这类继承的一个很好场合。 微软的Excel有很多方便有用的处理数据的...
  • 第八章 公共政策的评估与监控

    千次阅读 2019-03-14 14:52:21
    第一节 公共政策评估的作用、主体与类型 第二节 公共政策评估的过程、标准与影响因素 第三节 公共政策评估的方法 第四节 公共政策监控第一节 公共政策评估的作用、主体与类型 一、公共政策评估 公共政策评估的含义:...
  • Python面向对象理解

    万次阅读 多人点赞 2018-06-18 18:44:18
    一,初始面向对象.面向过程的程序设计的核心是过程(流水线式思维),过程即解决问题的步骤,面向过程的设计就好比精心设计好一条流水线,考虑周全什么时候处理什么东西。优点是:极大的降低了写程序的复杂度,只需要...
  • 公司主要关注的领域包括公共安全、智能交通、金融安防等,同时公司在无人驾驶、机器人和智能医疗方面也进行了深入的布局。 官网:http://www.deepglint.com/ 26、公子小白     总部:深圳 ...
  • 10-python程序员,面向对象基础

    万次阅读 多人点赞 2020-09-11 22:58:15
    《python小白入门系列教程》 有对象吗? 没有就new 一个 ...**缺点是:**一套流水线或者流程就是用来解决一个问题,代码牵一发而动全身。 **应用场景:**一旦完成基本很少改变的场景,著名的例子有Linux內核,gi
  • C#三十五 三层架构企业应用

    千次阅读 2016-05-29 19:37:30
    企业中这种职责分离、业务独立的部门划分方法对于管理企业有很大的好处,同样在程序中也需采用“职责分离、业务独立的”的原则划分模块,更好的实现“高内聚、低耦合”的软件设计思想。   1.2为什么要使用...
  • 因此,在Zachman的EA框架基础上,需要对企业架构框架进行重构,主要叠加人、物、事的行为,进而提出智慧企业架构框架SEAF,并就智慧企业架构框架进行概括性阐述,不涉及实现SEAF的方法论,供企业架构专家讨论,...
  • 如何理解Python中的面向对象

    万次阅读 2020-02-16 16:22:27
    一、认识面试对象是什么 面向过程的程序设计的核心就是过程,就是流水线式的思维,过程就是解决问题的步骤,面向过程的设计就好像一条设计好的流水线,考虑周全什么就处理什么东西。 优点在于极大地降低了写程序的...
  • 面向对象的需求分析方法

    千次阅读 2016-11-03 14:11:00
    面向对象的需求分析方法  面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。  面向对象的思想最初起源于 20...
  • 本书先介绍了一些企业应用开发的基础知识,比如分层架构、WEB表现、业务逻辑、数据库映射、并发、会话、分布策略等等。通过使用场景、解决方案、UML等手段详细介绍了设计模式(包括一些常用的设计模式GOF23和本书上...
  • Kotlin极简教程:第7章 面向对象编程

    千次阅读 2017-09-20 20:23:14
    在前面的章节中,我们学习了Kotlin的语言基础知识、类型系统、集合类以及泛型相关的知识。在本章节以及下一章中,我们将一起来学习Kotlin对面向对象编程以及函数式编程的支持。
  • Java-面向对象

    千次阅读 2020-02-14 16:14:48
    封装是指将对象的实现细节隐藏起来,然后通过公共的方法来向外暴露该对象的功能。 继承是面向对象实现软件复用的重要手段,当子类继承父类后,子类是一种特殊的父类,能直接或间接获得父类里的成员。 多态是可以...
  • ZODB 入门 如何通过面向对象的动态语言 Python 使用对象数据库 Noah Gift, 软件工程师, Giftcs Brandon Craig Rhodes (brandon@rhodesmill.org), 软件工程师 简介: 关
  • 某Java大佬在地表最强Java企业(阿里)面试总结

    万次阅读 多人点赞 2020-08-23 19:48:06
    1.5、 可以保证的实习时长 一般都是半年到一年,(太少的话,刚教会了你,你就可能走了,太多的话也不现实) 还有可能问到什么时候去上班,建议的话,就是下个月,或者两周后,今天面试明天上班,肯定准备的不充分...
  • OOP面向对象的编程思想

    千次阅读 2014-05-25 09:04:52
    1、面向对象的编程思想
  • 复杂的企业应用系统都会基于一些平台来开发和运行。这些平台软件主要提供一些各个应用系统共同需要的功能,如用于数据传输...企业应用开发者基于平台开发企业应用系统,可以专注于企业业务逻辑的实现,其他公共的功能由
  • 关键词:基于行为的学习,基于知识的学习,商业智能,工业4.0,知识图谱,企业图谱, 图数据库, 图计算引擎, 数据可视化应用场景:征信、风控、问答、医疗、能源、舆情、反欺诈、市场营销、社...
  • 客户关系管理

    千次阅读 2013-06-08 10:40:12
    客户关系管理 百科名片 ...客户关系管理 ...客户关系管理(Customer ...其内含是企业利用信息技术(IT)和互联网技术实现对客户的整合营销,是以客户为核心的企业营销的技术实现和管理实现。客户关系管理注重的是与
  • 面向对象的分析与设计

    万次阅读 多人点赞 2018-08-05 13:47:42
     一个(较复杂的)对象由其他若干(较简单的)对象作为其构成部分,称较复杂的对象为聚集,称较简单的对象为成分,称这种关系为聚合。如: UML表示举例:   关联  类之间的静态联系称作关联。...
  • 此文为第一篇,由天云软件产品总监马俊带来的IaaS专题:企业级云管理平台的架构实现与落地实践、趋势分析,以下为演讲实录。马俊:我给大家介绍一下云管平台,OpenStack现在比较流行,企业级客户IT架构在OpenStack上...
  • 这个回答有点类似于之类 WY 的博客中看到的,那里面的事例也很好的讲述了关于 Java Bean 的概念,虽然作者没有说明那是 Java Bean ,那其实那就是 Java Bean 的定义。  知乎:   问题:Java bean 是个什么...
  • 公共信息模型CIM

    千次阅读 2010-06-02 11:41:00
    它定义了电力工业的标准对象模型,提供了一种表示电力系统对象,包括其属性和相互关系的标准。 CIM 公共信息模型把电力系统资源( Power System Resource )描述为对象类、属性以及它们...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 43,445
精华内容 17,378
关键字:

企业公共关系的对象就是