当前位置:文档之家› ABSTRACT Workgroup Middleware for Distributed Projects

ABSTRACT Workgroup Middleware for Distributed Projects

ABSTRACT Workgroup Middleware for Distributed Projects
ABSTRACT Workgroup Middleware for Distributed Projects

Workgroup Middleware for Distributed Projects

Gail E.Kaiser and Stephen E.Dossick

Columbia University

Department of Computer Science 1214Amsterdam Avenue,MC 0401

New York,NY 10027USA

212-939-7000/fax:212-939-7084kaiser,

sdossick @https://www.doczj.com/doc/df15972627.html,

ABSTRACT We have developed a middleware framework for workgroup environments that can support distributed software develop-ment and a variety of other application domains requiring document management and change management for distributed projects.The framework enables hypermedia-based integra-tion of arbitrary legacy and new information resources avail-able via a range of protocols,not necessarily known in ad-vance to us as the general framework developers nor even to the environment instance designers.The repositories in which such information resides may be dispersed across the Internet and/or an organizational intranet.The framework also permits a range of client models for user and tool inter-action,and applies an extensible suite of collaboration ser-vices,including but not limited to multi-participant work?ow and coordination,to their information retrievals and updates.That is,the framework is interposed between clients,services and repositories —thus “middleware”.We explain how our framework makes it easy to realize a comprehensive collec-tion of workgroup and work?ow features we culled from a requirements survey conducted by NASA.

KEYWORDS:

Distributed software development support,

distributed document management,monitoring and manag-ing distributed development processes,distributed change man-agement,work?ow management and coordination support in distributed projects,Internet-based software process coordi-nation

INTRODUCTION

We have developed a middleware framework for distributed workgroup environments founded on what we call a referen-tial hyperbase paradigm for representing and hyper-linking the information resources of interest to a collaborating team intent towards some joint purpose or goal (as opposed to in-cidentally browsing the same materials for independent use,such as most World Wide Web users).A referential hyper-base differs from a conventional hyperbase in that the doc-uments need not reside in the system’s own repository.A referential hyperbase differs from a linkbase or link server in providing full object-oriented database functionality includ-ing a query language and entity typing.

The referential hyperbase system communicates with a vari-ety of local and remote information repositories,each through its original https://www.doczj.com/doc/df15972627.html,er clients and tools interact with the hyperbase in client/server fashion,also each through their appropriate protocol.The hyperbase may contain both na-tive objects,internal to the system,and protocol objects,rep-resenting external documents residing in one of the reposi-tories.Native objects are retrieved and presented to clients entirely through the hyperbase’s own object management fa-cilities,but accessing the contents of protocol objects gener-ally involves forwarding the appropriate operation(s)to their home repositories and transmitting the results through the hy-perbase back to the originating client.An extensible set of collaborative work support services are performed explicitly in response to requests from clients and/or implicitly upon accesses to objects,independent of the protocol(s)used.These groupspace ,or group workspace,services may send and re-ceive requests to/from each other as well as through the pro-tocols to backend repositories and frontend clients.Our system does not hardwire any particular protocols for interacting with backend repositories or frontend clients.In-stead,backend access protocols provide means to read and write the documents required by the workgroup,and addi-tional predicates and actions may expose the capabilities of speci?c legacy and new information resources.Frontend pre-sentation protocols tailor our system so that it appears to

Backend

Information Repositories

Frontend

User/Tool Clients

Service Providers

Figure 1:Framework Architecture

clients as if they are communicating with their own infor-mation server.Thus users can continue using their familiar legacy system commands,if desired,while still receiving the bene?ts of the multi-protocol workgroup framework.We are currently rethinking and reimplementing work?ow and transaction-based coordination components previously integrated with our earlier,single-protocol (HTTP)referen-tial hyperbase system targeted speci?cally to distributed soft-ware development projects [11].We have also ported and continue to develop that system’s distributed tool launching component [12].[9]describes our experience using the ear-lier HTTP-only system for our own continuing software de-velopment efforts.Our new multi-protocol framework is in-troduced in [10].Here we brie?y discuss the new framework and our initial implementation,and then focus on how it en-abled us to rapidly ful?ll most of the generic workgroup re-quirements adapted from the publicly available results of a survey conducted within NASA in 1995[8].

REFERENTIAL HYPERBASE

Figure 1illustrates the middleware architecture.Each fron-tend client communicates with the referential hyperbase server in the client’s own native protocol,which is understood by the corresponding Protocol Access Module (PAM).The ref-erential hyperbase server retrieves and updates documents from/to each backend repository using that repository’s na-tive protocol,through the corresponding Data Access Mod-ule (DAM).The PAMs and DAMs are written specially for each client and repository,respectively,as “plugins”with re-spect to the hyperbase system,and are dynamically loaded as needed.Groupspace services are also interfaced to the hyperbase server via plugins.The hyperbase system itself consists of four main components:an object layer;an un-derlying object management system (OMS),not shown,that

realizes the object layer;a data schema that may be extended by DAMs,PAMs and groupspace services;and an API for writing DAMs,PAMs and the service interfaces.

The data schema prede?nes a DAM base class,which is then extended by each new DAM.In general,a DAM treats its protocol object instances as “stubs”for external documents —thus the referential nature of the hyperbase.These docu-ments might reside anywhere on the Internet and/or organiza-tional intranet.A protocol object might re?ect any granular-ity,from an individual tuple in a relational database,to a GIF image,to an MPEG clip,to an entire website hierarchy or database management system,to another hypermedia server,or even to another workgroup environment.Different proto-col objects might represent the same document in different ways or at enclosing granularities,e.g.,a URL pointing to a named fragment of an HTML ?le and a URL referring to the whole ?le can co-exist in the same hyperbase.Arbitrary application-speci?c meta-data and links can be represented by the attributes of protocol objects,independent of any links embedded in their contents and any meta-data maintained by their home repositories.Such attributes can be used,e.g.,to represent dependencies utilized during change propagation.Every DAM necessarily publishes a read method and usu-ally also a write method;e.g.,in the case of HTTP,these would perform GET and PUT functions,respectively.Read-ing a protocol object from the hyperbase generally results in retrieving the document content from its repository and sending that content,along with application-speci?c meta-data and links from the hyperbase,to the appropriate client.A client may modify the content and write the protocol ob-ject,which typically results in updating the corresponding repository.Optional methods may provide type-speci?c or repository-speci?c functionality for particular protocol ob-ject subclasses.For example,printable materials might be associated with a print method,and a protocol object cor-responding to an Oracle or Sybase database might provide an SQL query interface.Any of these methods may potentially employ the object layer as a persistent object store,e.g.,to construct auxiliary objects as children of some protocol ob-ject.

One or more attributes of a protocol object designate the lo-cation of the corresponding external document.For example,this might be a string attribute indicating the URL for a World Wide Web entity.Other attributes,also interpreted by the class’s DAM,locally cache the document content;what con-stitutes content of course depends on the type.For a WWW entity this might be an HTML ?le or a GIF image,and for another collaboration environment the content might be any-thing from a list of active users to a “to-do”list of pending tasks to its events registrar.

GROUPSPACE SERVICES

A groupspace operates on top of a referential hyperbase to actively support workgroup tasks,most signi?cantly but not

solely through work?ow,rather than simply providing pas-sive access to documents.Groupspace functionality is not speci?c to any particular protocol(s),but inserted indepen-dently of the mix of repositories and clients.However,a groupspace service might internally perform distinct actions for different document classes;for instance,in a software de-velopment environment,an editor reading,and possibly later writing,a prose functional speci?cation would probably be treated as a completely different task,with different work-?ow constraints,than a compiler reading source code in or-der to generate and write executables.

Groupspace services are divided into two aspects:providers and roles.Roles are standard interfaces for those services “expected”to be provided by a particular workgroup envi-ronment.Note different environment instances may de?ne different roles,or de?ne what are in essence the same roles differently.These interfaces may be employed by the refer-ential hyperbase system itself,as well as by other groupspace services and by PAMs and DAMs.For example,conven-tional concurrency control and failure recovery is required by all multi-user hypermedia systems[17],and thus must be realized by some role if not built into the underlying OMS. Providers are independent components,connected to the hy-perbase system via plugins,that each realize some service such as work?ow automation,concurrency control and re-covery,tool management,intelligent search,guided tours, and so on.Providers register callbacks implicitly invoked by accesses to instances of particular classes(and their sub-classes),or by accesses to any object.Providers may also publish menus whose entries may be explicitly invoked.Ex-actly one provider may register as the default implementa-tion of a role.It is not necessary to know anything about the provider that ful?lls a role in order to use the standard facilities for that role,since the referential hyperbase’s API is extended with these operations(for that environment in-stance).

