(继续回医院吊水，呵呵)

出席： eeiser ， thyme ， int ， enetor

依旧是晚上 18:30 开始。

由于前段日子大家各有考试和一些琐碎的事情，没能集中精力放在这个项目上。因此对整个任务的理解并没有突破性的进展。通过前一段时间文档资料的阅读，对 SOA 、 ERP 、 CRM 都有了应有的概念，但普遍的困惑是，我们究竟怎么来完成题目，以及怎么把 SOA 的思想用进去。

老大 eeiser 收集到了台湾赛区的一些作品，虽然跟我们的题目大相径庭，但他们完成的设计文档给了我们一些参照，起码让了解了一下大致要做成什么样子。但与我们原来设想的有些不同，因为这些作品还是相对比较虚，只是提出了初步的想法和大致的系统与服务划分，并不考虑系统的实现。三个人在一起研究了一下台湾参赛作品后，达成一致意见，即我们必须动手开始勾画我们自己的系统。于是分别对业务流程和服务划分等提出了各自的意见，其中也有不少争论。决定先由两人设计出初步的业务流程与服务划分，下一次来进行讨论。

会议决定：

1、              eeiser 完成初步的业务流程图设计

2、              int 完成初步的服务划分

3、              thyme 和 enetor 继续整理相关的 SOA 文档

不管怎么说，已经对需要做什么有了比较清晰的认识，接下去只要按照计划做就好了。

     晚上18：30开始。
     首先观看了IBM提供的梁海奇研究员的大赛说明视频，进一步理解和领会大赛的目的与要求。接着看了几篇SOA相关的文档。期间，个人依照自己的理解，展开了讨论。
     分歧的存在是明显的。对于SOA架构的理解，以及大赛对ERP和CRM的整合要求等等。每人都阐述了自己的观点与可能涉及的实现、困难等等。
      会议一直持续到晚上九点多，时长三个小时多。通过讨论，对于大赛的实现和要求，有了更清晰的了解。
      会议决定：
             1，分歧继续存在，不做意见统一。大家继续对文档、软件、业务进行熟悉和探究，以期找到真正能够符合SOA的架构和实现。
             2，下次会议时间为5月31日

软件业从最初的面向过程、面向对象，到后来的面向组件、面向集成，直到现在的面向服务，走过了一条螺旋上升的曲线。
其实，自从上世纪70年代提出“软件危机”，诞生软件工程学科以来，为了彻底摆脱软件系统开发泥潭，我们一直也没有放弃努力。
SOA的定义
SOA，面向服务的架构是一个组件模型，它将应用程序的不同功能单元----服务(service)，通过服务间定义良好的接口和契约(contract)联系起来。接口采用中立的方式定义，独立于具体实现服务的硬件平台、操作系统和编程语言，使得构建在这样的系统中的服务可以使用统一和标准的方式进行通信。
这种具有中立的接口定义(没有强制绑定到特定的实现上)的特征称为服务之间的松耦合
软件系统架构
SOA不是一种语言，也不是一种具体的技术，更不是一种产品，而是一种软件系统架构，它尝试给出在特定环境下推荐采用的一种架构。
从这个角度上来说，它其实更像一种架构模式(Pattern)，是一种理念架构，是人们面向应用服务的解决方案框架。

　       服务是一个自包含的、无状态的实体，可以由多个组件组成。它通过事先定义的界面响应服务请求。它也可以执行诸如编辑和处理事务等离散性任务。服务本身并不依赖于其他函数和过程的状态。用什么技术实现服务，并不在其定义中加以限制。

           服务提供者提供符合契约的服务，并将它们发布到服务代理。

            服务请求者也叫服务使用者，它发现并调用其他的软件服务来提供商业解决方案。从概念上来说，SOA 本质上是将网络、传输协议和安全细节留给特定的实现来处理。服务请求者通常称为客户端，但是，也可以是终端用户应用程序或别的服务。

服务是整个SOA实现的核心
SOA架构的基本元素是服务，SOA 指定一组实体(服务提供者、服务消费者、服务注册表、服务条款、服务代理和服务契约)，这些实体详细说明了如何提供和消费服务。
遵循 SOA 观点的系统必须要有服务，这些服务是可互操作的、独立的、模块化的、位置明确的、松耦合的并且可以通过网络查找其地址。

           服务代理者作为储存库、电话黄页或票据交换所，产生由服务提供者发布的软件接口。

          这三种 SOA 参与者:服务提供者、服务代理者以及服务请求者通过 3 个基本操作:发布、查找、绑定相互作用。服务提供者向服务代理者发布服务。服务请求者通过服务代理者查找所需的服务，并绑定到这些服务上。服务提供者和服务请求者之间可以交互。

            所谓服务的无状态，是指服务不依赖于任何事先设定的条件，是状态无关的(state-free)。在SOA架构中，一个服务不会依赖于其他服务的状态。 它们从客户端接受服务请求。因为服务是无状态的，它们可以被编排(orchestrated)和序列化(sequenced)成多个序列 (有时还采用流水线机制) ，以执行商业逻辑。编排指的是序列化服务并提供数据处理逻辑。但不包括数据的展现功能。
SOA的一些重要特征
           服务的封装(encapsulation)。将服务封装成用于业务流程的可重用组件的应用程序函数。它提供信息或简化业务数据从一个有效的、一致的状态向另一个状态的转变。封装隐藏了复杂性。服务的API保持不变，使得用户远离具体实施上的变更。

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

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

SOA的一些重要特征
           服务是自治的(Autonomous)功能实体。服务是由组件组成的组合模块，是自包含和模块化的。

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

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.

1，              CRM和ERP融合

(1)客户深度分析和数据挖掘

ERP：通过多角度查询，统计客户的发货记录，交易记录，应收帐款，客户毛利等，进行客户分析。

CRM：不具备独立此功能。

需要ERP扩展并融合这些功能。

对未交易的客户分析

ERP：软肋。现在的ERP软件基本上不具备这样的功能

CRM：对于未交易的客户信息管理，销售团队的管理，售前的营销活动管理等都是CRM的重点。

(2)CRM与ERP的融合

CRM与ERP或者进销存的融合的重点是客户基本资料的共享集成，潜在的客户一旦成交，就可以将潜在客户信息自动转入ERP系统中，而不用重复输入。

CRM要与ERP在财务、制造、库存、分销、物流和人力资源等连接起来，从而提供一个闭环的客户互动循环。这种集成不仅包括低水平的数据同步，而且还应包括业务流程的集成，这样才能在各系统间维持业务规则的完整性，工作流才能在系统间流动。这二者的集成还使得企业能在系统间收集商业情报。

2，              服务管理

ERP功能中薄弱的是客户服务、维修管理。

CRM为客户提供优质服务，让客户满意。主要体现服务功能：维修记录，客户回访记录，客户投诉记录等信息，可以方便查询这些记录。定期提醒客户回访周期，提醒产品保养周期，客户投诉记录在CRM系统中可以反馈给相关部门或者责任人。

3，              CRM与E-Commerce电子商务的融合

CRM软件系统与公司对外网站的联接，企业可以将网站上收集的潜在客户的信息、客户询价自动转入CRM系统，客户信息经过确认，正式启用;询价信息自动生成报价单;

企业信息自动发布在网站。企业可以将自己的动态信息，发布相关网站，当然，这要建立信息的行业标准，例如:如果建立了信息检索的互联网标准，搜索引擎的作用更大，更倾向于行业化、结构化。