企业应用_企业应用开发 - CSDN
精华内容
参与话题
  • 企业应用系统大全

    2020-05-15 15:07:13
    在企业规划信息系统中,需要了解到企业应用的名录。该文档描述了企业信息化常用的软件信息名录。
  • 什么是企业应用

    2019-08-22 18:17:00
    看到“企业应用“这次术语, 在你的下意识里,第一反应能想起哪些相关的词?我的条件反射是: ERP, CRM, HRM, BI, CMS ......企业应用这个词听起来...
        

    看到“企业应用“这次术语, 在你的下意识里,第一反应能想起哪些相关的词?

    我的条件反射是: ERP,  CRM, HRM, BI, CMS ......

    企业应用这个词听起来很高大上,  但是什么“企业应用”?  我发现我没法下一个准确的定义。

    回顾下我的工作经历, 应聘的时候似乎都是要做"企业应用" 开发。

    毕业后第一份工作就是做很热门的OA系统,就是所谓的办公自动化,包括了邮件、工作流、表单、文档系统等公司信息化需求, 用户肯定是部署OA的企业内部人士,算是最基本的企业应用开发吧。

    后来做了欧洲的税务系统,实现他们各种各种复杂的业务逻辑,用户也是税务局的员工, 应该是标准的企业应用。

    再后来做一个庞大的系统来支持公司的产品销售,用户既有公司的销售人员,也有外部的用户。 系统相当复杂, 由很多子系统组成,各个子系统还存在着复杂的关系, 接口五花八门,有的用Webservice , 有的用数据复制, 有的用MQ, 甚至还有邮件接口和FTP接口,  这应该也是一个典型的企业应用。

    似乎一个企业应用就是帮助企业干活的信息系统,满足企业日常运营,  帮助他们完成流程的信息化。

    人称软件教父的Martin Flower 非常善于抽象,   在著名的《企业应用架构模式》一书中他就针对企业应用抽象出这么几点:

    1. 企业应用一般涉及到持久化数据

    初一看似乎是废话: 如果数据不能持久化,应用也没什么意思了。

    实际上重点是企业数据的生存年限相当的长, 甚至比访问这些数据的程序都要长,无论硬件、操作系统、应用程序怎么变,数据都不能受到损害。

    2. 企业应用一般涉及大量数据

    这是毫无疑问的, 一个企业运行过程中绝对不仅仅产生几千,几万条数据。

    3. 企业应用涉及到很多人同时访问数据

    如果是内部系统还好, 要是对外的Web系统, 那用户量可能非常大。

    4. 企业应用涉及到大量的用户操作界面

    有几百个界面毫不为奇, 用户使用频率差异很大,特别是这些用户没有技术背景。

    5. 企业应用很少独立存在, 通常需要与散布在企业周围的其他应用进行集成。

    这些各种各样的系统是在不同时期, 用不同的技术构建起来的, 把他们集成起来的痛苦经历过的码农才知道。

    但是互联网应用像淘宝,京东商城是否属于企业应用的范畴?    Martin Flower并没有明确说明。互联网应用符合了上面的第2,3两点,  数据量巨大, 高并发访问, 技术上要求规模大、扩展性强、可靠性高 。

    既然难于区分,  我想不妨根据用户的不同, 分为两个大类:


    1. 面向企业用户

    ERP(企业资源规划),  CRM(客户关系管理) , HRM(人力资源管理),SCM(供应链管理), BI(商业智能) ,还有各种各样根据企业的需求做的定制软件(例如营销系统) 等应该属于这一类。

    这类应用的用户数不会像互联网应用那样特别巨大, 但是业务逻辑一般比较复杂, 为了实现这些变态的,多变的逻辑经常得付出巨大的代价。

    稍微大点的企业都会涉及到应用之间的集成问题, 这又是一个大坑。

    由于用户主要是企业内部人员, 直接用于企业的生产环境,  一旦出错, 整个公司的活动都可能受影响, 所以对可靠性, 稳定性要求较高。

    这类应用一般都是收费的,并且价格不菲。 既然是掏了真金白银, 系统出了故障,客户一般会怒气冲冲的跳起来找售后。

    2. 面向消费者用户

    电子商务、社交、娱乐、通信等互联网应用属于这一类,相比而言, 消费者对于出错的容忍度要高一点 :  你肯定不会因为微信发不了朋友圈而去找腾讯要赔偿, 最多骂几句而已。

    由于这类应用的用户量巨大, 高并发访问的特质, 即使是简单的业务逻辑,实现起来也很不容易, 例如从数据库读取信息然后展示, 如果是几十个人或者上百人访问,可能直接发出SQL查询数据库就搞定了;  如果有几万甚至几十万访问, 那非得搞一些缓存,分布式,页面静态化等技术来搞定了。  


    由于用户是直接的消费者, 产品的体验至关重要,用起来不爽, 用户马上用脚投票,分分钟抛弃你。


    当然这些互联网应用肯定有后台的管理系统,用来做运营、营销和数据分析, 这又属于第一类的范畴了。

    码农翻身相关历史文章推荐:


    Java EE

    我是一个线程

    我是一个Java class

    Java:一个帝国的诞生

    JDBC诞生记

    JDBC后传

    一个不安分的JDBC驱动

    JSP:一个装配工的没落

    Javascript: 一个屌丝的逆袭

    Spring本质系列(1) -- 依赖注入

    Spring本质系列(2) -- AOP

    Http 历险记(上)

    Http 历险记(下)—Struts的秘密

    三层架构和MVC那点事儿

    Java帝国之 Java Bean(上)

    Java帝国之 Java Bean(下)

    计算机网络

    我是一个路由器

    我是一个网卡

    TCP/IP之大明邮差

    TCP/IP之大明内阁

    TCP/IP之蓟辽督师

    张大胖的socket

    IE为什么把Chrome和火狐打伤了?

    对浏览器村的第二次采访

    节约标兵IE的自述

    EMail诞生记

    EMail诞生记(下)

    操作系统

    我是一个进程

    CPU阿甘

    CPU阿甘之烦恼  

    我是一个键盘

    我是一块硬盘(上)  

    我是一块硬盘(下)

    那些烦人的同步和互斥问题  

    冯·诺伊曼计算机的诞生

    数据库

    小李的数据库之旅(上)

    小李的数据库之旅(下)

    张大胖学数据库

    数据库村的旺财和小王

    你看到的只是冰山一角, 更多精彩文章,尽在“码农翻身” 微信公众号, 回复消息"m"或"目录" 查看更多文章

    有心得想和大家分享? 欢迎投稿 ! 我的联系方式:微信:liuxinlehan  QQ: 3340792577

    0?wx_fmt=jpeg

    公众号:码农翻身

    “码农翻身”公众号由工作15年的前IBM架构师创建,分享编程和职场的经验教训。

    展开全文
  • 几种企业应用集成方式的比较

    千次阅读 2017-12-29 10:36:03
    尤其是很多企业应用的系统,因为我们定义的很多子系统是为了解决某个特定的问题或者问题域,在后续随着业务的发展和变化对于系统也会有更多的集成要求。于是,集成主要有哪几种方式?他们各有什么特点呢?这些问题就...

    前言

         我们做过的大部分系统其实并不是自己从头开始设计和实现的,很多时候是基于现有的基础再做扩展或者和现有的系统集成。尤其是很多企业应用的系统,因为我们定义的很多子系统是为了解决某个特定的问题或者问题域,在后续随着业务的发展和变化对于系统也会有更多的集成要求。于是,集成主要有哪几种方式?他们各有什么特点呢?这些问题就一一的浮现出来。这里主要针对一些原来个人项目中接触过的问题,结合一些前人的经验做一个总结。

    企业集成要点

        通常来说,我们需要将多个应用系统集成起来是的他们之间能够相互交互。出于系统演化和需求变更的影响,由于系统的差异导致我们集成的时候面临的困难也比较繁杂。很多时候我们最开始在设计某些系统的时候根本就没有考虑到集成的需要。因此在集成的时候主要会考虑一下几个要点:

    • 应用耦合度:这一点也和软件工程中的基本设计思想是契合的。即我们要求系统之间的依赖达到最小化,这样当一个系统发生变化的时候也会对另外一个系统产生尽可能小的影响。也就是我们所说的松耦合。
    • 侵入性:当进行集成的时候,希望集成的系统和集成功能的代码都尽可能的变动小。
    • 技术选择:不同的集成方案需要不同的软硬件,这些牵涉到开发和学习的成本。
    • 数据格式:既然系统要集成,从本质上来说就相当于两个系统的通信。那么相互通信的系统就要确定交换的数据信息格式来保证通信的正常进行。我们接触过的SOAP, REST web service, CORBA等都有特定的消息定义标准。
    • 数据时间线:集成还有一个需要考虑的就是当一个系统将需要传递数据发送给另外一个系统的时候,他们传送时间要尽可能少。这样可以提升系统整体运行的效率,减少延迟。
    • 数据或功能共享:有的应用集成还考虑到功能的集成共享。这种功能的共享带来的好处是使得一个系统提供的功能在另外一个系统看来就好像是调用本地的功能一样。一些典型的应用集成比如说RPC(远程方法调用)就符合这种特征。
    • 远程通信:通常我们系统调用是采用同步的方式。可以在一些远程通信的情况下,采用异步的方式也有它的优点,比如说带来系统效率的提升。同时也使得系统设计的复杂度变大。
    • 可靠性:我们不仅仅是设计系统集成方案,就是在一些简单系统应用里面也会考虑到,如果某个部分出错了或者失效了该怎么办?有什么办法可以提高可靠性?

        OK,有了前面这些要点,我们再结合目前几种主要的集成方式来一一讨论吧。    

    文件传输(共享)

         文件共享传输的方式是一种我们能想到的很简单直观的办法。它的典型交互场景如下:

     

         在这种场景下,我们一个应用产生包含需要提供信息的文件,然后再由另外一个应用来通过访问文件获取信息。在这里,集成部分所做的事情主要是将文件根据应用的不同需要做格式的转换。考虑这种集成方式,我们有几个重要的问题需要考虑:

    • 文件的格式:考虑到不同应用系统传递消息的具体样式不一致,A应用产生的文件如果能够给B应用直接使用是最好的了。尤其是如果如果有B应用的原生支持,对于集成来说将大大提高效率。因此,我们一些常见的方法是传递XML或者JSON格式的文本。 当然,在一些UNIX系统里面也有通过纯TXT文本传递信息的。
    • 另外一个比较重要的问题就是什么时候产生文件,什么时候处理文件。因为我们一般都需要一定的时间来产生文件,我们不太希望文件产生的太频繁。而且,在一个应用产生文件的时候怎么保证另外一个应用这个时候不去修改它呢?如果文件产生完了怎么通知另外一个应用呢?还有就是,我怎么知道另外一个应用已经处理过我处理的文件了?我们产生的文件会不会有重名的冲突?文件被处理完之后该怎么办?删除它还是重复再应用?这些问题是在消息传输比较频繁时很容易发生的。这些问题的发生会导致两个应用系统之间信息的不同步或者信息的错误,这也是采用纯文件传输的弊端。
    • 当然,在一些应用场景之下,文件传输还是有其优点的。在一些信息交换不是很频繁,而且对于信息的及时性要求不太高的情况下,这种方式还是值得考虑的。我们可以采用一些timer job的方式来产生和消费文件。只要保证两者不产生冲突和他们正确的执行顺序。集成的效果还是可以达到的。另外,采用文件传输还有一个优点就是对于集成的系统来说它比较完美的屏蔽了集成的细节。每个系统只要关注符合标准格式的文件内容,具体实现和数据交换他们都不需要关心。 

    共享数据库

         还有一种集成方式也比较常见,就是共享数据库。在很多应用开发的场景下,我们的数据库是相对独立提供服务的一部分。所以对于其他系统的对接也就比较容易,这种集成的方式如下图:

        和前面文件共享传输的方案比起来,这种方案有一个相对的优势,就是可以保证数据的一致性。在原来的方案中,如果文件要传输给多个应用的话,我们是没办法保证所有应用的数据是同步而且一致的。有可能有的快有的慢。而在这里,所有的数据都是统一存储在公共的数据库里,也就不存在这样的问题了。对于任何一个系统产生的数据或者变化,另外一个系统也就马上可以看到。

         当然,这种方案也有它不足的地方。首先一个问题就是对于多个应用来说,这个共享数据库需要能够适应他们所有的场景。不同的应用考量的点是不一样的,要能适应所有的需求对于数据库这一部分就显得尤其的困难。还有一个就是性能方面的问题,不同的应用可能会同时访问相同的数据导致数据访问冲突,因此也会带来如死锁等问题。

         所以说,这种方案出现问题的根源在于用一种统一的数据模型来解决各种不同的应用需求是并不现实的。

     

    RPC(远程过程调用)

         远程过程调用的方法在早些年的时候也比较常见。典型的如Java的RMI。典型的应用场景如下:

         以典型的java RMI为例,当我们需要访问远程方法的时候,需要定义访问的接口,然后通过相关工具生成skeleton和stub。然后一端通过stub给另外一端发送消息。在应用A本地的代码中访问stub看起来还是和调用本地方法一样,这些细节都由stub给屏蔽了。其他的技术如COM, CORBA, .net Remoting都采用了RPC的思路。

        RPC的这种思路能够很好的集成应用开发。当然,由于这种机制也会带来一定的问题,比如说java RMI或者.net remoting。他们都局限于一个平台,好比说我应用A是用java做的,那么如果要和另外一个系统通过RMI集成的话,那个系统也必须是java做的。另外,他们其实还是一种紧耦合。我们RPC调用是用的一种类似于系统api的同步调用,当一端发出调用请求的时候会在那里等待返回的结果。如果另外一个系统出现故障也会对调用方产生很大影响。而且我们用RPC调用的时候默认期望消息是按照发送的顺序给接收方的。但是由于各种环境的影响会使得接收的结果乱序,这样也可能会导致系统执行出现问题。所以从可靠性来说还是存在着一定的不足。

    消息队列

         看来前面几种集成的方式,我们再来看看消息队列的方式。消息队列的集成方式如下图:

         所有应用之间要通信的消息都通过消息队列来传输,由消息队列来保证数据传输的异步性、稳定性等。总的来说,这看起来有点像网络连接结构。所有数据通过一条可靠的链路来进行通信。

        那么,这种集成方式有哪些特征呢?

    •     更好的应用解耦:像以往采用文件传输或者共享数据库的方式需要知道文件或者数据库在哪里。对于RPC的方式来说甚至要知道对方的IP地址才能进行方法调用。这样的依赖太强烈。而且还对开发运行平台也有依赖。而现在这种方式则是只要双方规定好通信的消息格式,各自都只要发消息给消息队列就可以了。这就好比是两个人写信,一个人只要把要写的内容整理好再交给邮局,剩下的事情他就不用操心,全让邮局给他办了。这样,不管对方是什么语言开发的系统,只要他们采用统一的消息格式,java开发的系统也就能够和C++, .net等平台的系统通信了。
    • 消息的可靠性:我们具体发送消息的任务相当于交给了消息队列。所有提交的消息有消息队列里的message router来投递。这有点像网络概念里的路由器一样,根据一个发送方指定的地址并转发到另外一个地方。同时,消息队列也根据不同的需要将消息进行持久化,这样保证消息在投递的过程中不会被丢失。
    • 系统可靠性:如果对消息队列和RPC的方式做一个对比,这就好比是生活中打电话和发短信的区别。在打电话的时候,我们是必须期望接电话的对方在电话旁边能够接收响应。而如果接收人不在或者忙的话,打电话的这一方就只能在这里干等。这就是系统不够健壮的地方,一旦另外一方系统出故障,系统就没法正常运作。而且要保证能够正常通信,需要系统双方都同时就位。而发短信的这种消息方式则不然,消息可以准确的送达到对方,如果对方暂时忙消息也会保存在那里。等有空的时候会进行回复。至少保证了有效信息的传递。这种特性也就是保证了系统的异步执行,从某种角度来说也提升了系统性能。

        综合上面的这些讨论,消息队列算是一种兼顾了性能、可靠性和松耦合的一种理想集成方式。目前实现消息队列的产品有很多,比如微软的MSMQ, 开源产品ActiveMQ, RabbitMQ, ZeroMQ等。后续的文章还会对消息队列的应用和内部机制做深入的分析。

    总结

         应用系统集成的方式有很多,最常见的几种有文件传输,数据库共享,远程方法调用以及消息队列。他们在解决某些特定领域的问题时有自己的特长。综合来说,消息队列算是一种比较理想的解决方案。不同事物或者不同领域之间也有很多的相似性,在研究消息队列的时候会发现他们和网络的体系结构思想非常相似。

    展开全文
  • 本书先介绍了一些企业应用开发的基础知识,比如分层架构、WEB表现、业务逻辑、数据库映射、并发、会话、分布策略等等。通过使用场景、解决方案、UML等手段详细介绍了设计模式(包括一些常用的设计模式GOF23和本书上...

     

    本书先介绍了一些企业应用开发的基础知识,比如分层架构、WEB表现、业务逻辑、数据库映射、并发、会话、分布策略等等。通过使用场景、解决方案、UML等手段详细介绍了设计模式(包括一些常用的设计模式GOF23和本书上新创的设计模式)。了解书中这些模式是干什么的、它们解决什么问题、它们是如何解决问题的。这样,如果你碰到类似的问题,就可以从书中找到相应的模式。可以为你节约成本、缩短项目周期时间、避免风险,以确保项目能够完美的完成。

     

    一、三个基本层次:表现层、领域层、数据源层

    层次

    职责

    表现层

    提供服务,显示信息(例如在WindowsHTML页面中,处理用户请求(鼠标点击、键盘敲击等),HTTP请求,命令行调用,批处理API

    领域层

    逻辑,系统中真正的核心

    数据源层

    与数据库,消息系统、事务管理器及其他软件包通信

    关于依赖性的普遍性原则:领域层和数据源层绝对不要依赖于表现层。

    一旦选择了处理节点,接下来就应该尽可能使所有代码保持在单一进程内完成(可能是在同一个节点上,也可能拷贝在集群中的多个节点上)。除非不得已,否则不要把层次放在多个进程中完成。因为那样做不但损失性能,而且增加复杂性,因为必须增加类似下面的模式,如远程外观和数据传输对象。

    复杂性增压器:分布、显式多线程、范型差异、多平台开发以及极限性能要求(如每秒100个事务以上)。

     

    二、领域逻辑

    领域逻辑的组织可以分成三种主要模式:事务脚本、领域模型、表模块。

    三者之间的区别:

    事务脚本是一个过程来控制一系列动作逻辑的执行。

    领域模型不再是由一个过程来控制用户某动作的逻辑,而是由每一个对象都承担一部分相关逻辑。这些对象可以看成是领域的不同组成部分。

    表模块只有一个公共的合同类实例,而领域模型对数据库中每一个合同都有一个相应的合同类的实例。

     

     

    三、映射到关系数据库

    在使用领域模型的时候,它的读取应该把相关联的对象也一块读出来。例如,读取一个合同,应该把合同涉及到的产品和定购厂商的对象加载到内存中。由时候为了避免这些没有必要的连带读取,我们可以使用【延迟加载】模型。

    读取数据的时候,性能问题可能回变得比较突出。这就导致了几条经验法则。

    1)、尽可能一次查询多个记录,不要一次查询一个记录,然后进行多次查询。可以一次查询多条相关的记录,例如使用联合查询。或者使用多条SQL语句。

    2)避免多次进入数据库的方法是使用连接(Join),这样就可以通过一次返回多个表。可以制作一个入口,让入口完成相关数据的一次性读取。

    3)数据库中进行优化。DBA来优化数据库。

    映射到关系数据库的时候,一般会遇到三种情况:

    1)  自己选择数据库方案。

    2)  不得不映射到一个现有数据库方案,这个方案不能改变。

    3)  不得不映射到一个现有数据库方案,但这个方案是可以考虑改变的。

    最简单的情况是自己选择数据库方案,并且不用迁就领域逻辑的复杂性。当已经存在一个数据库方案的时候,应该逐步建立领域模型并包括数据映射器,把数据保存到现有的数据库中。

     

    四、并发

    并发问题:更新丢失和不一致读。

    并发问题,人们提出了各种不同的解决方案。对于企业应用来说,有两个非常重要的解决方案:一个是隔离,一个是不变性。

    隔离是划分数据,使得每一片数据都可能被一个执行单元访问。比如文件锁。

    不变性是识别那些不变的数据,不用总考虑这些数据的并发问题而是广泛地共享它们。

    当有一些可变数据无法隔离的时候,会发生什么样的情况呢?总的来说,我们可以使用两种形式的并发控制策略:乐观并发控制和悲观并发控制。

    如果把乐观锁看作是关于冲突检测的,那么悲观锁就是关于冲突避免的。

    假如MartinDavid同时都要编辑Customer文件。如果使用乐观锁策略,他们两个人都能得到一份文件的拷贝,并且可以自由编辑文件。假设David第一个完成了工作,那么他可以毫无困难地更新他的修改。但是,当Martin想要提交他的修改时,并发控制策略就会开始起作用。源代码控制系统会检测到在Martin的修改和David的修改之间存在着冲突,因而拒绝Martin的提交,并由Martin负责指出怎样处理这种情况。如果使用悲观锁策略,只要有人先取出文件,其他人就不能对该文件进行编辑。因此,假如是Martin先取出了文件,那么David就只能在Martin完成任务并提交之后才能对该文件进行操作。

     

    多种技术处理死锁:一种是使用软件来检测死锁的发生。另一种是给每一个锁都加上时间限制,一旦到达时间限制,所加的所就会失效,工作就会丢失。

     

    软件事务经常使用ACID的属性来描述。

    原子性(Atomicity):在一个事务里,动作序列的每一个步骤都必须是要么全部成功,要么所有的工作都将回滚。部分完成不是一个事务概念。

    一致性(Consistency):在事务开始和完成的时候,系统的资源都必须处于一致的、没有被破坏的状态。

    隔离性(Isolation):一个事务,直到它被成功提交之后,它的结果才对其他所有的事务是可见的。

    持久性(Durability):一个已提交事务的任何结果都必须是永久性的,即“在任何崩溃的情况的能保存下来”。

    大多数企业应用是在数据库方面涉及到事务的,但还有很多情况要进行事务控制,比如说哦消息队列、打印机和ATM等。为了处理最大的吞吐率,现代的事务处理系统被设计成保证事务尽可能短,尽可能不让事务跨越多个请求;尽可能晚打开事务。

     

    五、分布策略

    按类模型进行分布的方法不可行的主要原因与计算机的基本特点有关。进程内的过程调用非常快。两个对立进程间的过程调用就慢了一个数量级。在不同机器间运行过程又要慢一两个数量级,取决于网络拓扑。

    本地接口最好是细粒度接口。但细粒度不能很好地用在远程调用中。分布对象设计第一定律:不要分布使用对象,大多数情况下是使用集群系统。

     

    六、一些关于具体技术的建议

    1、  JavaJ2EE

    企业级Java BeanEJB)的价值有多大,这个是JAVA世界中最大的争论。但是要构建良好的J2EE引用,其实并不需要EJB。使用POJO(普通Java对象)和JDBC同样能够完成这一任务。J2EE的设计选择随使用的模式不同而不同,同样,也受到领域逻辑的制约。

    2.NET

    .NETVisual Studio以及微软世界应用中,其中起决定作用的模式是表模块。.NET大力宣传Web Services,但是我不会在一个应用程序内部使用Web Services,而只会像Java中一样,使用它们作为一种允许应用集成的表现层。

    2、  存储过程

    3、  Web Services

        Web Services使得重用成为现实,并最终导致系统集成商的消失。

    4、  其他分层

     

     七、模式

     

    领域逻辑模式

    1、事务脚本:使用过程来组织业务逻辑,每个过程处理来自表现层的单个请求。

    事务脚本置于何处将取决于你如何组织你的软件层次,它可能会位于服务器页面、CGI脚本和分布式会话对象中。我喜欢尽可能的分离事务脚本。至少应当将它们放在不同的子程序中,而更好的方法则是将它们置于与其他处理表现层和数据源层的类相独立的类中。此外,绝不要让事务脚本调用任何表现层逻辑;这样会使我们容易修改代码和测试事务脚本。

    可以用两种方法来把事务脚本组织成类。一种是把多个事务脚本放在一个类中,每个类围绕一个主题将相关的事务脚本组织在一起。另一种方法则是每个事务脚本对应一个类,通过命令模式来完成消息传递。

    2、领域模型:合并了行为和数据的领域的对象模式。

    领域模型按照它的复杂程度分,可以分为:简单领域模型和复杂领域模型。简单的领域模型如【活动记录】,可以应对领域逻辑比较简单的系统。复杂的领域逻辑需要复杂的领域模型。

    3、表模块:处理某一数据库表或视图中所有行为的业务逻辑的一个实例。

    表模块以一个类对应数据库中的一个表来组织领域逻辑,而且使用单一的类实例来包含将对数据进行的各种操作程序。它与领域逻辑的主要区别在于,如果你有许多订单,领域模型对每一个订单都有一个对象,而表模块则只用一个对象来处理所有的订单。

    4、服务层:通过一个服务层来定义应用程序边界,在服务层中建立一组可用的操作集合,并在每个操作内部协调应用程序的响应。

     

     

    数据源架构模式

    1、表数据入口:充当数据库表访问入口的对象。一个实例处理表中所有的行。

    表数据入口包含了用于单个表或视图的所有SQL,如选择、插入、更新、删除等。其他代码调用它的方法来实现所有与数据库的交互。

    2、行数据入口:充当数据源中单条记录入口的对象,每行一个实例。

    3、活动记录:一个对象,它包装数据库表或视图中某一行,封装数据库访问,并在这些数据上增加了领域逻辑。

    4、数据映射器:在保持对象和数据库彼此独立的情况下在二者之间移动数据的一个映射器层。

    数据映射器是分离内存对象与数据库的一个软件层。其职责是在内存对象与数据库之间的传递数据并保持它们彼此独立。有了数据映射器,内存对象甚至不需知道数据库的存在;它们也不需要SQL接口代码,当然也不需要知道数据库方案。由于数据映射器是映射器的一种形式,因此数据映射器自身根本不为领域层所察觉。

     

    对象—关系行为模式

    1、工作单元:维护受业务影响的对象列表,并协调变化的写入和并发问题的解决。

    工作单元是一个记录这些变化的对象。只要开始做一些可能会对数据库有影响的操作,就创建一个工作单元去记录这些变化。每当创建、改变或者删除一个对象时,就通知此工作单元。

    工作单元的关键是在提交的时候,它决定要做什么。它打开一个事务,做所有的并发检查(使用悲观离线锁和乐观离线锁)并向数据库写入所做的修改。开发人员根本不用显式调用数据库更新方法。这样,他们就不必记录所修改的内容或者不必担心的引用完整性如何影响他们的操作顺序。

    2、标识映射:通过在映射中保存每个已经加载的对象,确保每个对象只加载一次。当要访问对象的时候,通过映射来查找他们。

    3、延迟加载:一个对象,它虽然不包含所需要的所有数据,但是知道怎么获取这些数据。

    实现延迟加载的四种方法:延迟初始化、虚代理、值保持器、重影。

     

    对象—关系结构模式

    1、标识域:为了在内存对象和数据库行之间维护标识而在对象内存的一个数据库标识域。

    数据库中通过主键来区分数据行,然而,内存对象不需要这样一个键,因此为对象系统能够保证正确的身份确认(在C++中是直接用原始内存位置)。

    2、外键映射:把对象间的关联映射到表间的外键引用。

    3、关联表映射:把关联保存为一个表,带有指向(有关联所连接的)表的外键。

    4、依赖映射:让一个类的部分类执行数据库映射。

    5、嵌入值:把一个对象映射成另一个对象表的若干字段。

    6、序列化LOB:通过将多个对象序列化到一个大对象(LOB)中保存一个对象图,并存储在一个数据库字段中。

    7、单表继承:将类的继承层次表示为一个单表,表中的各列代表不同类中的所有域。

    8、类表继承:用每个类对应一个表来表示类的继承层次。

    9、具体表继承:用每个具体类对应一个表来表示类的继承层次。

     

    对象—关系元数据映射模式

    1、元数据映射:在元数据中保持关系—对象映射的详细信息。

    元数据映射使开发者可以以一种简单的表格形式来定义映射,这些映射可由通用代码来处理,从而实现读取、插入和更新数据的细节。使用元数据映射最主要的决策是如何根据运行代码来表示元数据中的信息。有两种主要的途径:代码生成和反射编程。

    2、查询对象:描述一次数据库查询的对象。

    3、资源库:协调领域和数据映射层,利用类似于集合的接口来访问领域对象。

     

    WEB表现模式

    1、模型—视图—控制器(MVC):把用户界面交互分到不同的三种角色中。

    2、页面控制器:在WEB站点上为特定页面或者动作处理请求的对象。

     

    3、前端控制器:为一个WEB站点处理所有请求的控制器。

    4、模板视图:通过在HTML也面中嵌入标记向HTML发送消息。

    5、转换视图:一个视图,它一项一项地处理领域数据,并且把它们转换成HTML

     

    6、两步视图:用两个步骤来把领域数据转换成HTML。第一步,形成某种逻辑页面;第二步,把这些逻辑页面转换成HTML页面。

    7、应用控制器:一个用来处理屏幕导航和应用程序流的集中控制点。

     

    分布模式

    1、远程外观:为细粒度对象提供粗粒度的外观来改进网络上的效率。

    2、数据传输对象:一个为了减少方法调用次数而在进程间传输数据的对象。

    数据序列化

     

    离线并发模式

    1、乐观离线锁:通过冲突检测和事务回滚来防止并发业务事务中的冲突。

    2、悲观离线锁:每次只允许一个业务事务访问数据以防止并发业务事务中的冲突。

    3、粗粒度锁:用一个锁锁住一组相关的对象。

    4、隐含锁:允许框架或层超类型代码来获取离线锁。

     

    会话状态模式

    包括客户会话状态、服务器会话状态、数据库会话状态。

    通常使用数据传输对象来传输数据。数据传输对象可以在网络上序列化,因此,即使是很复杂的数据也可以传输。

    客户会话状态:将会话状态保持在客户端。客户会话状态有一定的优点。特别是支持无状态服务器对象,从而提高最大的集群性能和容错恢复。当然,如果客户崩溃了,它所有的会话数据就丢失了,但用户通常认为这合乎情理。对于安全问题,就要对传输的数据进行加密。

    客户数据传输:客户也需要存储数据。大客户的应用可以用自己的数据结构来存储。如果使用HTML,情况就复杂一些。一般有三种方法:URL参数、表单的隐藏域和Cookie

     

    服务器会话状态:将会话状态以序列化形式存放在服务器端。

    服务器会话里面最简单的一种方法是把会话数据放在应用服务器的内存中。可以将会话数据以会话标识号作为键标识存放在内存映射表中。只需要客户给出会话标识号,服务器就可以从映射表中取出会话数据。这种方法假设应用服务器有足够的内存处理,而且是只能有一个应用服务器,没有集群——如果这个应用服务器崩溃了,所有的会话数据就丢失得无影无踪。

    解决方案是将服务器会话状态序列化存放到数据库中,用一个以会话标识号为键值的表,表中需要有一个序列化LOB存放序列化后的会话状态。还要对作废的会话进行处理,尤其在一个面向顾客的应用中。一种方法是用一个监督进程检查并删除过期的会话,但这样会造成很多与会话表的连接。Kai Yu提供了他使用的一个好方法:将会话表分成12段,每两个小时轮换一次,轮换时先删除时间最旧的段中所有的数据,并把所有新的数据放到该段中。虽然这样会把那些超过24个小时的会话强制删除,但实际上不用去担心这样极少数的情况。

    实现举例:

    Java实现       最常用的服务器会话状态技术是使用HTTP会话或者使用有状态会话bean

    HTTP会话是让WEB服务器保存会话状态的一种简单方法。

    使用有状态会话bean,它需要一个EJB服务器。EJB容器负责持久和钝化处理,因此很容易实现。

    NET实现   服务器会话状态可以很容易地使用内建的会话状态功能实现。默认情况下,.NET将会话状态放在服务器进程内。也可以换成通过状态服务存取,可以在本地也可以在远程。如果使用远程的状态服务,可以在重启WEB服务器后依然使用原来的会话数据。通过在配置文件中指定是使用进程内方式还是使用状态服务,因此不必要修改应用程序。

     

    数据库会话状态是将会话数据作为已提交的数据保存到数据库中。

     

    基本模式

    1、  入口:一个封装外部或资源访问的对象。

    实际上这是一个十分简单的包装器模式。封装外部资源,创建一个简单的API,并用入口将对该API的调用转移到外部资源上。

    2、  映射器:在两个独立的对象之间建立通信的对象。

    映射器通常需要在层与层之间进行数据交换。这种数据交换一旦被激活,工作方式就是显而易见的。映射器的使用难点在于如何激活,因此你无法在被映射子系统中的任何一方直接调用它。有时可以使用一个第三方的子系统来完成映射并调用映射器。另一个可选的方案是让映射器成为某个子系统的观察者。通过监视子系统中发生的事件,映射器就可以调用了。

    3、层超类型:某一类型充当一层中所有类型的超类型。

    某一层中所有的对象都具有某些方法,但你并不希望这些方法在系统内被多次复制而产生冗余代码。此时你可以将这些行为移到一个通用的层超类型中。

    4、分离接口

    在一个包中定义接口,而在另一个与这个包分离的包中实现这个接口。

     

    5、  注册表

    一个众所周知的对象,其他对象可以通过该对象找到公共的对象和服务。

    6、  值对象:一个如货币或日期范围这样的小而简单的对象,判断时并不根据标识ID

    在由多种类型对象组成的对象中,区分引用对象和值对象是有用的。二者之中值对象通常规模小一些;它类似于许多非纯粹面向对象程序设计语言中的原始类型。通常来说,我们倾向于认为值对象是小对象,如货币对象或日期对象;而引用对象是大的对象,如订单或顾客。

    7、  货币:表示一个货币值

    面向对象的程序设计使你可以通过创建一个处理货币的货币类来解决货币与金额(小数点)这类问题。令人感到奇怪的是,居然没有任何主流的类库提供这个类。

    创建一个货币类,在其中保存金额和币种,可以以整数或定点小数的方式来保存金额。

    8、  特殊情况:针对特殊情况提供特殊行为的子类。

    9、  插件:在配置时而非编译时的连接类。

    10、服务桩:在测试时移除对有问题服务的依赖。

    企业级系统通常要依赖于第三方服务(例如信用评分、税率查询和价格引擎)的访问。有这类系统开发经验的开发人员都知道:如果依赖于完全不受自己控制的外部资源,通常会使软件项目受挫。第三方服务的特性是不可预知的,而且这些服务通常是远程的,因而软件性能和可靠性也会受到损害。

    这种依赖关系可能会导致测试无法进行,从而使得开发周期成倍增长。在测试时,用运行在本地的、快速的、位于内存中的服务桩来代替服务将会改善你的开发经验。

    当你发现对某一特定服务的依赖妨碍你的开发和测试时,就应当使用服务桩。许多XP的实践者使用术语“模拟对象”来代替服务桩。
    11
    、记录集:表格数据在内存中的表现方式。
       

    记录集模式的思想是通过一个内存中数据结构来提供解决这一问题的完整方案,该数据结构看起来与SQL查询的结果极为类似,但是它可以由系统中其他部件来生成和操控。

    记录集通常无需你亲自创建,而是由所有软件平台的销售商提供。ADO.NET中的data setJDBC2.0中的row set都是记录集的例子。

    目前有一种内存数据库sqlite,读取访问速度很快,有兴趣的可以研究,是开源的。

     

    展开全文
  • 企业应用集成之初学乍练

    千次阅读 2018-04-11 15:56:37
    企业应用集成(EAI)的需求企业不断发展,很多长期需要人为操作或者流程定制来处理的业务问题,为了提高效率会考虑引入软件应用系统来解决,比如,CRM(客户管理管理)系统,SCM(供应链管理)系统,ERP(企业资源...
    撸主:


    阿木   岂安科技项目经理


    基础开发出身,目前主要负责岂安产品的项目资源规划和过程管理。




    企业对应用集成(EAI)的需求


    企业不断发展,很多长期需要人为操作或者流程定制来处理的业务问题,为了提高效率会考虑引入软件应用系统来解决,比如,CRM(客户管理管理)系统,SCM(供应链管理)系统,ERP(企业资源计划)系统等。引入这些系统在当时是解决了一部分的问题,但是随着应用系统数量的增加,新的问题也慢慢暴露了出来。因为,每个应用系统都有不同的开发需求前提和问题背景,系统之间数据也是相互孤立;所以在企业内部,每个应用系统其实就是一个“孤岛”,相互之间没有畅通的信息交流与数据共享。于是经过一段时间之后新的问题就出现了:比如,信息和数据的更新的不同步甚至不一致的问题,更严重的是给客户也经常提供一些前后不一致的信息,导致客户无法接受,这会严重影响到企业的形象和信誉。



    企业要解决这些矛盾,一种办法是对现有系统推倒重来:将企业引入的各个信息系统全部更新成一个统一的管理系统,并要求各个部门都在这个统一的系统上工作(如:整个企业的所有应用都在一个ERP系统上运行),但考虑到成本、实施周期和难度因素,这不是一种切实可行的解决方案。还有另一种办法,就是企业从整体来考虑整个信息系统,根据实际需要,对各个应用系统进行总体规划,选择一个合适的集成平台,把企业的各个“信息孤岛”合理的集成起来。这种解决方案不管是从实施难度,还是从实施成本、周期和技术上考虑都是切实可行的。



    什么是企业应用集成(EAI)


    一般的应用系统是属于独立完成一项应用的软件产品,比如:ERP系统、OA系统、库存管理系统、人事管理系统等等;而系统集成是指将两种、甚至多种类型的应用系统通过二次开发将他们互相集成在一起,可以进行信息资源的共享和相互调用,比如将库存管理系统和ERP系统进行集成后,管理员可以通过ERP系统方便地查看物料零件的当前库存和标准价格等信息;而ERP系统也可以直接将库存管理统中单个零件清单和入库、出库、货品盘点操作等信息自动进行导入,以提高工作效率。


    图源百度



    企业应用集成(EAI)的分类


    关于企业应用集成,可以从深度和广度两方面来理解,然后进行分类。

    从集成广度来看:

    ✦部门内部集成到部门间的集成

    ✦企业范围内和企业间的集成


    部门内部集成到部门间的集成可以理解为一个商业实体(企业)的信息系统进行业务应用集成,比如酒店各部门之间消费的统一结算、直销企业的网上订单到送货的后台过程;但当在多个企业系统之间进行商务交易的时候,也可以表现为不同企业实体之间的企业系统集成,例如跨行信用卡在ATM上的互通、超市与供应商间的电子数据交换。


    从集成深度上理解,企业应用集成应该还可以归类为:数据集成、业务集成、应用集成三大类。


    数据集成


    数据应用集成是企业实施EAI的基础。数据集成的目的是将不同的数据库集成起来,提供一种单一的虚拟数据库,这样就不会出现与核心业务不一致的多个数据库。数据集成直接和企业应用系统的数据库打交道,对数据库进行直接的读写操作。数据层的集成可能是EAI里相对简单的一种集成技术。再简单点理解,就是将企业的签约客户信息与财务的合同收款记录在数据库的基础上打通,保持一致性。




    应用集成


    应用集成主要是指通过应用接口对应用系统实现集成。应用接口(API)是指应用系统以及客户自建系统为方便和外部应用系统连接而对外开放的软件接口。目前市场上的一些标准商业软件,例如ERP系统,CRM系统,电子商务系统等,为了更好的满足企业应用集成的市场需求,都有非常成熟的API。






    业务集成


    业务集成是将不同单位部门的不同业务流程利用应用集成技术集成在一起,实现跨部门、跨系统、跨企业的流程共用。




    企业应用集成(EAI)的目标


    目前企业应用面临着:多对多的数据交换,牵一发动全身商业逻辑多出重复,浪费开发资源;难以进行业务修改,无法快速推出新产品,新业务;开发质量难以控制等问题。所以,企业需要实现应用集成,马上就可以降低IT成本。因此,可以认为采用企业应用集成的主要目的就是:


    • 实现符合业务流程需要的信息交互。

    • 满足企业实施并行工程和经营过程重组的扩展需要。

    • 充分利用已有资源,通过实现已有应用系统的集成和封装保护企业过去在信息化建设上的投资。

    • 实现应用逻辑和过程逻辑的分离及过程建模与具体数据、功能的分离,支持在不修改功能的前提下,通过修改过程模型来完成集成系统功能的改变,以提高企业的灵活性和反应能力。



    企业应用集成(EAI)的步骤


    1. 业务模式分析

    2. 企业现状分析

    3. 确定集成策略

    4. 确定集成技术架构

    5. 统一元数据标准

    6. 分析关键集成店

    7. 制定实施计划

    8. 分步骤实施

    9. 不断优化


    一般应用集成实施步骤图



    采用企业应用集成(EAI)给企业带来的好处


    企业应用集成就是将企业内部已经引入的“信息孤岛”连接起来,实现数据共享和业务流程的共享,可为企业带来以下一些好处:


    充分利用企业已有的信息系统,保护企业在信息资源方面的投资


    企业的信息资源不仅包括大家所熟知的企业各类数据还包括企业的管理与决策模式,而这种管理方式体现在电子化上就是企业的各类信息系统(例如:ERP,MIS,财务,销售,SCM等),这些资源是企业花费了大量资金与心血组建起来的。企业应该充分利用好现有的信息系统和数据资源,将这些分离的“信息孤岛”连接起来,避免信息重复多次输入,减少信息存在的冗余,消除大量的垃圾信息,保证信息交流的一致性,保证部门之间进行信息共享,方便领导统揽全局。 



    优化企业内部的业务流程


    1. 利用EAI技术可简化企业内部的信息流,可以将企业传统的业务流程通过信息技术进行整合,实现企业内部业务流程自动化。

    2. 利用EAI技术减去不必要的数据重复输入,简化企业内部流程。

    3. 利用EAI技术可以将分散在企业内部不同地方的数据进行汇总,为领导决策提供服务。



    总结


    随着时代的发展,企业迫切需要把自身业务精简化、自动化,使得内部业务直接实现无缝对接,所有应用系统之间的集成将成为企业信息化系统发展的最终目标



    附录:关键词


    关键词:信息系统、信息系统集成、应用集成、企业应用集成


     信息系统

    是用信息化的手段将业务逻辑固化,是人、设备、应用软件、操作环境、业务流程的集合体。


     信息系统集成

    是根据应用的需求,将硬件产品、网络设备、系统软件、工具软件以及相应的应用软件等集成为一个具有优良性能价格比的计算机系统的全过程。


     应用集成

    是遵循规范的开放标准,并用技术手段通过系统间的功能交互,实现之间的信息交互。


     企业应用集成

    实现企业多个应用系统构建之间的协同,将孤立到的应用过程集成起来,形成一个面向需求的、协调的、高度伸缩的、集成的企业信息系统。

    展开全文
  • 在kevin的专栏看到从个人软件到企业软件一文,主要从...沿着这个思路,我们可以对“企业应用和个人应用的区别”这个问题得出另一层面的认识。 我们首先设定一下立场:从软件的应用对象、目标及用户角度去探讨,而不是
  • python 应用领域介绍 Python作为一种功能强大且通用的编程语言而广受好评,它具有非常清晰的语法特点,适用于多种操作系统,目前在国际上非常流行,正在得到越来越多的应用。 下面就让我们一起来看看它的强大功能...
  • 轻量级Java EE企业应用实战(第3版) 代码

    千次下载 热门讨论 2020-07-30 23:30:44
    轻量级Java EE企业应用实战(第3版) 的所有源码(随书光盘中提出),因上传空间问题将所有jar包提出放在“libs”目录下,如果用哪个可以自己找一下。内有readme.txt自己看下。 急用的兄弟下吧!
  • Spring 3.x 企业应用开发实战(含CD光盘1张)  陈雄华,林开雄著 ISBN978-7-121-15213-9 2012年2月出版 定价:90.00元(含光盘1张) 16开 728页 宣传语:10年技术专家邀您共享Spring饕餮盛宴 内 容 简 介 ...
  • 企业应用集成架构和ESB

    千次阅读 2011-05-25 17:09:00
     首先要说的是本文参考了《Service.Oriented.Java.Business.Integration》一书,对于企业应用集成和ESB,这是一本不错的书,它的第一章《Why Enterprise Service Bus》对企业应用集成面临的问题有一个真切地...
  • 今天升级了iOS7.1后发现通过之前的url无法安装企业应用了,一直提示“无法安装应用程序 因为http://xxx.xxx.xxx证书无效”,折腾了一番,终于在StackOverFlow上找到了答案。在这里分享给大家。
  • 浅谈企业应用集成的三个层次

    千次阅读 2012-11-22 19:35:38
    企业应用集成是为了提高管理效益,而不是仅仅追求技术的先进性,只有把握集成的度,分层次考虑,才能提高集成的效益。 早些年企业在信息化方面的一穷二白不同,最近两三年我所遇到的咨询客户,都有一些共性,一...
  • 轻量级Java EE企业应用实战(第4版):Struts 2+Spring4+Hibernate整合开发(含CD光盘1张)(国家级奖项获奖作品升级版,四版累计印刷27次发行量超10万册的轻量级Java EE经典著作) 李刚 编著  ISBN 978-7-121-...
  • Java企业应用开发框架Spring框架简介

    千次阅读 2017-07-12 15:56:05
    Spring是一个开源的轻量级的Java企业应用开发框架,其初衷是为了替代当时非常笨重的Java EE(当时还称为J2EE)组件技术EJB(Enterprice Java Beans),让Java EE开发更加简单灵活。 Spring起源于Rod Jahnson 2002...
  • C#实现企业应用接入钉钉

    千次阅读 2020-05-04 21:44:53
    现在钉钉已经成为中国企业进入智能移动办公时代的一种新型工作方式,同时钉钉也允许企业将自身系统接入钉钉,更多的包容性、同样的快捷性,为钉钉赢来了越来越好的口碑。 前段时间我们公司就将内部系统接入到钉钉...
  • 互联网+时代的企业应用集成平台

    千次阅读 2017-11-28 12:58:26
    在互联网+时代,企业中的业务人员将面临比以往更加复杂的信息化环境,不仅仅是以往经常使用的那些业务系统,还包括部署在云端的应用系统,与各种设备和货物关联的物联网,更加贴近客户的移动和社交网络等等。...
  • “第三方企业应用”->“小程序”,点击"创建应用"。 如图实例: 第二步:如下图(框起来的信息都要填写完成后,点击下一步) (注意:应用类型分为“测试应用”和“正式应用”,选择后不能进行修改,测试应用不...
  • 《Spring 3.x 企业应用开发实战》源代码下载

    千次下载 热门讨论 2020-07-21 10:00:10
    本光盘内容包括《Spring 3.x 企业应用开发实战》一书部分章节的源代码及第18章、第19章的电子版本。 Spring 3.0是Spring在积蓄了3年之久后,隆重推出的一个重大升级版本,进一步加强了Spring作为Java领域第一开源...
  • 企业应用架构之分层 - 总结

    千次阅读 2015-04-14 21:35:44
    总结了3中企业应用架构分层中常见的3种分层。
  • 详解前端应用开发中涉及的Ext JS/jQuery/XMLHttpRequest等技术,将Ajax融入轻量级Java EE开发,深入介绍Ajax+Java EE整合开发的方法和步骤,对实际开发具有极好的指导意义。
1 2 3 4 5 ... 20
收藏数 964,713
精华内容 385,885
关键字:

企业应用