The referential hyperbase system triggers groupspace ser-vice roles,and corresponding providers,in two basic modes, which we call wrap-around(or implicit)and direct(or ex-plicit).In either case,the services are independent of the particular communication protocols used.The wrap-around mode involves activating the particular service both before and after each request from the hyperbase to a DAM and hence a backend information repository.

For example,a work?ow service might treat reading a pro-tocol object as a primitive task,and check preconditions be-fore the operation’s execution and assert postconditions af-terwards.Plausible preconditions might include the user’s access rights to the document as well as his/her authoriza-tion and responsibilities with respect to the enclosing com-posite task,the status of all inputs(have prerequisites been ful?lled?),and so on.Possible postconditions might include checking deadlines for production of outputs(have impli-cations been ful?lled?),noti?cation of supervisors,routing to another user for postprocessing as another task,etc.The work?ow engine itself does not need to know whether the ac-tual task re?ected by the protocol object read involves invok-ing an X.509authentication service,retrieving a Web page, or submitting an SQL query.

Wrap-around services are stacked,meaning a speci?c order among services is con?gured for the before callbacks,and the reverse order is employed for the after callbacks.Multi-ple providers for the same role may participate in the stack without awareness on the part of clients.In contrast,clients cannot take advantage of direct services except through the standard interface of a role,or by requesting certain methods of a named provider—requiring some knowledge of that provider’s functionality.

Direct mode assumes that each service exposes a menu of activities(no visual interpretation is implied)whose entries then can be explicitly selected.The simplest example is a list of tools handled by a tool launching service.Note that while a given tool probably needs to know the format of its input and output data,the launching service does not;they can be passed as BLOBS(binary large objects).Another possibility is a work?ow service’s set of tasks;some of those tasks may correspond exactly to reads and writes of individ-ual protocol object instances,as above,but others may be signi?cantly more complex and involve sophisticated com-putations on perhaps hundreds of objects,e.g.,marketing and requirements analysis for revamping the“look and feel”of an existing product line.

User clients might be developed speci?cally as an adjunct to the middleware framework,with their PAMs speaking the “language”consisting of its published terms—from the stan-dard API plus the roles speci?c to a given environment in-stance.In contrast,the PAMs for legacy presentation proto-cols convert or translate to the features provided by the work-group environment,and vice versa,in a manner meaningful for the relevant legacy system.Which services and which menu entries are made available to a particular client de-pends on the PAM.A sophisticated PAM might?lter a menu to make available only some of its entries only under certain circumstances,supply details about the expected parameters, and express the menu entries in a way meaningful to its users. IMPLEMENTATION

Our referential hyperbase server,called Xanth,is implemented as a Java application and runs on any platform that supports Java1.1.Its Java graphical user interface client runs as an applet in Java-enabled browsers,which must be con?gured to use our special HTTP proxy(which may be cascaded with conventional caching or?rewall proxies and/or with other special-purpose proxies).

We use ObjectStore’s Persistent Storage Engine(PSE)as the OMS.Xanth’s object layer supports the usual hierarchical

navigation and addition/deletion of objects,and provides an OQL subset as its query language(PSE does not supply its own query language).

PAMs are explicitly registered;DAMs are implicitly regis-tered via inclusion of their protocol subclass in the object layer’s data schema.Every PAM runs in its own Java thread and is responsible for handling any network communications required by the protocol.DAMs are woken up only when needed,though they may spawn their own background threads during initialization.Xanth’s API thus includes atomic op-erations where warranted,to protect shared data from con-current access,since PAMs,DAMs and groupspace service providers can access the OMS through the object layer.All our DAMs currently follow the JavaBeans conventions,and we plan to soon convert all the PAMs and service plugins. Groupspace service roles are implemented as Java interfaces. Xanth does not hardwire any particular groupspace services, but a particular Xanth workgroup environment called OzWeb 1.0de?nes three roles,Work?owManager,TransactionMan-ager and ToolMediator,with one service ful?lling each role. Details are outside the scope of this paper;see[10]. EVALUATION

The italicized capabilities listed below are paraphrased from the NASA workgroup/work?ow requirements survey.We adopt these as generic goals for our middleware framework, independent of any particular application,but most of them are obviously useful for distributed software development. We respond to each requirement with a brief description of how Xanth makes it relatively easy to realize.

Cross-platform support,covering Unix workstations,PC Win-dows,Macintoshes,and pen-based PDAs:Both Xanth clients and servers run on any platform supporting Java1.1.We’ve tested Windows,Solaris,Linux and Irix.MacOS should work,too,but Apple had just released their Java1.1sup-port as of this writing.We’ve developed partial client sup-port for the Newton MessagePad2000that exploits its na-tive“to-do”list protocol:A PAM listens to the machine’s serial port for the Newton“hotsync”,accepts updates indi-cating completed assignments,and sends a zip-like?le with new work assignments and their ASCII parameters.A cor-responding DAM de?nes Newton-speci?c“to-do”lists as a subclass of the todoList base class,in turn a subclass of the DAM class.A shell script invokes a utility to convert the todoItem children to/from“newton”and stores/retrieves them in the proper synchronization subdirectory.

Access via email,HTTP and dialup modem:A mail?lter program captures email to a Unix userid and resends the con-tents of the message to the Xanth server in HTTP format;re-sponses are similarly converted back from HTTP to email. Another HTTP PAM handles conventional WWW-style re-quests and responses,and the WebObject DAM commu-nicates with backend websites via HTTP.Whether email or HTTP access is appropriate for dialup depends on the modem speed.

Reliable,secure and authenticated data transmission and stor-age:This could be handled separately by every concerned

PAM and DAM,but it would be better to provide X.509au-thentication,public-key encryption and so forth as a wrap-around groupspace service automatically applied to all data accesses and updates as well as to all requests for direct ser-vices.This feature has not yet been implemented.

Support for off-line work and merging:Checkout and Check-

in operations are transmitted by clients via HTTP to the component ful?lling the TransactionManager role in OzWeb

1.0,to place and remove persistent locks permitting off-line

work in the meantime without need for merging—provided

that all other users of the relevant backend repository(ies)

also update it only through the same environment instance. However,if the repository itself supports the checkout model

or long-duration locks,e.g.,a WEBDA V-compliant website[15], then its corresponding methods would be exposed through

the DAM for use by the TransactionManager provider in en-forcing the concurrency control policy.If a non-exclusive

form of Checkout where used instead,then either the DAM

or the backend repository itself would need to provide the merging utility,which is inherently speci?c to the data for-

mat and semantics.Our transaction manager component is presented in[18].

Version Control:The TransactionManager or some other groupspace service(s)could implement versions,but again those versions would only be accessible through Xanth and the backend repository would only contain the latest variant.The CVSPackage DAM,and its auxiliary CVSFile DAM for mirroring the

?les from a CVS directory within the hyperbase,support

an example of a backend repository that itself provides ver-sioning[13].We’re working on another DAM that monitors (polls)the CVS global log for changes and queues up these events,which could trigger work?ow and/or provide input to

a noti?cation service.

Addressing,routing and tracking.Directory services:It is

not clear to us what NASA had in mind here.One form of routing and tracking is provided by the Work?owManager component.A general tracking utility could be provided by another groupspace service for logging whatever is appropri-

ate on behalf of all the other services(and DAMs and PAMs). LDAP[19]and other directory services could be searched via corresponding DAMs.

Personal and shared calendars with meeting and resource scheduling:Our calendar base class,a PAM,de?nes com-

mon functionality for scheduling systems.As an example,

the icalSchedule PAM represents the individual and group calendars implemented by the public domain ical scheduling

tool[7].

To-do items that are prioritizable,assignable to others,and trackable for status:The generic todoList PAM class de-

?nes a common representation for the“to-do”lists of various tools.For instance,the“to-do”items stored in ical calendars are automatically forwarded to the next day until deleted or marked as“done”.

Integrated project?les for email,calendar,to-do,etc.,with data enclosures including BLOBS:The integration is pro-vided through the Xanth hyperbase.Arbitrary protocol ob-jects can be attached via links to any other protocol objects. One protocol object can be enclosed with another when trans-mitted back to clients either as just the OID for later access,

or as contents and attributes.

Threaded dialogues:Our NNTP PAM provides access to In-ternet and intranet news servers,and represents articles ac-cessible via these servers.Threaded articles may be linked

