今天完成的事情：

1.开始任务九，先是看一些概念

（1）SCA

1）SOA标准----------SCA架构思想

上图中显示的各个组成部分：

‍‍服务（Service）：用来让其他组件调用。是一个接口，类似于Java的Interface

组件实现（Implementation）：实现上面所创建的服务，类似于Java的接口的实现类

引用（Reference）：一个组件可能需要调用其他组件，需要创建一个其他组件的引用。

属性（Properties）：对组件实现的一种属性参数的注入‍‍

2）‍‍SCA的目标：‍‍

‍‍很好的集成现有的系统；

服务组件与传输协议的绑定达到一定的松散耦合，服务组件可以自由的选择传输协议，从而达到服务组件的最大可重用性。‍‍

3）SCA的优势

组件之间处于一种松散耦合的状态，不需要在自己的代码中加入对方组件的接口代码不需要指导对方的技术系统，在组件客户端的调用程序中不能有任何和具体技术相关的接口。

4）‍‍SCA与JBI的异同

相同点：
目的是一样的：都是为了集成。
大致方向一样：都是为了将服务和传输协议解耦。
不同点
SCA以接口作为切入点，从组件接口层将传输协议和接口实现解耦，是从编程的角度出发，一种全新的编程模型。
JBI是以请求消息和相应消息作为切入点，在集成时将消息和传输协议解耦，形成一种与传输协议无关的标准消息，这样形成一种全新的区别于现有应用服务器的集成容器，是从容器的角度出发，一种全新的容器模型。

‍

‍‍（2）SOA

1）面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。‍‍

2）面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

    SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集）/Web Service技术之后的自然延伸。

     SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。

     SOA在Java领域有两套标准：一个是SUN推出的JBI（没有得到BEA和IBM的承认），另外一个是：IBM和BEA等公司推出的SCA和SDO标准。

（3）JBI

‍‍JBI（Java Business Integration，Java业务集成，Java业务整合）是一种企业服务总线(Enterprise Service Bus,ESB)，使我们能够用Java实现面向服务的架构。企业正转向以面向服务架构（SOA）和网络服务，以提供灵活的IT系统，用一种成本低廉的方式来支持快速变化的商业需求。‍‍

‍‍JBI目的主要是在于创建一个可以集成各种‍‍‍‍‍‍组件服务的运行环境，当然这也是一种服务总线思想的体现。

目前流行的服务容器有Servlet容器、EJB容器、JMS容器。

1. Servlet容器只能处理以HTTP/SOAP协议传输的消息（接收与响应）；

2. EJB容器只能处理RMI协议传输的消息；

3. JMS容器则处理的是JMS协议传输的消息；

它们之间无法进行通讯，如果想集成上面不同类型的容器服务，则必须有一种能融合以上不同容器的新容器出现。JBI就是基于解决这种问题的思路出现的，JBI提供了各种各样的容器绑定组件（Binding Component,称BC）,而BC专门负责接收各种各样的传输协议的消息与发送请收消息给外部容器。当然JBI还提供其它的功能。

‍‍‍‍‍‍‍‍（4）EJB

‍‍EJB是sun的JavaEE服务器端组件模型，设计目标与核心应用是部署分布式应用程序。简单来说就是把已经编写好的程序（即：类）打包放在服务器上执行。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。EJB (Enterprise JavaBean)是J2EE(javaEE)的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具(SDK)。 在J2EE里，Enterprise Java Beans(EJB)称为Java 企业Bean，是Java的核心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDriven Bean）。在EJB3.0推出以后，实体Bean被单独分了出来，形成了新的规范JPA。‍‍

‍‍2.跑计算器的一个demo

明天计划的事情：

跑通分布式项目，结束任务九

遇到的问题：

1.自己写的demo一直会报错，然后也找不出来原因，最后通过跑通的项目回顾，应该是配置文件那边的问题，因为这个demo其实就接口和实现，然后加一个配置文件，所以应该就是配置文件出错了。

这个问题已搞定。

2.还有这个jar包的问题，无从着手，看到任务是，只有SCA，然后中央仓库里面涉及的很多。

如果不看师兄们的代码的话，感觉都不知道怎么找jar包，子啊加上资料少，难度很大。今天报错也有一部分问题是由于jar包的事。

‍‍收获：‍‍

1.初步了解了SCA架构。

2.还是晚上安静的环境比较适合学习（如果没有bug的话）

对比今天的计算器项目，梳理了一遍思路。

相对于RMI，这个就相对于多了个service组件的东西，相对于整合的概念，将一些方法整合到一起，定义一个接口，然后再定义一个实现。

接着在总实现类里面，通过@Reference来实现调用其他组件（demo中就写的简单，知识分出去了一些方法，重新调用，比较好理解点）。

最后就是客户端直接通过配置文件启动服务，并且实例化我们的‍实现类‍。这个是通过我们定义的配置文件名称来getService的。

配置文件中也是相应的要@Reference来实现调用其他组件。

然后通过这种思路解决了今天报了一天错的项目：

MyDemo01.composite这是配置文件名，通过它启动服务。

标记出的就是一直没发现的错误，这里应该是得到实现类，而不是接口。

另外九四Node的接口类要和NodeFactory都是在node下面的，所以在写的时候别选错了，因为有很多相似的，不过写错以后是没有start()方法的。

然后另外一大出错点，配置文件：

然后可以通过箭头指向很明显看出来，启动的服务名称我们第一的“demo1”；

它的class很明显是组件的实现类，所以在客户端的时候是“实现类.class,demo1”这样实例化对象；

第二个箭头就是调用其他组件的写法，以后无论怎么加，其他组件都是这么加，当然对于的接口，实现类，调用都要在程序里写全，不仅仅是写在配置文件里。