天天综合亚洲色在线精品,亚洲av最新在线观看网址,亚洲精品国产日韩无码AV永久免费网

SOA

邓璠 — Mon, 22 May 2006 09:31:00 GMT

Service-Oriented Architecture
面向服务的架�?/p>

软�g业从最初的面向�q�程、面向对象，到后来的面向�l��g、面向集成，直到现在的面向服务，走过了一条螺旋上升的曲线�?br />其实�Q�自从上世纪70�q�代提出“��Y件危机”，诞生软�g工程学科以来�Q��ؓ了彻底摆��p�Y件系�l�开发惔潭，我们一直也没有攑ּ�努力�?br />SOA的定�?br />SOA�Q�面向服务的架构是一个组件模型，它将应用�E�序的不同功能单�?---服务(service)�Q�通过服务间定义良好的接口和契�U?contract)联系��h��。接口采用中立的方式定义�Q�独立于具体实现服务的硬件��^台、操作系�l�和�~�程语言�Q��得构建在�q�样的系�l�中的服务可以��用统一和标准的方式�q�行通信�?br />�q�种��h��中立的接口定�?没有强制�l�定到特定的实现�?的特征称为服务之间的松耦合
软�g�pȝ��架构
SOA不是一�U�语�a��Q�也不是一�U�具体的技术，更不是一�U��品，而是一�U��Y件系�l�架构，它尝试给出在特定环境下推荐采用的一�U�架构�?br />从这个角度上来说�Q�它其实更像一�U�架构模�?Pattern)�Q�是一�U�理忉|��构，是�h们面向应用服务的解决�Ҏ��框架�?/p>

　服务是一个自包含的、无状态的实体�Q�可以由多个�l��g�l�成。它通过事先定义的界面响应服务请求。它也可以执行诸如编辑和处理事务�{�离散性�Q务。服务本�w��ƈ不依赖于其他函数和过�E�的状态。用什么技术实现服务，�q�不在其定义中加以限制�?/p>

服务提供者提供符合契�U�的服务�Q��ƈ��它们发布到服务代理�?/p>

服务��h��者也叫服务��用者，它发现�ƈ调用其他的��Y件服务来提供商业解决�Ҏ��。从概念上来��_��SOA 本质上是��网�l�、传输协议和安全�l�节留给特定的实现来处理。服务请求者通常�U�Cؓ客户端，但是�Q�也可以是终端用户应用程序或别的服务�?/p>

服务是整个SOA实现的核�?#xB;
SOA架构的基本元素是服务�Q�SOA 指定一�l�实�?服务提供者、服务消费者、服务注册表、服务条�ƾ、服务代理和服务契约)�Q�这些实体详�l�说明了如何提供和消�Ҏ��务�?br />遵��@ SOA 观点的系�l�必��要有服务，�q�些服务是可互操作的、独立的、模块化的、位�|�明��的、松耦合的�ƈ且可以通过�|�络查找其地址�?/p>

服务代理者作为储存库、电话黄��|��据交换所�Q��生由服务提供者发布的软�g接口�?/p>

�q�三�U?SOA 参与�?服务提供者、服务代理者以及服务请求者通过 3 个基本操�?发布、查找、绑定相互作用。服务提供者向服务代理者发布服务。服务请求者通过服务代理者查找所需的服务，�q�绑定到�q�些服务上。服务提供者和服务��h��者之间可以交互�?/p>

所谓服务的无状态，是指服务不依赖于��M��事先讑֮�的条�Ӟ��是状态无关的(state-free)。在SOA架构中，一个服务不会依赖于其他服务的状态�?它们从客��L��接受服务��h��。因为服务是无状态的�Q�它们可以被�~�排(orchestrated)和序列化(sequenced)成多个序�?(有时�q�采用流水线机制) �Q�以执行商业逻辑。编排指的是序列化服务�ƈ提供数据处理逻辑。但不包括数据的展现功能�?br />SOA的一些重要特�?br /> 服务的封�?encapsulation)。将服务��装成用于业务流�E�的可重用组件的应用�E�序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的API保持不变�Q��得用戯��d��体实施上的变更�?/p>