to each other through the hyperbase.Since the cross-article links are implemented by the hyperbase layer,it is possible

to make links between articles in different discussion groups

or on different news servers independent of the underlying usenet threads.

Chat/conference:We’re implementing the proposed Rendezvous Protocol(RVP),an IETF Internet Draft[5],to support scal-able instant messaging(one-line messages)and chat(real-time text conversations)among users of the same or differ-ent Xanth environments.Each RVP server will operate as

a Xanth module(either groupspace plugin or PAM),and the clients as JavaBeans,which can be incorporated into JDK1.1-compliant We

b browsers or other tools.

Video conferencing:This could potentially be realized either through a stream-oriented DAM/PAM pair or by a groupspace service.It is not clear,however,what it would mean to apply wrap-around services to a video conference,or whether the real-time requirements could be satis?ed if the video stream passed through the hyperbase system.It might be better for the ToolMediator to fork the video application separately. Compatibility with current desktop software,and access to desktop and legacy data.A DAM could be constructed to extract/insert data from/to ActiveX applications.A PAM im-plementing the ActiveX Container standard could pop up the appropriate application when such data is accessed by clients.This has not yet been implemented.However,the ToolMediator service already runs arbitrary Windows appli-cations on the user’s PC,or on a server machine and export the display to the user’s Unix workstation via WinDD.

Group whiteboards,editors and drawing tools:There’s noth-ing particularly special in Xanth about multi-user versus single-user tools.We have previously developed session manage-ment and work?ow support for synchronous what-you-see-

is-what-I-see groupware,see[14,3],but have not yet incor-porated those particular functions into the new groupspace components used with https://www.doczj.com/doc/df15972627.html,er-friendly.Sophisticated data entry,access and ware-housing facilities:Existing legacy clients,whether deemed

to be particularly“user friendly”and sophisticated,or not,

can continue to be used through construction of appropri-

ate PAMs.And of course new clients can be developed,ei-

ther for the workgroup framework in general,or for some legacy information resource,and also connected to Xanth via

a PAM.And analogously for DAMs with respect to legacy

and new repositories.The generic approach to groupspace services permits,e.g.,introduction of data mining indepen-dent of the information source.

Ability to integrate additional facilities using standard proto-cols.Enhanceable with respect to interfaces and third party products.These are precisely the main contributions of our multi-protocol architecture.It took the second author four hours to complete the CVS DAM and six hours for the NNTP PAM.Another member of our lab,who was not directly in-volved in the development of Xanth except to interface the TransactionManager component,was able to add HTTP checkin and checkout operations in about an hour.Not counting Xanth and the Oz1.0roles and providers,development of all

the workgroup facilities indicated as completed above was done in two weeks.

Scalable to thousands of users while remaining inexpensive

and supportable with a small staff:Because Xanth and its ToolMediator provide a range of mechanisms for running re-mote tools and otherwise operate as middleware for network-based computing,fewer applications will need to be main-tained on personal computers,hence administration costs should be reduced.We have some preliminary ideas about how to organize“alliances”of multiple Xanth servers to scale up to teams of teams,based on our previous work on Oz[2],but

this requirement will have to wait for future work.

We also developed a Tcl scripting console as a PAM,so one

can telnet to a port on the machine running the Xanth server

and debug by directly calling service plugin,DAM and PAM methods.The facilities above were tested in this way,rather than constructing full-blown graphical user interfaces. CONCLUSIONS

The Open Hypermedia Protocol(OHP)[6]is being negoti-ated in the hypertext community so that viewers for one hy-permedia system can be used with any other compliant sys-tem.Writing a PAM for a given protocol seems substan-tially simpler and quicker than writing or adapting a viewer

to speak OHP,and analogously for DAMs and repositories. Obviously,a PAM can be developed for OHP so that OHP-compliant clients can be utilized.We do not intend to im-

ply that Xanth quali?es as an open hypermedia system,since

we do not intend to build our own viewers,but instead that mixing and matching of legacy hypermedia systems can also

be achieved by integrating them with Xanth via PAMs and DAMs—at the same time automatically enhancing them with the available groupspace services.

A variety of collaboration environments have been developed on top of the World Wide Web infrastructure,each providing some of the workgroup facilities presented above,e.g.,the Virtual Collaboratorium[1]and BSCW[4].But these are generally speci?c to HTTP,and do not support other proto-cols,while most hypermedia systems support their own“pro-prietary”protocol,possibly augmented with OHP.

Our approach is closer to that of the Hyperform framework for hypermedia system development[16]:We provide a frame-work around which sophisticated,protocol-independent hy-permedia collaboration environments may be designed,much as Hyperform provides a rich set of hypermedia abstractions

in its framework.We do not focus,however,on develop-ment tools like those provided in Hyperform.Instead,we concentrate on providing support for development of multi-ple protocol interfaces,giving workgroup environments built with our toolkit access to,as well as allowing access from, many different legacy information systems. ACKNOWLEDGEMENTS:We would like to thank Jingshuang Jack Yang,Wenyu Jiang,and Xiaoning Zhang for their work with the authors on OzWeb.Discussions with members of Dick Taylor’s group at the University of California at Irvine have also contributed substantially to this research.

This effort is sponsored in part by the Defense Advanced Research Projects Agency,and Rome Laboratory,Air Force Materiel Com-mand,USAF,under cooperative agreement F30602-97-2-0022. REFERENCES

1.Pete Beckman,Todd Green,and Juan Villacis.The virtual

collaboratorium.

https://www.doczj.com/doc/df15972627.html,:80/pseware/vc/overview.html.

2.Israel Ben-Shaul and Gail E.Kaiser.A Paradigm for Decen-

tralized Process

Modeling.Kluwer,1995.http://www.wkap.nl/kapis/CGI-

BIN/WORLD/book.htm?0-7923-9631-6.

3.Israel Z.Ben-Shaul and Gail E.Kaiser.Integrating groupware

activities into work?ow management systems.In7th Israeli

Conference on Computer Systems and Software Engineering,

pages140–149.IEEE Computer Society Press,June1996.

ftp://https://www.doczj.com/doc/df15972627.html,/pub/psl/CUCS-002-95.ps.Z.

4.R.Bentley,W.Appelt,U.Busbach,E.Hinrichs,D.Kerr,

K.Sikkel,J.Trevor,and G.Woetzel.Basic support

for cooperative work on the World Wide Web.Interna-

tional Journal of Human Computer Studies,Spring1997.

http://bscw.gmd.de/Papers/IJHCS/IJHCS.html.

5.Martin Calysn.Rendezvous protocol,November1997.In-

ternet Draft.https://www.doczj.com/doc/df15972627.html,/internet-drafts/draft-calsyn-

rvp-00.txt.

6.Hugh Davis,Sigi Reich,and Antoine Rizk.OHP–

Open Hypermedia Protocol working draft2.0,June1997.

https://www.doczj.com/doc/df15972627.html,/hcd/ohp/ohp.htm.

7.Sanjay Ghemawat.

Ical.https://www.doczj.com/doc/df15972627.html,/SRC/personal/Sanjay-

中间件技术

中间件技术 定义: 中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机/ 服务器的操作系统之上,管理计算机资源和网络通讯,是连接两个独立应用程序或独立系统的软件。相连接的系统,即使它们具有不同的接口,但通过中间件相互之间仍能交换信息。执行中间件的一个关键途径是信息传递。通过中间件,应用程序可以工作于多平台或 OS 环境。 中间件处于操作系统软件与用户的应用软件的中间。中间件在操作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。 中间件特点: ?满足大量应用的需要; ?运行于多种硬件和OS平台; ?支持分布式计算,提供跨网络、硬件和OS平台的透明性的应用或服务的交互功能; ?支持标准的协议; ?支持标准的接口。 由于中间件需要屏蔽分布环境中异构的操作系统和网络协议,它必须能够提供分布环境下的通讯服务,我们将这种通讯服务称之为平台。基于目的和实现机

