英语翻译 网页翻译不要

3.0 A Reference Architecture for Service Oriented Architecture

A reference architecture is a more concrete artifact used by architects. Unlike the reference model, it can introduce additional details and concepts to provide a more complete picture for those who may implement a particular class. Reference architectures declare details that would be in all instances of a certain class, much like an abstract constructor class in programming. Each subsequent architecture designed from the reference architecture would be specialized for a specific set of requirements. Reference architectures often introduce concepts such as cardinality, structure, infrastructure, and other types of binary relationship details. Accordingly, reference models do not have service providers and consumers. If they did, then a reference model would have infrastructure (between the two concrete entities) and it would not longer be a model.

The reference model and the reference architecture are intended to be part of a set of guiding artifacts that are used with patterns. Architects can use these artifacts in conjunction with others to compose their own SOA. The relationships are depicted in Figure 3.1.

The concepts and relationships defined by the reference model are intended to be the basis for describing reference architectures that will define more specific categories of SOA designs. Specifically, these specialized architectures will enable solution patterns to solve particular problems. Concrete architectures may be developed based upon a combination of reference architectures, architectural patterns, and additional requirements, including those imposed by technology environments. Architecture is not done in isolation; it must account for the goals, motivation, and requirements that define the actual problems being addressed. While reference architectures can form the basis of classes of solutions, concrete architectures will define specific solution approaches.

Architects and developers also need to bind their own SOA to concrete standards technologies and protocols at some point. These are typically part of the requirements process. For example, when building a highly efficient client side Mashup application, a developer might opt for the ActionScript Messaging Format (AMFiv) to provide the most efficient communication between remote services and the client .

Neutrality

The reference architecture shown in Figure 3.2 is not tied to any specific technologies, standards, or protocols. In fact, it would be equally applicable to a .NETv or J2EEvi environment and can be used with either the Web Service family of technologies, plain old XML-RPC (XML – Remote Procedure Call), or a proprietary set of standards. This reference architecture allows developers to make decisions and adopt technologies that are best suited to their specific requirements.

3.1 Service Tier

The server side component of the reference architecture has a number of commonly used components. The Service Provider Interface is the main integration point whereby service providers connect to capabilities that exist in internal systems in order to expose them as services. These internal applications typically reside in a resource tier, a virtual collection of capabilities that become exposed as services so consumers can access their functionality. Service providers may integrate such capabilities using numerous mechanisms, including using other services. In most cases, an enterprise will use the Application Programmatic Interface (API) of the system as provided by the application vendor.

The Service Invocation Layer is where services are invoked. A service may be invoked when an external messages being received or, alternatively, it can be invoked by an internal system or by a non-message based event (such as a time out). It is essential to understand that services may be invoked via messages from multiple sets of standards and protocols working together. Common examples of external service interface endpoints include:

. Asynchronous JavaScript and XML (AJAXvii),

. Simple Object Access Protocol (SOAP),

. XML Remote Procedure Call (XML-RPC),

. a watched folder being polled for content,

. an email endpoint, and

. other RESTviii style endpoints including plain old HTTP and HTTP/S.

Services may also be invoked by local consumers including environments like J2EE and language specific interfaces (for example - Plain Old Java Objects or POJO’s).

Each service invocation is often handed to a new instance of a service container. The service container is responsible for handling the service invocation request for its entire lifecycle, until either it reaches a successful conclusion or failed end state. Regardless of its ultimate end state, the service container may also delegate responsibilities for certain aspects of the service’s runtime to other services for common tasks. These tasks typically include logging functions, archiving, security, and authentication, among others.

To facilitate orchestration and aggregation of services into processes and composite applications, a registry-repository is often used. During the process design phase, the registry-repository provides a single view of all services and related artifacts. The repository provides a persistence mechanism for artifacts during the runtime of processes and workflows. If multiple system actors use and interact with a form, the repository can persist it while allowing access to privileged individuals.