SOA的一些重要特�?br /> 服务的重�?reuse)。服务的可重用性设计显著地降低了成本。�ؓ了实现可重用性，服务只工作在特定处理�q�程的上下文(context)中，独立于底层实现和客户需求的变更�?/p>

SOA的一些重要特�?br /> 服务的互操作。互操作�q�不是一个新概念。在CORBA、DCOM、Web Service中就已经采用互操作技术了。在SOA中，通过服务之间既定的通信协议�q�行互操作。主要有同步和异步两�U�通信机制。SOA提供服务的互操作�Ҏ��更利于其在多个场合被重用�?/p>

SOA的一些重要特�?br /> 服务是自�ȝ��(Autonomous)功能实体。服务是��q��件组成的�l�合模块�Q�是自包含和模块化的�?/p>

SOA的一些重要特�?br /> SOA非常��架构中提供服务的功能实体的完全独立自�ȝ��能力。传�l�的�l��g技术，都需要有一个宿�?Host或者Server)来存攑֒��理�q�些功能实体;当这些宿主运行结束时�q�些�l��g的寿命也随之�l�束。这样当宿主本��n或者其它功能部分出现问题的时候，在该宿主上运行的其它应用服务��׃��受到影响�?br />SOA的一些重要特�?br /> SOA架构中非常强调实体自我管理和恢复能力。常见的用来�q�行自我恢复的技术，比如事务处理�Q�消息队列等在SOA中都起到臛_��重要的作用�?br />SOA的一些重要特�?br /> 服务之间的松耦合度。服务请求者到服务提供者的�l�定与服务之间应该是松耦合的。这��意味着�Q�服务请求者不知道提供者实现的技术细节，比如�E�序设计语言、部�|��^収ͼ��{�等。服务请求者往往通过消息调用操作�Q�请求消息和响应�Q�而不是通过使用 API 和文件格式�?br />SOA的一些重要特�?br /> 松耦合使会话一端的软�g可以在不影响另一端的情况下发生改变，前提是消息模式保持不变。在一个极端的情况下，服务提供者可以将以前��Z��遗留代码的实现完全用��Z�� Java 语言的新代码取代�Q�同时又不对服务��h��者造成��M��影响。这�U�情冉|��真实的，只要��C��码支持相同的通信协议�?br />SOA的一些重要特�?br /> 服务是位�|�透明的。服务是针对业务需求设计的�Q�需要反应需求的变化�Q�即所谓敏捯��计。要想真正实��C��务与服务的分��R��就必须使得服务的设计和部��v对用��h��说是完全透明的。也��是��_��用户完全不必知道响应自己需求的服务的位�|�，甚至不必知道具体是哪个服务参与了响应�?br />抽象�U�别1�Q�操�?br /> 代表单个逻辑工作单元的事务。执行操作通常会导致读、写或修改一个或多个持久性数据。SOA 操作可以直接与面向对象的�Ҏ��相比。它们都有特定的�l�构化接口，�q�且�q�回�l�构化的响应。完全同�Ҏ��一��P��特定操作的执行可能涉及调用附加的操作�?br />抽象�U�别2�Q�服�?br /> 代表操作的逻辑分组。服务可以分层，以降低耦合度和复杂性。一个服务的�_�度大小也与�pȝ��的性能息息相关。粒度太��，会增加服务间互操作通讯的开销;�_�度太大�Q�又会媄响服务面寚w��求变化的敏捷性�?br />抽象�U�别3�Q�业务流�E?br /> 为实现特定业务目标而执行的一�l�长期运行的动作或活动。业务流�E�通常包括多个业务调用�?br />业务��程
在SOA中，业务��程包括依据一�l�业务规则按照有序序列执行的一�p�d��操作。操作的排序、选择和执行称为服务或��程�~�排。典型的情况是调用已�~�排服务来响应业务事件。从建模的观�Ҏ��看，描述设计良好的操作、服务和��程抽象的特征以及系�l�地构造它们是重要的�?br />

邓璠 2006-05-22 17:31 发表评论

An article on Service-Oriented Architecture from Sun Corp.

邓璠 — Mon, 22 May 2006 09:20:00 GMT

Service Oriented Architecture - Part 1

By Samudra Gupta

Sun Corporation

Introduction

In recent times, more and more organizations are implementing IT systems across different departments. The challenge is to find a solution that is extendible, flexible and fits well with the existing legacy systems. Replacing legacy systems to cope with the new architecture is not only costly but also introduces risk of malfunctioning. In this context, the traditional software architectures proves ineffective in providing the right level of cost effective and extendible Information systems across the organization boundaries. Service Oriented Architecture (S0A) provides a relatively cheap and more cost-effective solution addressing these problems and challenges. Although, it is not a new concept, with the advent of recent platform-independent programs and platform-neutral data models, SOA needs some fresh attention. In this installment, we will examine the anatomy of a Service Oriented Architecture and develop an understanding of how to implement SOA in an architectural level.

Why do we need SOA?

One important factor in imbibing a new model of Software Architecture is the ever-changing business model. Modern day business constantly needs to adapt to new customer bases. The ability to quickly adapt to the new customer base and new business partners is the key to success. Sharing IT systems with other organizations is a new trend in the business. For example, businesses like online auctions are opening their systems to third party organization in an effort to better reach their customer base. In this context, Service Oriented Architecture offers benefit and cost-effectiveness to the business. The process of adapting to the changing business model is not an easy task. There are many legacy systems, which are difficult to make available to the new business partners. These legacy systems might need to change to support the new business functions and integrate to the newly developed IT systems or integrate to the IT systems of its partners'. The complexity of the whole thing is what makes it a constant challenge to organizations.

Imagine a government department has some legacy Sales Tax management system which interacts with the legacy Trader Management system. Suddenly, the government needs to incorporate a new Green House tax. Now the new Green House Tax system will also interact with the legacy Trader Information system and also affect the existing Sales Tax for the Traders who are paying Green House Tax, In essence, because of the introduction of the new Green House Tax system, both the legacy systems need to be readjusted to deal with the new type of Traders and Tax information. This is costly as all the existing legacy systems will have to be modified and will need to be re-tested.

This sort of complexity scenarios can be resolved by adopting SOA. Services are defined as a set of well-defined interfaces, which are generic in nature. Services also define a schema for the input to be supplied to the Service by its consumer. The inherent nature of SOA is that Services work with an extendible Schema and thereby can cope with various different types of entities that the Service is dealing with. For example, a Customer Management system works with a XML based data passed into it and it is capable of processing any type of Customer without needing to know the difference between a Corporate Customer and a Household Customer. This aspect of SOA resolves the above mentioned complexity scenario without having to change.

Essentially, Services operate as an independent entity. An Organizational IT system is composed of a collection of Services. Each of these Services can evolve and change in its own right.

Another example might be, a bank. Imagine that several areas of banking applications will deal with the current balance of an existing customer. More than often, the “get current balance�?functionality is repeated in various application softwares written within a banking environment. This gives rise to a redundant programming scenario. The focus should be towards finding this sort of common, reusable functionality and implement them as a service, so that all banking applications can reuse the service as and when necessary.

We have briefly discussed the case for SOA. We have seen that SOA is mostly driven by the business model of an organization. The real benefit lies in the reduced cost to fit into changing and reusable business model. Now let us try to define what do we mean by a “Service�?

What is a Service?

A Service is an implementation of a well-defined business functionality that operates independent of the state of any other Service defined within the system. Services have a well- defined set of interfaces and operate through a pre-defined contract between the client of the Service and the Service itself.

A Service can be of various nature. A Business service may mean “getAccountBalance�? A business Transaction Service may mean something like “makeCreditCardPayment�? A system Service may offer some operations like “deleteAFile�?

In Service Oriented Architecture, the system operates as a collection of services. Each Service may interact with various other Services to accomplish a certain task. The operation of one Service might be a combination of several low level functions. In that case, these low level functions are NOT considered Services.

How to Identify Services

Technically, you can make any piece of functionality as a Service, but doing so will make the organizational IT systems cluttered and complicated to maintain. The advantage is in keeping the Services as a set of well-organized functionalities. Services must represent a tangible Business concept. For example, getAccountBalance() is a tangible business process but convertStringToNumber() is not an identifiable business concept and therefore is not a candidate for a Service.

The process of identifying potential Services is by no means an easy task. At this stage, I have seen many organizations get carried away by the available technologies forgetting that the technology should not drive the Business. Although, identifying Services is a series of organization-wide analysis, certain analysis patterns can be applied to find out the potential services. Here are some things to consider when deciding.

Analyses a certain part of the organizational business process and decompose them into several smaller business process. For example, Order Processing System of an organization can be decomposed into smaller business processes such as checkInventory(), processPayment(), updateInventory() etc.

Identify if any of the smaller business processes are re- used or can potentially be reused in other organizational business process. For example, checkInventory() can also be used by the Stock Management application within the organization. The reusable business processes are strong candidates for operating as Services.

Draft the required inputs to these business processes and define what the specific outputs they must produce. Attention must be paid to keep these inputs and outputs generic so that the Service remains reusable and are capable of providing Service to changing business models. For example, processPayment() service at present might only accept check payment but should be flexible enough to support Card payment in order to support changing business needs. Hence, the input to the processPayment() Service must be defined in a generic fashion. We will discuss more about Service Specification in part 2 of this article.

Identify, if these Business processes are already implemented as an IT system within the organization. If yes, then analyses the Business critical factor for all the existing applications to identify which ones need to be converted to SOA. For example, if a clothes retailer no longer accepts refund/exchange of goods, we do not need to consider to look into Refund/Exchange application.

Identify, what Services operate together, what are the dependencies between various Services.

Find out, if the Services will be used only internally or will be opened to external consumers also. This will have impact on the definition of the Services.

Identify, whether the Services operate in a synchronous or asynchronous manner. What is the permissible response time for the Services?

These are guidelines from my experience in working in the industry with quite a few organizations, where we successfully provided SOA based solutions. By no means is this list complete and I do not believe that there can ever be a complete set of formulas for identifying the correct set and subset of Services to be implemented. It is always an ongoing process as new requirements keep on coming in. But the gist of the story is that one needs great attention to identify the sets of Services that are to be deployed within the organization.

Technology and Patience

I know I talk a lot about the background here, but, one thing I have learned from my mistakes is not to rush into technology. In order to be effective in our execution we must correctly identify the Business processes and the Business requirements. Only then can we make a decision on what technology will work best. Then, we draw a set of Service specifications. We measure the specifications against the infrastructural constraints of the organization in concern. A simple case may be that if most of the IT application in a specific organization is already written using Visual Basic, then we need to pause before we propose a Java based solution. Remember, any technology is capable of producing a Business solution and switching technology means extra costs, which may need to be justified. So please be patient until next part of this article, where we take a step towards the technology.

Conclusion

In the first part of this series, we have layed out a case for the Service Oriented Architecture, defined what Service actually means and discussed few guidelines about identifying Services. We have also warned about the danger in rushing to technology too early in the process of SOA implementation. In the next part of this article, we will talk about the Service specification and take a step towards available lava based technologies to implement Service Oriented Architecture.

Next month, we will talk about Service Specification and available technology and in the final part, we will discuss the most popular technology for SOA—Web Services.

Service Oriented Architecture - Part 2

By Samudra Gupta

Introduction

In part 1 of this article, we analyzed the need for Service Oriented Architecture (SOA) in today's ever changing business model. Experience shows that before we decide on a technology, careful thinking and analysis is required to arrive at the correct level of granularity and appropriate Service definitions. Development teams need to be focused on what we are trying to achieve and adapting any one technology does not guarantee success in achieving the goal. We outlined a few general guidelines in the analysis stage of the process and laid out a path for identifying Services. In part 2, we will concentrate more on the technical aspects of Service Oriented Architecture and finally will reach a framework for implementing Service Oriented Architecture.

The SOA objectives

Technically, the foremost concept to understand is what we are trying to achieve with SOA. At the very bottom, SOA relies on basic units of application software, which automates one or more pre-defined business processes. In a simplistic scenario, the goal is to make these basic application units accessible to the client and also for these basic application units to talk to each other in a technology-neutral manner. In a more complex scenario, the goal is to sustain these basic application components and just change the underlying technology for improved efficiency. For example, one organization might have a CustomerManagement?application component. The component offers some Services and the Insurance Department and the Marketing Department of the organization make use of the CustomerManagement. Now for improved efficiency, we must be able to migrate the CustomerManagement component to EJB without affecting the client of this component or event, we should be able to convert this component to a .NET component even though the client to this component is written using a different technology, Java per say.

Keeping these issues in mind, implementing SOA demands the following features:

Technology Independence: The Consumer of a Service component is completely independent of the technology of the Provider component and vice-versa.

Life-cycle Independence: Each of the Provider and Consumer Service components should be able to operate in a separate life- cycle.

Loose Coupling: The Service Consumer Component must define its specification independent of the Service Provider Component. The responsibility of aligning the two specifications is up to the Assembler component, which bridges the gap between two worlds.

Invokable interfaces: The Service interfaces must be invokable either locally or remotely. At the architecture level, we don’t really care how the interface is invoked.

Communication Protocol: A Service must be invokable by variety of protocol. The choice of protocol must not restrict the behavior of the Service. Binding to a specific protocol must take place at run-time/deployment-time, and not at the design or development time.

How to arrive at such solution

In the Part 1 of this series, we have defined Services as software application units that provide a distinct and atomic business process. Services do operate independent of the technology involved in the Consumer and the Service provider itself.

Although it is a new and novel concept to introduce the inter- operability of application units in a technology neutral way, the basic building of SOA relies on some of the proven methodologies such as Component Based Development. The Components do exist as the basic unit of the application performing a certain business operation itself or by collaborating with other components. What is unique to the SOA is how these components are invoked and also how the components interact with each other.

In my opinion, having a sound Component based design helps any organization to newly implement or even migrate towards SOA in a smooth transition. In the following sections, we will elaborate on the concepts of Component Based Development and how it can be used alongside Service Oriented Architecture (SOA). Often we use the term SOA and Web Service interchangeably, which is not strictly correct. Web Service is one implementation of SOA wherein SOA really means a set of technology, which enables us to develop business functions as Components which can be invoked and used in a technology independent fashion.

The Process

In the previous article of this series, we have outlined guidelines on identifying the reusable business processes across the organizations boundary. The outcome of this process can lead to the basic building blocks or Components that co-exist within an organization and perform one or more business operations.

Component Specification: In a technology neutral way like UML define the business functions. This must be technology independent. This just specifies what the interfaces are that the Component offers and what the Component dependencies are.

Interface Definition: Translation of the Functional Specification in a target platform language in a technology neutral way. For example, the interfaces can be elaborated using UML and translated into a programming language of choice such as Java.

Service Specification: Subscribing to 1..* functional interfaces. Services can collate multiple Component interfaces to provide a coarse-grained Service Definition. Again, this needs to be technology neutral.

Service Discovery and Registry: A mechanism for Registering Services to a registry. The Consumers use a Service Discovery mechanism and access the Services by looking up in the registry.

Technology binding: Consumer Components are inherently technology independent. We need to plug-in a technology binding mechanism to use a certain kind of interface exposed by the Service provider and its runtime instance technology. For example, we need to plug-in a technology layer into the Service Consumer to access a Service by using EJB or by using Web Service mechanism as is appropriate. We will elaborate on this later in this article.

The following small example will clear the clouds. Let us assume that in a company we are to write a Payroll Management System which manages the Employee payroll records and posts the pay- slips to their home addresses using the Address manager component. Also there is another Component which looks after the employee welfare and sends out a gift check on the anniversary or birthdays of employees.

The component specification of the above components can be shown as in Figure-1.

Figure-1 The Component Specification

Let us consider that we might want to offer a Service at a higher level called the EmployeeService which can subscribe to both the Payroll Management and Welfare Management interfaces. The Service Definition for the EmployeeService might look like the following in Figure-2.

Figure-2 The Service Specification

The interface definitions are still technology independent but can be translated in to a specific programming language such as Java. For example, the interface definition for the EmployeeService can look like the following in Java (Listing - 1). We have omitted the data type references from the diagram for simplicity

public interface IEmployeeManger {

void sendPayslip(IEmployee employee, IDocument payslip)

throws EmployeeNotFoundException,

ServiceUnavailableException;

void sendGiftCheck(IEmployee employee, IDocument check) throw

EmployeeNotFoundException,ServiceUnavailableException;

}

Listing-1 the interface definition(there were two line breaks added to make it fit the page)

Note: The Exceptions listed above are very much application specific exceptions and avoid any technology specific exceptions.

The Glues

So far we have defined the EmployeeService and its interfaces. We have seen that this interface definition is totally technology neutral. However, at deployment time we may decide to one or more instances of this Service supporting different communication protocol. There is no restriction that the same Service cannot offer more than one invocation protocol. Rather, in different situations it is more appropriate to offer multiple protocol support to provide service to different Consumers.

So far we had the Consumer component and the Service Component being specified and implemented in isolation. But there must be something in the middle to glue these two together. We discuss the missing bits as follows:

Technology

In OO concept, the great thing about interface concept is that multiple implementations of the same interface can co-exist. Binding to any particular implementation can happen at run-time or compile-time. Dynamic binding at runtime offers greater flexibility to switch between implementations based on context. For example, an AddressManager Component can be invoked remotely using Web Service based on XML-SOAP protocol or also can be invoked as a Pure Java component or EJB when it is invoked locally.

It is a good design pattern to separate the technology layer form the actual business logic and business operations. The business operations can be implemented as a standard Java class. The technology layer is solely responsible to implement the technology logic and infrastructural service calls. For example, in EJB technology, the technology layer will consist of the EJBs, which will interact with the container to manage transactions etc. However, the actual business logic may be delegated to another standard Java class.

Service Discovery and Registry

When a Service interface is implemented using a specific technology, the Service needs to publish itself to a registry for the Consumers to lookup and use the Service. This is implemented as another separate layer called Service Access Layer. This layer is responsible for looking up Services using certain lookup mechanism. For an EJB, this layer might perform a JNDI lookup and for Web Service this layer might use a Web Service Registry lookup.

Where Happens the Mapping

So far we have said that the Service consumer and the Service provider specification are independent of each other. This also meant that the data represented in both these domains can also be different. So there needs to be a mechanism to align these two worlds. An ideal place for this mapping to happen is the Service Access Layer. This layer can receive the data object from the Service consumer and then use the Service provider Transfer object to map data. Also this layer can convert any Exceptions generated into an appropriate one that is understood and defined in the Service consumer specification.

Who Implements the Layers, the Responsibilities

We have seen that layering the application based on separation of concern is a good way to achieve the loose-coupling between the Service consumer and the Service provider. We have identified the layers within Components carrying out different roles and responsibilities. Looking at the full picture, we can thus assign the responsibilities to the Service consumer and to the Service Provider.

Figure 3 The overall picture

The Service Provider component is responsible for providing all the above mentioned layers. A mistake often made is to make the Service Access layer as part of the Consumer, which creates a tight-coupling between the Consumer and the Provider in terms of technology.

Conclusion

In this article, we have examined the technical aspects of the Service Oriented Architecture (SOA) and its root in Component Based Development (CBD). One of the biggest mistakes in the world of SOA is that they are identified with Web Services. But it is to be stressed that Web Service is one form of SOA. If we do not design our Components carefully, we will end-up with a solution which is tightly coupled with Web Services technology. In the future, it will then be a big change to move towards another technology such as Web Service. This sort of situation defies the very basic goal of SOA that we should be able to write Consumer and Provider Components irrespective of technology used in either of them.

In the next part of this series, we will develop a Web service example based on the Component concept discussed in there. Please feel free to discuss and let me know your ideas on this. Thanks.

Benoy Jose is a web developer with over six years of experience in J2EE and Microsoft technologies. He is a Sun Certified programmer and enjoys writing technical and non-technical articles for various magazines.

邓璠 2006-05-22 17:20 发表评论