制的不同,我们将平台分为以下主要几类: ?远程过程调用中间件(Remote Procedure Call) ?面向消息的中间件(MesSAge-Oriented Middleware) ?对象请求代理中间件(object RequeST Brokers) ?事务处理监控(Transaction processing monitors) 1、远程过程调用 远程过程调用是一种广泛使用的分布式应用程序处理方法。一个应用程序使用RPC来“远程”执行一个位于不同地址空间里的过程,并且从效果上看和执行本地调用相同。事实上,一个RPC应用分为两个部分:server和client。server 提供一个或多个远程过程;client向server发出远程调用。server和client 可以位于同一台计算机,也可以位于不同的计算机,甚至运行在不同的操作系统之上。它们通过网络进行通讯。 2、面向消息的中间件 MOM指的是利用高效可靠的消息传递机制进行平台无关的数据交流,并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型,它可在分布环境下扩展进程间的通信,并支持多通讯协议、语言、应用程序、硬件和软件平台。目前流行的MOM中间件产品有IBM的MQSeries、BEA的MessageQ等。 3、对象请求代理 对象请求代理(ORB)是对象总线,它在CORBA规范中处于核心地位,定义异构环境下对象透明地发送请求和接收响应的基本机制,是建立对象之间client/server关系的中间件。ORB使得对象可以透明地向其他对象发出请求或接受其他对象的响应,这些对象可以位于本地也可以位于远程机器。ORB拦截请求调用,并负责找到可以实现请求的对象、传送参数、调用相应的方法、返回结果等。client对象并不知道同server对象通讯、激活或存储server对象的机制,也不必知道server对象位于何处、它是用何种语言实现的、使用什么操作系统或其他不属于对象接口的系统成分。 4、事务处理监控 事务处理监控(TPM)最早出现在大型机上,为其提供支持大规模事务处理

为什么需要中间件

为什么要中间件? 计算机技术迅速发展。从硬件技术看,CPU速度越来越高,处理能力越来越强;从软件技术看,应用程序的规模不断扩大,特别是Internet及WWW的出现,使计算机的应用范围更为广阔,许多应用程序需在网络环境的异构平台上运行。这一切都对新一代的软件开发提出了新的需求。在这种分布异构环境中,通常存在多种硬件系统平台(如PC工作站,小型机等)在这些硬件平台上又存在各种各样的系统软件(如不同的操作系统、数据库、语言编译器等),以及多种风格各异的用户界面,这些硬件系统平台还可能采用不同的网络协议和网络体系结构连接。如何把这些系统集成起来并开发新的应用是一个非常现实而困难的问题。 中间件在实际的应用过程中,是对应用软件起到支撑作用,最终用户并不直接使用中间件,中间件不是大众消费类软件产品。因此,除非是一个行业专业人士,一般不大可能与中间件打交道,不太了解什么是中间件。 因此,在系统软件之中,操作系统、数据库、中间件的三驾马车,中间件是最“神秘”的。因为,好歹大家通过Windows基本上会了解操作系统是个什么东西,尽管不会很全面,很专业,毕竟是有感觉的。数据库,虽然没有直接见过,但基本上明白数据是要一个“仓库”来储存的,因此,也大致知道数据库管理系统是干什么的。 长期以来,中间件是一个专业化非常强的细分产业。因为中间件的技术门槛比较高,玩家也不多,无论是国外还是国内都是如此。因此,行业内对什么是中间件并不特别在意。而公司名称直接叫中间件的就更少了,“金蝶中间件”应该是国内外直接在公司名称中冠以中间件字眼最早,也是很少的公司之一。另一方面,因为中间件软件还处于发展阶段,还没有完全成熟,因此对中间件的定义也就没有深究,或者权威的说法。 但现在情况有点变化,其中一个原因在于2008年底,国家启动了“核高基”重大科技专项,在基础软件领域明确提出重点支持“操作系统、数据库、中间件、文字处理”等基础软件产业的自主创新,几乎一夜之间大大小小的软件公司都宣称是做中间件的了,只要不是做最终应用软件的,他们的产品都叫中间件了,一时间,中间件变得“蓬勃发展”起来了。 作为中间件行业内的专业化和领先企业来说,大家都重视起中间件来了,这是好事,说明社会上重视了。对行业的发展和繁荣固然重要,但这也隐含了重大的风险。中间件名字被滥用,无论是对用户,对这个产业,对政府和投资人来说,都会有负面的影响。“鱼目混珠,泥沙俱下”的局面,对中间件产业的正常发展未必就是好事情了,也可能对真正的中间件自主创新带来许多困扰,模糊了中间件的本质,可能会弱化中间件核心技术的创新和发展。 因此,在这种情况下,无论是对行业内,还是行业外,突然“什么是中间件”的问题变成了一个大问题了。

应用中间件要求

投标方必须保证本项目所需软件产品获得生产厂家的合法授权,且为最新版本,并在售后服务承诺中保证提供至少一年的免费升级服务和技术支持服务。主要的应用支撑软件要求如下: 一、数据库系统 投标方提供的数据库管理系统需满足以下具体技术要求: 1、基本功能 提供丰富的数据类型支持,提供丰富的内置函数,主要包括:数学函数、字符串函数、日期时间函数、聚集函数、大对象函数等。支持自定义存储过程/函数,支持触发器,支持视图。支持完整性约束,支持事务的4种隔离级别。 支持海量数据存储和管理,数据存储量为32T以上,单个大对象的最大容量要支持到4GB。并发控制支持表锁、行锁和页锁,具有大规模并发处理能力。 支持集中的数据库管理,提供远程跨平台数据库管理工具;提供良好的性能监控、调整手段;提供跨库、跨系统数据管理能力。 2、安全要求 支持强用户身份鉴别:为用户身份鉴别提供口令、指纹和Radius等多种身份鉴别方式,并允许系统管理员自行配置用户身份鉴别类型。 支持自主访问控制机制:利用对象的ACL列表来检查某个用户是否具有对某个对象的某种访问权限,支持强制访问控制机制:提供基于标签的访问控制方式。提供多种加密方式来保证数据存储安全,至少支持外部密钥加密套件和透明加密两种方式。提供基于证书机制的数据加密传输。提供独立的安全审计,支持系统特权审计、用户审计、语句审计和对象审计四种类型的审计,既可以审计执行成功的语句也可以审计执行失败的语句。支持三权分立的安全体系,建立系统管理员、系统审计员、系统安全员的三权分立安全模型,并将访问控制的粒度细化到行级。 3、性能要求 支持多种索引,支持多种查询优化策略,支持存储过程优化、基于代价的查询优化、基于规划的查询优化,支持高效的自动数据压缩。支持物化视图,提供并行查询能力。支持一级及二级水平分区,包括:hash分区,range分区和list

浅谈未来中间件技术发展的两大趋势

浅谈未来中间件技术发展的两大趋势 中国的ERP开发与应用经过多年的发展,已经取得了很大的成就,“普及”与“深化应用”已经成为当前ERP市场的两大主题。不论普及还是深化都意味着越来越多的人更加关注ERP的实际应用效果,更加关注ERP能否为企业带来实际的效益。对于企业和ERP厂商来讲都是非常有意义的。 ERP应当普及,但如何理解普及?是不是仅依靠某种产品低价销售,或者跑马圈地的方式来普及?这有待于商榷。 首先ERP不能用一个标准的产品销售方式来推广。ERP在管理对象上非常复杂,特别是随着市场竞争的加剧,每个企业在生存和发展过程中都形成了自己的管理理念、流程和方法,不可能用一个标准的产品来适合不同的对象。 所以把ERP的普及比喻成当年的T型车,不是十分妥当。在那个年代大家对需求比较单纯,认为汽车只是交通工具,而现在人们对汽车的要求就很高,不同的型号、配置和特殊要求,需要按订单制造和装配,所以T型在这个年代是不适合的。 大家的需求非常复杂、多变,所以想用某种产品或某一类产品做成标准去推广、普及是不行的。而同时ERP确实需要普及,但如何普及则需要按ERP的发展和应用客观规律来做。首先就是企业流程优化,如果实施ERP不做流程优化,不改变企业传统模式和管理方法,不吸收一些行之有效的管理模式,其结果就是失败。 另外,ERP普及并不意味着ERP产品低价。ERP实施需要资深管理专家和专业的实施顾问,要做流程优化、设计、系统设置和培训等方面的大量工作,这些都是实实在在实施成本。从国外ERP市场情况来看,ERP整个后期实施的费用远远大于软件产品费用。所以用一个很低的软件费吸引客户采购,这种方法是危险的。 中间件(middleware),顾名思义,是处于操作系统与应用软件的之间的基础软件,其作用是为处于自己上层的应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。 10年前,中间件的概念刚刚提出,而如今中间件已成为一个拥有上百亿美元市场的关键软件分类,并成为构建网络分布式异构信息系统不可缺少的关键技术,与操作系统、数据库管理系统并列为基础软件体系的三大支柱。 中间件的价值在哪?中间件如何影响产业的变化? 随着IT系统对企业发展的重要性的不断提升,信息系统也变得越来越复杂,必然也无法避免多厂商产品并存的局面。于是,如何屏蔽不同厂商产品之间的差异,如何减少应用软件开发与工作的复杂性,就成为人们不能不面对的现实问题。 显然,由一个厂商去统一众多产品之间的差异是不可能的,而单独由计算机用户在自己的应用软件中去弥补其中的大片空档,由于技术深度和技术广度的要求,必然也是勉为其难。于是,中间件应运而生。中间件试图通过屏蔽各种复杂的技术细节使技术问题简单化。