Design, development and governance tools are also commonly used by humans to deploy, monitor, and aggregate multiple services into more complex processes and applications.

最新回答 (1条回答)

2010-01-15 回答

3.0一个参考架构,面向服务架构的参考架构是一个更具体的工件建筑师使用。不同的参考模型,可以引进更多的细节和观念,为那些谁可以实现某一特定类别更全面的了解。参考架构申报就像在编程抽象类的构造细节,将在某一类的所有实例。每个后续的架构设计的,参考架构将是一组特定的专业要求。参考架构经常项目,例如基数,结构,基础设施的概念,二元关系和其他类型的细节。因此,参考模型没有服务提供商和消费者。如果是这样,那么参考模型将基础设施(两个具体的实体),不会再是一个模范。

参考模型和参考架构是为了成为一个模式是用来指导与工件集的一部分。建筑师可以使用与他人一起,这些文物,撰写自己的SOA。描绘的关系图3.1。

的概念和参考模型定义的关系的目的是描述的参考依据架构,将定义SOA的设计更具体的类别。具体来说,这些专门的架构将使解决方案模式来解决具体问题。混凝土结构后,可以制定一个参考架构,建筑模式的组合为基础,并追加经费,包括技术环境下实施的。建筑不是孤立进行,它必须为目标,动机和要求,确定帐户的实际问题得到解决。虽然参考架构可以形成解决方案的阶级基础,混凝土结构将确定具体的解决办法。

建筑师和开发商也需要约束自己的SOA的具体标准技术和协议在某些时候。这些通常的要求进程的一部分。例如,当建立高效能的客户端混搭应用,开发人员可能选择的ActionScript消息格式(AMFiv),以提供远程服务之间和客户最有效的沟通。

中立

该参考架构图3.2所示是不依赖于任何特定的技术,标准,或协议。事实上,这将是同样适用于1。网络电视或J2EEvi环境,可与网络服务技术的家庭使用的,老式的XML - RPC(XML的-远程过程调用),或专有的一套标准。该参考架构,使开发人员能够作出决定,采取最适合其特定要求的技术。3.1服务层

该参考架构服务器端组件有一个常用的元件数量。该服务提供程序接口是主要的结合点,使服务供应商连接功能,在内部系统的存在是为了公开为服务。这些内部应用程序通常驻留在资源层,一个是成为公开为服务,使消费者能够访问他们的功能能力的虚拟馆藏。服务提供者可以结合使用这些功能,包括使用大量的其他服务的机制。在大多数情况下,企业将使用由供应商提供的应用系统的应用程序编程接口(API)

服务调用层是服务被调用。一个服务时,可援引外部邮件被接收,或者,它可以通过内部系统调用,或由一个非基于消息的事件(如超时)。这是必须认识到,服务可能是通过从标准和协议合作的消息援引多套。对外服务接口端点常见的例子包括:异步JavaScript和XML(AJAXvii)。简单对象访问协议(SOAP)。 XML的远程过程调用(XML - RPC的)。一看文件夹被调查的内容。电子邮件端点,其他RESTviii式端点包括老式的HTTP和HTTP / S的服务,也可以调用包括像J2EE和语言环境(例如-普通Java对象或特定的接口本地消费者的POJO的)。

每个服务调用通常是交给一个服务容器的新实例。该服务容器负责处理其整个生命周期服务调用请求,直到达到或者取得圆满成功或失败的最终状态。其最终目的的状态如何,服务容器也可委托这项服务的运行时某些方面的责任,共同任务,其他服务。这些任务通常包括记录功能,归档,安全和认证等。为方便新工艺和复合应用程序,注册表,仓库业务流程和服务聚集经常被使用。在这个过程中的设计阶段,注册与信息库提供的所有服务及相关文物的单一视图。在该库提供的流程和工作流程运行时对工件持久性机制。如果多个系统者使用和互动的形式,该库可以坚持它同时允许特权的人。

设计,开发和管理工具,还常用于人类的部署,监控,并为更复杂的流程和应用聚合多个服务