分布计算环境作业一.通过生成进程来构建并发服务器与使用多线程来构建并发服务器相比有优点也有缺点,请分析这两种方式的优缺点。你认为基于CORBA实现的并发服务器是基于生成进程的方法,还是基于多线程的方法?为什么?并发服务器需要同时处理多个请求。采用多进程:优点:1)处理各个请求的进程之间隔离性好。缺点:1)创建/撤销处理各个请求的进程的代价大;2)分发器(主进程……)将请求发送到另一个进程的代价大(如果能说明为什么代价大更好);3)如果各个子进程间需要通信,代价大。采用线程:优点:1)创建/撤销处理各个请求的线程的代价小;2)分发器(主线程……)将请求发送到另一个线程的代价小(如果能够说明为什么代价小更好);3)如果各个线程间需要通信,代价小。缺点:1)一个线程出问题,可能会影响其他线程。CORBA:使用多线程技术实现并发服务器。因为如果采用多进程实现,有以下问题:1)服务器端要同时维护多个可被用户访问的CORBA对象,这些对象的数量常常会比较大,为每个服务对象起一个进程,进程数会比较大,系统开销过大;2)对于远程方法调用来说,请求的参数比较复杂,主进程将请求再发送给子进程,开销比较大;3)主进程、子进程都需要ORB的Runtime,进程启动/撤销的代价大;所以如果采用多进程的话实现并发CORBA服务器很困难。主要问题:(一)针对性不够:a)直接罗列进程和线程的优缺点(二)理由不够充分:a)为支持高并发及高可用,所以多线程或多进程b)为支持稳定性和健壮性,所以多线程或多进程c)ORB拿到请求后要决定哪一个对象实例完成这个请求,送过去,这种工作过程类似于线程d)多线程更适合,代价低,所以e)因为ORB每拿到一个对象都会派生一个线程,所以f)事务控制,所以…….g)CORBA要对稳定性隔离性要求较高,所以基于进程方式(三)没有弄清楚题目问的重点:a)CORBA支持远程调用,客户和服务器不在同一个位置,所以多进程(四)其它:a)服务对象由不同语言编写,不能在单一进程中b)因为POA有线程策略,那么如果你不知道POA的工作机制呢?c)多个伺服对象在不同位置,所以多进程。二.为什么传输层通信服务往往不适合用于直接构建比较复杂的分布式应用?目前的解决办法是什么?为什么这样做?首先,说明传输层通信服务提供什么样的能力?只是为端到端连接提供传输服务。其次分析构建比较复杂分布式应用需要什么样的支持?不仅仅是端到端的通信支持,而且要求具有一些分布透明性,如位置的透明性、访问透明性等,显然,仅仅基于传输层服务,位置、访问透明性等的支持,例如远程对象访问方法的打包拆包等等,都需要应用程序开发者来负责实现,大大加大了应用开发的难度。目前使用分布计算环境(中间件)来支持相应的分布式应用系统的实现。例如使用CORBA、EJB支持面向对象的分布式系统的实现。使用消息中间件来支持面向消息的分布式系统的实现。使用WebService来实现Web环境下分布式系统的实现。等等(举2个或以上例子就好)。这些分布式计算环境解决了相应的分布式应用系统要解决的共性问题,如支持访问、位置透明性,使得分布式应用系统可以更加方便地构建。主要问题:(一)为什么不行,说得太简单,就说了没有支持分布透明性,需要开发人员注意通信的实现,从而导致解决方案的可扩展性很差。(二)解决方法单一:ODP、RPC、MPI、HTTP、消息队列…….。(三)使用C/S模式。(四)流、各种应用级协议都提到了,就是不提分布计算环境。(五)局限在通信一点上。三.DNS中的高层命名服务器(那些在DNS命名空间中接近根的)一般不支持递归式名字解析,为什么?你认为CORBA的命名服务使用的是哪种解析方法,为什么?(1)采用递归方式,对性能影响较大:维持缓存、服务器要等待等等。而基于DNS的工作机制,高层服务器要处理的请求量大,对性能要求高。所以……(2)CORBA命名服务通过resolve方法,根据指定的对象名,返回给相应的对象引用,对于客户来说,这是一次请求得到最终结果的方式,因此可以认为是递归方式。采用这种一次性获得结果的方式,使得客户端编程简单便捷。主要问题:(一)说明了DNS的工作机制,指明根域名服务器不支持递归,但没有说明为什么。(二)CORBA名字空间的树形结构是基于LDAP属性的吗?(三)CORBA的命名服务提供了Iterator迭代接口,但这不能说明是迭代解析。(四)至于DNS中的重定位/重定向方式,在CORBA中主要用于提供重置透明性,与命名服务的工作机制无关。四.CORBAORB中,实现了ODP工程视点中存根对象、联编对象和协议对象的功能的组件分别是什么?CORBA应用中,对应于客户端和服务器端的基本工程对象的组件分别是什么?存根对象:服务器端骨架、客户端存根;联编对象:ORB核心和对象适配器;协议对象:ORB核心;服务器端基本工程对象:对象实现的实例(伺服对象);客户端基本工程对象:客户应用程序。主要问题:答非所问的,把通道里的对象也当成基本工程对象的。五.现要为某网上商城实现一个商品价格查询服务,该服务具有以下功能:用户可以主动查询某个商品的价格。用户可以订购某个商品的价格,当商品价格低于用户指定的阈值时,该服务通知订购用户当前的价格。多个用户可同时使用该服务。现要使用面向对象的技术,如CORBA技术实现该服务:请描述该服务对象和客户端程序(用户程序)分别需要实现的接口。接口可以采用任何一种程序设计语言描述(甚至夹杂自然语言),但要明确每个接口名、接口中的方法名、方法的返回值和参数名以及类型。商品价格查询服务的接口:方法一:价格查询FloatgetPrice(StringgoodID)throwssomeFailure返回值为价格。方法二:订购价格变化情况Voidsubscribe(StringgoodID,floatmyInterestPrice,RefmyCallback)throwssomesomeFailure其中,myInterestPrice为指定的价格阈值,myCallback为实现nicePrice()方法的客户端回调接口对象引用。客户端实现的接口:方法一:VoidnicePrice(StringgoodID,floatnicePrice)throwssomesomeFailure其中,nicePrice是低于阈值的新价格。(参数类型和名字等,可在合理范围内变动。缺失红色部分,不会扣分)主要问题:写代码的。写属性的。接口与方法混淆的。代码里直接写着提醒用户的。还有把客户端和服务器端要实现的方法写在同一个接口中的。首先弄清楚,谁实现的接口由谁来调。六.无状态会话Bean可以用于实现有状态的应用吗?为什么?可以。虽然无状态会话Bean在不同方法调用中不保留任何状态,但可以将用于识别会话的数据保留在客户端,客户随后的请求中携带该数据,使得接收请求的无状态会话Bean可以识别出正在为哪个会话进行处理,从而实现有状态服务。例如,无状态会话Bean在客户某次会话的第一次请求时将一个可以标识本次会话的ID返回给客户方,由客户保存,同时服务器将该会话相关的状态数据保留在持久化存储中。则该会话持续过程中,客户每次请求服务器时,在方法参数中加入这个ID,这样,无状态会话Bean的该方法执行时,可以根据这个标识符从数据库中取出相应的状态数据,基于该数据进行处理,处理完后新状态可以重新存入数据库,以备后续调用使用,从而实现有状态服务。主要问题:第一问不明确答复。明确回答可以或者不可以。把无状态会话Bean的定义和特点抄一遍就是原因了。回答不可以,因为存在于对象池中供多个客户使用,所以不能保持某一客户的状态。无状态会话Bean中也有成员变量。无状态会话Bean会有成员变量吗?你需要怎么谨慎地使用它,才能保证这个状态不至于影响各个方法的调用结果?想一想,为什么EJB2.0中说到,无状态会话Bean的Create方法没有参数?(计数器服务?)使用Cookie,Bean的使用环境中无Cookie。有状态BeanNew不出那么多,大家共享。七.EJB3.0中是否还有类似EJB2.0中的生命周期方法(回调方法)的成份存在?为什么?还有。因为EJB3.0中的Bean,例如很多有状态会话Bean,仍然需要有容器负责相应的状态初始化、状态保存、状态恢复等生命周期管理工作,如在初始化或者从外存恢复到内存时进行状态的赋值,所以必须要有相应的接口如回调函数供容器调用从而完成这些工作,这些回调函数的作用与2.0的生命周期函数是基本一样的。只是回调函数的定义方法与2.0不一样,不再需要实现某个接口,而是可以定义任意名字的方法,通过增加标注如@PostConstruct来声明其为一标注指定类型的回调方法。主要问题:明确回答有或者没有。八.在语义网中,各概念(或资源)间的关系有清晰的定义,请问这些关系可以由语义网中的哪些技术来定义?为什么?(不考虑本体上面的层次)可以使用RDFSchema自身词汇、RDFSchema定义的新的词汇、本体语言自身词汇、本体语言定义的新的词汇。例如RDFschema中的subClassOf、value;RDFSchema定义的新的词汇author;本体语言OWL中的disjointWith、partOf;OWL定义的Fly。主要问题:不针对性回答问题,把相关定义抄一遍。九.轻量级容器的控制反转实质上是“对象生成”的控制权的倒置,这是把对象生成的控制权从对象的调用者交给了被调用对象吗?为什么?不是。因为实际上是把对象生成的控制权从对象的调用者交给了容器,由容器来控制。容器根据配置文件或者标注,为调用对象创建出被调用对象(被依赖对象),然后把创建好的对象注入到调用对象那里,供调用对象使用。主要问题:没有明确说交给了容器或由容器来控制。十.XML标记及其标记之间的嵌套可以描述XML文档的结构并传达所标记数据的含义,因此对数据的处理方式取决于标记,对吗?为什么?不对。虽然XML标记说明了数据的含义,但是处理方式取决于具体处理这个数据的程序或者脚本,对于同样含义的数据,可以有不同的处理方式。当然,对于标准化的程序,比如XHTML的浏览器,对于XHTML的标记的处理,就有相对一致的处理方式,这时候,才可以说取决于标记。主要问题:此处理非彼处理。题中泛指对数据的各种处理。有的同学特指为解析器或者XSLT。对于XML解析器来说,从某种角度说好像取决于标记,但实际上取决于使用解析器的程序。对于XSLT来说,实际上取决于XSL,它决定对什么样的标记做什么样的工作。进一步地,对于标准化的程序,比如XHTML的浏览器,对于XHTML的标记的处理,就有相对一致的处理方式,这时候,才可以说取决于标记。