weblogic中间件介绍

w e b l o g i c中间件介绍 Company Document number:WTUT-WT88Y-W8BBGB-BWYTT-19998

目录

一、Weblogic11g概述

编写目的 ■金税三期以后的综税的产品线中间件由原来Weblogic814,全面升级为Weblogic11g,JDK统一使用及以上版本。 ■为了满足三期后运维要,全面提高运维工程师运维能力。本文档全面介绍了Weblogic11g中间件的基础操作。 功能简介 ■支持最新的 Java 平台、企业版 (Java EE) 规范及Web 服务标准,从而可简化开发并 增强互操作性,以支持面向服务的体系结构 (SOA)。 ■领先的可靠性、可用性、可扩展性和业界领先的性能。 主要优势 ■J2EE应用服务器性能记录的保持者 ■应用程序和服务的可用性和运行时间 ■更好地监视和管理生产应用程序 ■更快、更高效的开发-部署-调试周期 ■卓越的最终用户客户端可用性 ■高效快速的服务器管理 ■简化新应用程序和服务的开发 适用范围

■J2EE应用服务器 ■BS三层架构的应用服务器 Weblogic11G新特性 自调优的企业级内核 ?静态的线程池参数可以不进行设置 ?系统自动维护线程池的大小 ?自动记录系统历史的吞吐量和性能统计 ?为了达到资源的最优分配,自动优化服务器 ?没有本地代码 过载保护 ?合理的处理过量的服务–过载保护 ?根据内存与队列容量的极限值的设定拒绝请求 ?通过降低非关键业务系统的使用资源,来保证关键业务系统的正常 ?过载的时候拒绝新的请求而不是降低整个服务器的服务质量 ?优雅的意外处理 ?可以选择当发生死锁、内存溢出等关键错误时,关闭或暂停服务器动态的配置变化 ?事务式的配置变化– all or nothing! ?大部分的变化不需要重启服务器

第一章:中间件技术介绍

第一章:中间件技术介绍 1.1两层结构与三层结构 长期以来,我们一直使用着"客户端/服务器"的两层结构,这种两层的结构曾让无数人 为之兴奋和惊叹,即客户端提供用户界面、处理业务逻辑,数据库服务器接受客户端SQL 语句并对数据库进行查询,更新等操作,然后操作结果返回给客户端,如图所示。 在一个比较简单的计算机应用系统中,采用两层体系结构的确给人们带来了相当的灵活性。但随着计算机应用水平的飞速发展、企业信息化水平的不断深入、企业客户的不断增 加,以及新业务的不断出现,越来越多的用户对计算机应用系统提出了更高的要求: 1.要能够同时支持成千上万乃至更多用户的并发服务请求 2.由单一的局域网向跨多个网络协议的广域网扩展 3.不仅要支持一般的信息管理,而且还要支持关键业务的联机交易处理 4.从支持单一的系统平台和数据源转向支持异构的多系统平台和多数据源 面对用户的新需求,二层结构的应用模式由于采用客户机与服务器直接联接的方式形成了其固有的一些缺陷: 1.难以维护 clie nt/server 结构用户界面、业务逻辑和数据逻辑相互交错,通常在第一次部署的时候比较 容易,但难于升级或改进,而且经常基于某种专有的协议(通常是某种数据库协议)。它使得重 用业务逻辑和界面逻辑变得非常困难。 2 ?难以扩展 随着系统的升级,系统复杂程度大大增加,难以扩展,另外它是一个封闭的系统,很难与其他的应用系统实现互操作。 3.安全性差 客户端程序可以直接访问数据库,可通过编程语言或数据库提供的工具直接对数据库进行操作,不安全

4?性能不好 客户端直接与数据库建立连接,当有大量的并发用户存在时,会使数据库不堪重负,性能迅速下降,甚至当机。 三层结构 为解决传统二层模式与应用需求日益突出的矛盾,以交易中间件为基础框架的三层应用模式应运而生,三层结构以中间层管理大量的客户端并为其联接、集成多种异构的服务器平台,通过有效的组织和管理,在极为宽广的范围内将客户机与服务器进行高效组合。同时中间件开创的以负载平衡、动态伸缩等功能为代表的管理模式,已被广泛证实为建立关键业务应用系统的最佳环境,使在二层模式下不可能实现的应用成为可能,并为应用提供了充分的扩展余地。这种模式的成功应用已为许多国际大型企业在应用的开发和部署方面节省了大量的时间和金钱。由此促使越来越多的系统开发商和用户采用三层结构模式开发和实施其应用。 三层客户机/服务器模式的核心概念是利用中间件将应用的用户界面、业务逻辑和数据逻辑 分为三个不同的处理层,如图所示? 1.表示层(用户界面):它的主要功能是实现用户交互和数据表示,为以后的处理收集数据, 向第二层的业务逻辑请求调用核心服务处理,并显示处理结果。这一层通常采用VB, PB DELPHI等语言编写,或采用浏览器实现 2.中间层(业务逻辑):实现整个应用系统核心业务逻辑,通常把业务逻辑划分成一个个独立 的模块,用中间件提供的API结合数据库提供的编程接口实现。客户端通过调用这些模块 实现相应的业务操作。 3.数据层(数据逻辑):数据库负责管理整个应用系统的数据资源,完成数据操作。中间层上应用程序 在处理客户端的请求时,通常要存取数据库。 随着市场竞争的日益加剧和企业电子信息化建设的不断深入,高度灵活、能快速部署新服务和新应用的三层结构应用系统将成为企业信息化的必由之路。采用以中间件为基础的三层结构来架构的应用系统不但具备了大型机系统稳定、安全和处理能力高等特性,同时拥有开放式系统成本低、可扩展性强、开发周期短等优点。可以很好解决两层结构所面临的问题。中间件作为构造三层结构应用系统的基础平台,在三层结构中起着关键的作用,下一节我们将对中间件技术做一个概括性的介绍。 1. 2 中间件技术简介

什么是地图发布中间件及其功能应用介绍

什么是地图发布中间件及其功能应用介绍 一、海量影像地图数据发布首选——中间件 如果需要发布海量影像数据快速构建全国离线二维GIS地理信息系统或全球离线三维地球触摸GIS系统,则需要由硬件、软件、数据和GIS平台四部分组成。 1)硬件 硬件主要包括地图数据服务器和客户端PC机。 服务器:主要用于安装中间件、布署GIS应用平台和存储全国卫星影像数据。 客户端:用于加载GIS平台,并接收中间件发布的影像数据、地名路网数据和高程数据。 2)软件 软件主要包括《水经注地图发布服务中间件》(简称“中间件”)和《水经注万能地图下载器》(简称“下载器”)。 中间件:用于发布全国或全球海量卫星影像数据、地名路网和高程数据。 下载器:用于下载卫星影像数据、地名路网和高程数据。 3)数据 用户可以自行下载数据或直接购买下载好的数据。 自行下载:卫星影像数据、地名路网数据和高程数据可以用《水经注万能地图下载器》自行下载。 直接购买:购买之后,会通过邮寄硬盘(全国数据)或阵列柜(全球数据)

的方式为用户提供。 4)GIS平台 由于中间件只是一个基于URL请求返回瓦片数据的功能部件,因此只要可以支持瓦片式影像加载的GIS平台都可以进行调用。 这里推荐几个GIS开发平台供选择: 1)Google Map 离线API 2)Openlayers 二维开源平台 3)ArcGIS API for JavaScript 4)Cesium 开源三维地球平台 5)OsgEarth开源三维地球平台 二、什么是地图发布中间件 简单的讲,地图发布中间件就是为客户端提供影像瓦片的一个Windows系统服务。它只做一件事,也就是客户端通过URL请求的方式,可以快速返回影像瓦片、地名路网瓦片和高程瓦片数据。 获取影像URL示例 http://127.0.0.1:8080/getImage?z=6&y=62&x=35 获取地图路网URL示例 http://127.0.0.1:8080/getlabel?z=6&y=62&x=35 获取高程URL示例 http://127.0.0.1:8080/getDem?z=6&y=62&x=35

中间件安装步骤

中间件服务器安装步骤 1、安装WINDOWS 2003 32位操作系统,更改计算机名,设置许可证每服务器可连接600 个客户端。 2、在控制面板里的增加删除程序界面,如图安装 3、安装相应驱动程序。 4、设置IP,并加入域https://www.doczj.com/doc/df15972627.html,。 5、先安装R2再安装操作系统的补丁SP2。 6、安装.NET FRAMEWORK 2.0,安装语言包补丁,安装.NET FRAMEWORK 2.0 SDK。 7、安装https://www.doczj.com/doc/df15972627.html,。 8、安装ORACLE客户端,要求安装ODPNET版本第一项和第五项。 9、安装.NET FRAMEWORK 32位补丁1。 10、配置COM+组件服务,如图

COM 安全中四个按钮都要打开,并加入EVERYONE 用户都有全部权限。

11、 把ICARECONTROLLER 的域用户添加到本地管理员组中 12、 拷贝更新服务器上最新的DEBUG 文件夹 13、 运行DEBUG 目录下“生成三层中间件服务器目录.bat ”文件,注册COM+组件

14、修改ICARESYSTEM的属性,如图

15、 把ICAREDA TA.DLL 和IBM.Data.DB2.dll 放到GAC 里,操作方法如下: 建立批处理文件,内容如下:建立bat 文件,内容包括如下,然后把它放在

"D:\Debug\gacutil" /il RegGacFileList.txt pause 然后新建RegGacFileList.txt,里面包括ICAREDATA.DLL、IBM.Data.DB2.dll、EMR_ICAREDATA.DLL和EMR_BASE_VO.DLL文件名即可,格式如下: iCareData.dll IBM.Data.DB2.dll EMR_ICAREDATA.DLL EMR_BASE_VO.DLL 也可以通过控制面板下管理工具中的.NET FRAMEWORK2.0工具进行添加上述四个文件。 16、更新中间件时 a)必须先右键关闭ICARESYSTEM三次,并禁用 b)然后反注册 c)再拷贝新文件 d)再注册 e)启动服务,完成之后再检查ICARESYSTEM的属性,确保没有变成库模式。 17、如果某个中间件之前已经放在GAC里面,首先必须在GAC里进行反注册该中间 件即可,操作方法如下: 建立批处理文件,内容如下 "D:\Debug\gacutil" /ul UnRegGacFileList.txt pause 然后新建UnRegGacFileList.txt,里面包括需要反注册的文件名即可,格式请参考如下:HISReg_SVC(特别注明:不需要加文件扩展名) 18、配置自动更新服务: a)必须先右键关闭UpdateSystem_Svr三次,并禁用 b)再拷贝新文件 c)修改UpdateFiles.xml的版本号和需要更新文件的标志 d)启动服务UpdateSystem_Svr 19、客户端只需要运行icare.exe即可自动更新。

安防监控技术的现状和发展前景

安防监控技术的现状和发展前景 随着安防监控技术的快速发展和信息技术需求的多样化,信息系统变得越来越庞大、复杂和多变,为此中间件技术应运而生,成为了大型信息系统集成的利器。而安防系统作为信息系统的一个重要分支,也将越来越多的利用到中间件技术。 安防监控技术的现状和发展前景 信息系统综合集成的水平反映了一个企业、一个部门,乃至整个国家信息化建设的水平。制定和遵循相关技术标准是一件重要的工作,但是不能照搬工业化的做法。面对复杂而多变的网络世界,中间件就成为信息系统综合集成的利器。 中间件(middleware)是基础软件的一大类,属于可复用软件的范畴。顾名思义,中间件处于操作系统软件与用户的应用软件的中间。中间件在操作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。 在中间件产生以前,应用软件直接使用操作系统、网络协议和数据库等开发,这些都是计算机最底层的东西,越底层越复杂,开发者不得不面临许多很棘手的问题,如操作系统的多样性,繁杂的网络程序设计、管理,复杂多变的网络环境,数据分散处理带来的不一致性问题、性能和效率、安全,等等。顺泰.伟成表示这些与用户的业务没有直接关系,但又必须解决,耗费了大量有限的时间和精力。于是,有人提出能不能将应用软件所要面临的共性问题进行提炼、抽象,在操作系统之上再形成一个可复用的部分,供成千上万的应用软件重复使用。这一技术思想最终构成了中间件这类的软件。 到目前为止,确实有越来越多的用户开始接纳中间件了,甚至在一些大型采购招标项目之中,中间件已经被明确写入了招标书。目前来看,对于中间件的应用需求,还主要集中在行业市场上,与前几年仅仅局限在金融、电信、政府等几个领域的市场状况不同,安防行业市场对于中间件的需求也逐步开始了,并有望占据比较大的市场份额,但是在应用层次上,还是有比较大的区别。

常见的服务器性能指标有哪些及简要介绍

常见的服务器性能指标有哪些及简要介绍 当前业界常见的服务器性能指标有: TPC-C TPC-E TPC-H SPECjbb2005 SPECjEnterprise2010 SPECint2006 及SPECint_rate_2006 SPECfp2006 及SPECfp_rate_2006 SAP SD 2-Tier LINPACK RPE2 一、TPC (Transaction Processing Performance Council) 即联机交易处理性能协会, 成立于1988年的非盈利组织,各主要软硬件供应商均参与,成立目标: 为业界提供可信的数据库及交易处理基准测试结果,当前发布主要基准测试为: TPC-C : 数据库在线查询(OLTP)交易性能 TPC-E : 数据库在线查询(OLTP)交易性能 TPC-H : 商业智能/ 数据仓库/ 在线分析(OLAP)交易性能

1.TPC-C测试内容:数据库事务处理测试, 模拟一个批发商的订单管理系统。实际衡量服务器及数据库软件处理在线查询交易处理(OLTP)的性能表现. 正规TPC-C 测试结果发布必须提供tpmC值, 即每分钟完成多少笔TPC-C 数据库交易(TPC-C Transaction Per Minute), 同时要提供性价比$/tpmC。如果把TPC-C 测试结果写成为tpm, TPM, TPMC, TPCC 均不属正规。 2.TPC-E测试内容:数据库事务处理测试,模拟一个证券交易系统。与TPC-C一样,实际衡量服务器及数据库软件处理在线查询交易处理(OLTP)的性能表现。正规TPC-E测试结果必须提供tpsE值,即每秒钟完成多少笔TPC-E数据库交易(transaction per second),同时提供$/tpsE。测试结果写成其他形式均不属正规。对比:TPC-E测试较TPC-C测试,在测试模型搭建上增加了应用服务器层,同时增加了数据库结构的复杂性,测试成本相对降低。截止目前,TPC-E的测试结果仅公布有50种左右,且测试环境均为PC服务器和windows操作系统,并无power服务器的测试结果。除此之外,TPC官方组织并未声明TPC-E取代TPC-C,所以,说TPC-E取代TPC-C并没有根据。附TPC-C与TPC-E数据库结构对比

中间件开发方案

中间件开发方案 一使用中间件原因 由于呼叫中心提供的调用呼叫中心的方法只支持单独页面的独立调用,无法满足BS架构的用户在多页面调用呼叫中心功能,因此需要使用中间件服务器连接呼叫中心系统,模拟建立独立通信通道,将多页面调用所需的功能发送给中间件,由中间件作为呼叫中心的唯一调用源,以此保证在符合呼叫中心调用机制的情况下完成BS架构的呼叫中心完整功能。 二开发方案1(CS架构客户端调用方式) 中间件组成部分:(服务器端和客户端) 1、服务器端功能: a)CRM用户和呼叫中心坐席关联,记录在中间件坐席信息表中。 b)接收和记录客户端状态和客户端传来的坐席状态。 c)接收和记录BS架构发送的呼叫中心调用命令。 d)记录客户端和BS架构调用呼叫中心的调用记录及调用结果。 2、客户端功能: a)连接呼叫中心的服务器,实现坐席登录功能。 b)获取呼叫中心服务器上的坐席状态,发送给中间件服务器端。 c)用呼叫中心提供的CS开发文档和开发ocx、dll调用呼叫中心的话务功能。 d)调用呼叫中心话务功能的时候讲调用记录发送给中间件服务器端。 e)接收中间件服务器端传来的BS架构调用呼叫中心话务功能的消息,并根据消 息判断触发呼叫中心话务功能类型及参数,翻译后发送给呼叫中心服务器。 f)在客户端转接、强插、监听等功能调用的时候读取中间件服务器端坐席状态表, 获取在线空闲坐席信息、在线通话中坐席信息等列表,并根据列表中的信息整 理成为调用参数,单击或双击列表中坐席调用呼叫中心话务功能。 g)监控来电事件,根据来电号码、客户端登录坐席,实现CRM弹屏。 3、CRM话务功能调用: a)发送命令消息给中间件服务器。500ms后查询服务器执行结果,若执行结果为 失败则显示失败消息,若执行结果为成功则无动作。 b)读取中间件服务器端坐席状态表,获取在线空闲坐席信息、在线通话中坐席信 息等列表,并根据列表中的信息整理成为调用参数,单击或双击列表中坐席将 转接命令消息发送给中间件服务器,并实现销售线索和来电客户数据的自动生 成或关联。

中间件技术综述

中间件技术综述 摘要:介绍了中间件的产生与发展,详细阐述了中间件的定义、分类以及功能与作用。指出了中间件的优缺点,并分析了中间件技术的现状,最后介绍了中间件的应用前景和发展趋势。 关键词:统一软件开发平台、中间件技术 1 引言 随着Internet网络应用技术的发展,基于客户机/服务器(Client/Server)模式的系统设计方法己被广泛地应用于各种类型软件系统的设计与开发中。其编程方式改变了传统的应用程序设计和系统实现方式。为此人们提出了一种介于客户端和服务器端的软件--中间件(Middleware)。中间件是处于应用软件和系统软件之间的一类软件,是独立于硬件或数据库厂商(处于其产品的中间,实现其互连)的一类软件,是客户方与服务方之间的连接件,是需要进行二次开发的中间产品。 于是集软件复用、分布式对象计算、企业级应用开发等技术为一体的“基于中间件的软件开发”伴随产生,这种技术以软件架构为组装蓝图,以可复用软件构件为组装模块,支持组装式软件的复用,大大提高了软件生产效率和软件质量。 2 中间件技术 2.1 中间件的分类 由于中间件所包括的范围十分广泛,而目前对中间件还没有一个比较精确的定义。因此,在不同的角度或不同的层次上,对中间件的分类也会有所不同。基于不同中间件的目的和实现机制的不同,一般将中间件主要分为以下几类:远程过程调用中间件(remote procedure call middle-ware); 面向消息的中间件(message oriented middleware); 对象请求代理(object request broker); 事务处理监控(transaction processing monitor); 数据库中间件(database middleware); 专用中间件(proprietary middleware)。 其中,前3类中间件称为管道,它们可向上提供不同形式的通讯服务,包括

中间件介绍

中间件介绍 文档编制序号:[KKIDT-LLE0828-LLETD298-POI08]

中间件介绍 1、Ice: ICE(Internet Communications Engine)是ZeroC提供的一款高性能的中间件,基于ICE可以实现电信级的解决方案。在设计网站架构的时候可以使用ICE实现对网站应用的基础对象操作,将基础对象操作和数据库操作封装在这一层,在业务逻辑层以及表现层(java,php,,python)进行更丰富的表现与操作,从而实现比较好的架构。基于ICE的数据层可以在未来方便的进行扩展。ICE支持分布式的部署管理,消息中间件,以及网格计算等等。 Zeroc推出的一种分布式的面向对象中间件,解决分布式的异构计算。可以用 C++,Java,c#等进行分布式的交互计算。 主要设计目标是: ·成为适用于异种环境的平台。 ·具有一组完整的特性,支持广泛的领域中的实际的的开发。 ·去掉不必要的复杂性,使平台更易于学习和使用。 ·是一种在、内存使用和CPU开销方面都很高效的实现。 ·是一种具有内建安全性的实现,使它适用于不安全的公共网络。 2、JBoss: 是一个基于J2EE的的。 JBoss代码遵循LGPL许可,可以在任何商业应用中免费使用,而不用支付费用。JBoss是一个管理EJB的容器和服务器,支持EJB 、EJB 和EJB3的规范。但JBoss核心服务不包括支持servlet/JSP的WEB容器,一般与Tomcat或Jetty绑定使用。 在J2EE领域,JBoss是发展最为迅速的应用服务器。由于JBoss遵循商业友好的LGPL授权分发,并且由开源社区开发,这使得JBoss广为流行。 另外,JBoss应用服务器还具有许多优秀的特质。 JBoss运行后后台管理界面 其一,将具有革命性的JMX服务作为其; 其二,本身就是(Service-Oriented Architecture,); 其三,具有统一的类装载器,从而能够实现应用的和热卸载能力。 因此,高度模块化的和松耦合。JBoss应用服务器是健壮的、高质量的,而且还具有良好的性能。 1、JBoss是免费的,J2EE的实现,通过许可证进行发布。但同时也有的,开源和闭源流入流出的不是同一途径。 2、JBoss需要的内存和硬盘空间比较小。 3、安装便捷:解压后,只需配置一些即可。 4、JBoss支持"热部署",部署BEAN时,只拷贝BEAN的文件到部署路径下即可自动加载;如果有改动,也会自动更新。 5、JBoss与Web服务器在同一个中运行,Servlet调用EJB不经过网络,从而大大提高运行效率,提升安全性能。

TUXEDO中间件介绍及应用

TUXEDO中间件介绍及应用 一、前言 首先介绍一下什么是中间件?中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源,中间件位于客户机服务器的操作系统之上,管理计算资源和网络通信。 中间件屏蔽了底层操作系统的复杂性,使程序开发人员面对一个简单而统一的开发环境,减少程序设计的复杂性,将注意力集中在自己的业务上,不必再为程序在不同系统软件上的移植而重复工作,从而大大减少了技术上的负担。 世界著名的咨询机构Standish Group在一份研究报告中归纳了中间件的十大优越性: ●缩短应用的开发周期 ●节约应用的开发成本 ●减少系统初期的建设成本●降低应用开发的失败率●保护已有的投资●简化应用集成 ●减少维护费用 ●提高应用的开发质量●保证技术进步的连续性●增强应用的生命力 Tuxedo是第一个严格意义上的中间件产品。Tuxedo是1984年在当时属于A T&T的贝尔实验室开发完成的,但Tuxedo在很长一段时期里只是实验室产品。直到BEA公司1995年收购Tuxedo后,使Tuxedo现已经发展成为交易中间件领域事实上的标准。 TUXEDO是在企业、Internet 这样的分布式运算环境中,开发和管理三层结构的客户/服务器型关键任务应用系统的强有力工具。它具备分布式事务处理和应用通信功能,并提供完善的各种服务来建立、运行和管理关键任务应用系统。开发人员能够用它建立跨多个硬件平台、数据库和操作系统的可互操作的应用系统。 二、TUXEDO的组件软件模型 TUXEDO采用三层结构的组件软件模型。 图1 BEA TUXEDO 的组件软件模型概要

中间件技术介绍

中间件技术介绍 中间件(middleware)是基础软件的一大类,属于可复用软件的范畴。顾名思义,中间件处于操作系统软件与用户的应用软件的中间。中间件在操作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。 在众多关于中间件的定义中,比较普遍被接受的是IDC 表述的:中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源,中间件位于客户机服务器的操作系统之上,管理计算资源和网络通信。 IDC对中间件的定义表明,中间件是一类软件,而非一种软件;中间件不仅仅实现互连,还要实现应用之间的互操作;中间件是基于分布式处理的软件,最突出的特点是其网络通信功能。 中科院软件所研究员仲萃豪形象地把中间件定义为:平台+通信。这个定义限定了只有用于分布式系统中的此类软件才能被称为中间件,同时此定义还可以把中间件与支撑软件和实用软件区分开来。 目前,中间件发展很快,已经与操作系统、数据库并列为三大基础软件。中间件主要分为以下几类:

1.通信处理(消息)中间件 此类中间件能在不同平台之间通信,实现分布式系统中可靠的、高效的、实时的跨平台数据传输(如Tong LINK、BEAe Link、IBM的MQ Series等)。这是中间件中唯一不可缺少的,是销售额最大的中间件产品。 2.交易中间件 在分布式事务处理系统中要处理大量事务,常常在系统中要同时做上万笔事务。例如在北京市就要设置各种运载汽车,完成日常的运载,同时要随时监视汽车运行,出现故障时,要有排除措施,发生堵塞时要进行调度。在联机事务处理系统(OLTP)中,每笔事务常常要多台服务器上的程序顺序地协调完成,一旦中间发生某种故障时,不但要完成恢复工作,而且要自动切换系统,达到系统永不停机,实现高可靠性运行;同时要使大量事务在多台应用服务器能实时并发运行,并进行负载平衡地调度,实现昂贵的可靠性机和大型计算机系统同等的功能,为了实现这个目标,要求系统具有监视和调度整个系统的功能。BEA的Tuxedo由此而著名,它成为增长率最高的厂商。一个事务处理平台,根据X/OPEN的参数模型规定,应由事务处理中间件、通信处理中间件以及数据存取管理中间件三部分组成。东方通科技公司的Tong LINK和TongEASY实现了这个参考模型规定。3.数据存取管理中间件

中间件应用部署整体要求

1.中间件应用部署整体要求 以下中间件应用部署要求主要指基于WEB服务器及Java中间件部署的WEB、J2EE等的应用。 1.1.内容要求 a)对整个系统硬件架构进行描述,提供系统架构组网图,此部分可以在主机集成部分提供。 b)对应用系统软件架构进行描述,提供应用软件架构图,对系统数据流,系统控制流以及 外部接口进行描述。 2.中间件应用部署用户要求 2.1.内容要求 a)要求对中间件软件及应用系统安装用户和组进行合理规划。 b)应用系统安装和部署必须新建用户和组,不能使用root安装。 c)对于一般应用,中间件软件与应用系统可以部署在同一用户下。 d)对于同一系统在不同主机上的相同应用,所有新建应用用户的UID,GID信息在所有主机 上保持一致。 2.2.内容实例 ● ● 3.中间件应用部署目录要求 3.1.内容要求

a)要求对中间件软件及应用系统安装目录进行合理规划。 b)应用系统要求部署在独立的文件系统上,在rootvg下建立文件系统。 c)对于同一系统在不同主机上的相同应用,所有目录部署结构在所有主机上保持一致。 d)中间件软件安装目录、域目录、应用发布目录要求独立部署。 ● 3.2.内容实例 ●WebLogic应用目录部署示例 网厅应用前台部署目录:

4.中间件软件及版本要求 4.1.内容要求 a)对使用的中间件软件及版本,32/64bit进行描述; b)对使用的JDK版本进行描述,根据中间件软件的安装要求,选择符合要求的JDK最新 稳定版本。 4.2.内容示例 5.中间件主机参数及系统包要求 5.1.内容要求 a)根据不同操作系统平台,要求的操作系统补丁; b)根据不同操作系统平台,需修改相应的核心参数,保证中间件的安装与运行; 5.2.内容示例 ●WebLoigc(AIX平台) 操作系统补丁要求: 操作系统参数要求:

中间件技术的现状及其发展_符春

作者简介:符春(1980-),女,湖南怀化人,长沙民政职业技术学院电子信息工程系讲师,研究方向为中间件技术。 中间件技术的现状及其发展 符 春 (长沙民政职业技术学院,湖南长沙410004) 摘 要:为了解决分布式环境问题,使得中间件技术受到人们广泛的关注。从中间件技术的概念、分类、特点、优势与 应用几个方面阐述了中间件技术的现状,并同时提出了中间件今后发展的趋势。关键词:中间件;分布式环境中图分类号:TP3-05 文献标识码:A 文章编号:1672-7800(2009)09-0007-02 0引言 计算机技术迅速发展,许多应用程序在网络环境的异构平 台上运行。这一切都对新一代的软件开发提出了新的需求。在这种分布式异构环境中,通常存在多种硬件系统平台(如PC 、工作站、小型机等),在这些硬件平台上又存在各种各样的系统软件(如不同的操作系统、数据库、语言编译器等),以及多种风格各异的用户界面,这些硬件系统平台还可能采用不同的网络协议和网络体系结构连接。如何把这些系统集成起来并开发新的应用是一个非常现实而困难的问题。为解决分布异构问题,人们提出了中间件(middleware )的概念。 1中间件的概念 中间件是基于构件技术,处于两种或多种软件之间(通常 是在应用程序和操作系统、网络操作系统或数据库管理系统之间)传递信息的软件;它使用户能使用一种脚本语言来选择和连接已有的服务,从而生成简单程序的软件开发工具。中间件涉及软件的各个领域,是供公用应用程序编程接口的软件。中间件在操作系统、网络和数据库之上,应用软件的下层,总的作用是为处于自己上层的应用软件提供运行与开发的环境,帮助用户灵活、高效地开发和集成复杂的应用软件。中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源。中间件位于客户机/服务器的操作系统之上,管理计算资源和网络通讯。 2中间件的分类 随着计算机软件技术的发展,中间件技术也已经日渐成 熟,并且出现了不同层次、不同类型的中间件产品。从宏观上看,中间件可以分为3大类:①数据类。用于数据的存取、利用 和增值,此类中间件用于构建以数据为中心的应用;②处理类。把分布在网络结点上的各个应用或处理连接在一起,形成一个统一的分布式应用;③分布式构件类。支持构件式应用,未来应用的发展方向,目前竞争激烈。 然而基于目的和实现机制的不同,又可以将中间件分为5种:数据库中间件、远程过程调用(RPC )中间件、面向消息中间件、基于对象请求代理(ORB )的中间件、事务处理中间件。它们可向上提供不同形式的通讯服务,包括同步、排队、订阅发布、广播等等。在这些基本的中间件之上,可构筑各种框架,为应用程序提供不同领域内的服务,如事务处理监控器、分布数据访问、对象事务管理器等。 3中间件的特点与优势 中间件是一种位于具体应用和底层系统(包括操作系统、 网络协议栈、硬件等)之间的软件。中间件在这个软件体系中所扮演的角色是:连接应用程序和底层软硬件基础设施,协调应用各部分的连接和互操作;使系统开发者能够实现并简化基于各种不同技术的服务组件之间的集成。在应用系统开发中采用中间件技术有以下特点:①满足大量应用的需要;②运行于多种硬件和OS 平台;③支持分布式计算,提供跨网络、硬件和OS 平台的透明性的应用或服务的交互功能;④支持标准的协议; ⑤支持标准的接口。 过去的十多年是中间件技术飞速发展的时期,中间件技术已经被广泛应用到IT 行业的各个技术领域,它极大的缓解了分布式应用开发、运行、管理中的一些固有的复杂问题。中间件技术已经成为分布式软件系统不可或缺的关键基础设施,它同操作系统、数据库系统共同构成了基础软件体系的3大支柱。 中间件的主旨就是要支持网络应用的有效开发、部署、运行和管理。中间件是一种独立的系统软件或服务程序,分布式应用软件借助这种软件在不同的技术之间共享资源。中间件软 软件导刊 Software Guide 第8卷%第9期 2009年9月Vol.8No.9Sep.2009

业界常见的服务器性能指标简要介绍

当前业界常见的服务器性能指标有: TPC-C TPC-E TPC-H SPECjbb2005 SPECjEnterprise2010 SPECint2006 及SPECint_rate_2006 SPECfp2006 及SPECfp_rate_2006 SAP SD 2-Tier LINPACK RPE2 一、TPC (Transaction Processing Performance Council) 即联机交易处理性能协会, 成立于1988年的非盈利组织,各主要软硬件供应商均参与,成立目标: 为业界提供可信的数据库及交易处理基准测试结果,当前发布主要基准测试为: TPC-C : 数据库在线查询(OLTP)交易性能 TPC-E : 数据库在线查询(OLTP)交易性能 TPC-H : 商业智能/ 数据仓库/ 在线分析(OLAP)交易性能 1.TPC-C测试内容:数据库事务处理测试, 模拟一个批发商的订单管理系统。实际衡量服务器及数据库软件处理在线查询交易处理(OLTP)的性能表现. 正规TPC-C 测试结果发布必须提供tpmC值, 即每分钟完成多少笔TPC-C 数据库交易(TPC-C Transaction Per Minute), 同时要提供性价比$/tpmC。如果把TPC-C 测试结果写成为tpm, TPM, TPMC, TPCC 均不属正规。 2.TPC-E测试内容:数据库事务处理测试,模拟一个证券交易系统。与TPC-C 一样,实际衡量服务器及数据库软件处理在线查询交易处理(OLTP)的性能表现。正规TPC-E测试结果必须提供tpsE值,即每秒钟完成多少笔TPC-E数据库交易(transaction per second),同时提供$/tpsE。测试结果写成其他形式均不属正规。 对比:TPC-E测试较TPC-C测试,在测试模型搭建上增加了应用服务器层,同时增加了数据库结构的复杂性,测试成本相对降低。截止目前,TPC-E的测试结果仅公布有50种左右,且测试环境均为PC服务器和windows操作系统,并无power服务器的测试结果。除此之外,TPC官方组织并未声明TPC-E取代TPC-C,所以,说TPC-E取代TPC-C并没有根据。 附TPC-C与TPC-E数据库结构对比

相关主题
相关文档 最新文档