圣达云一卡通系统采用B/S架构， 依托当前一卡通产品为基础，为客户提供的包含门禁、考勤、楼宇对讲、梯控、停车场、通道等功能在内的信息化解决方案。智能一卡通管理平台对梯控,停车场,门禁,消费,考勤,在线巡更等子系统进行集中统一管理，对人员、卡片进行统一规划和编辑、变更等操作，通过集中授权，实现对一张卡片授权使用多个子系统，中心一次授权，无需到每个子系统再次授权。集停车场、门禁、巡更、考勤、消费、电梯控制等多项功能于一卡；将各子系统信息集中于一个管理平台，统一对卡片的发行、授权、挂失、补发、终止、延期等进行管理；一旦变更用户信息，则各个系统的用户信息同时改变，实现信息资源共享。

在智能云一卡通应用中，有大量的第三方应用可以接入，如移动千里眼业务、移动OA办公系统、移动企业混合云业务、移动班班通业务、移动智能停车车检器功能、移动智能停车系统等。

常用的接口实现方式有socket方式和Web Service接口。

socket方式

概念：

socket通常也称作"套接字"，用于描述IP地址和 端口，是一个通信链的句柄。在Java环境下，Socket编程主要是指基于TCP/IP协议的网络编程。何谓socket如计算机，顾名思义即是用来做计算。因而也需要输入和输出，输入需要计算的条件，输出计算结果。这些输入输出可以抽象为I/O（input output）。Unix的计算机处理IO是通过文件的抽象。计算机不同的进程之间也有输入输出，也就是通信。因此这这个通信也是通过文件的抽象文件描述符来进行。在同一台计算机，进程之间可以这样通信，如果是不同的计算机呢？网络上不同的计算机，也可以通信，那么就得使用网络套接字（socket）。socket就是在不同计算机之间进行通信的一个抽象。他工作于TCP/IP协议中应用层和传输层之间的一个抽象。如下图：

协议：

在TCP/IP协议中IP层主要负责网络主机的定位，数据传输的路由，由IP地址可以唯一地确定Internet上的一台主机。而TCP层则提供面向应用的可靠（tcp）的或非可靠（UDP）的数据传输机制。TCP是Tranfer Control Protocol的 简称，是一种面向连接的保证可靠传输的协议。通过TCP协议传输，得到的是一个顺序的无差错的数据流。发送方和接收方的成对的两个socket之间必须建 立连接，以便在TCP协议的基础上进行通信，当一个socket（通常都是server socket）等待建立连接时，另一个socket可以要求进行连接，一旦这两个socket连接起来，它们就可以进行双向数据传输，双方都可以进行发送 或接收操作。UDP是User Datagram Protocol的简称，是一种无连接的协议，每个数据报都是一个独立的信息，包括完整的源地址或目的地址，它在网络上以任何可能的路径传往目的地，因此能否到达目的地，到达目的地的时间以及内容的正确性都是不能被保证的。

服务器通信：

socket保证了不同计算机之间的通信，也就是网络通信。对于网站，通信模型是客户端服务器之间的通信。两个端都建立一个socket对象，然后通过socket对象对数据进行传输。通常服务器处于一个无线循环，等待客户端连接：

TCP三次握手：

python代码写套接字很简单。传说的TCP三次握手又是如何体现的呢？什么是三次握手呢?

第一握：首先客户端发送一个syn，请求连接，

第二握：服务器收到之后确认，并发送一个syn ack应答

第三握：客户端接收到服务器发来的应答之后再给服务器发送建立连接的确定。

这样就建立了一个TCP连接会话。如果是要断开连接，大致过程是：

上图也很清晰的表明了三次握手的socket具体过程。

客户端socket对象connect调用之后进行阻塞，此过程发送了一个syn。服务器socket对象调用accept函数之后阻塞，直到客户端发送来的syn，然后发送syn和ack应答。客户端socket对象收到服务端发送的应答之后，再发送一个ack给服务器，并返回connect调用，建立连接。服务器socket对象接受客户端最后一次握手确定ack返回accept函数，建立连接。

至此，客户端和服务器的socket通信连接建立完成，剩下的就是两个端的连接对象收发数据，从而完成网络通信。

优点：

1、实时性高

2、效率高，传输的过程中对于带宽基本没有浪费

缺点：

1、多线程及大并发实现起来较复杂

2、接口协议较复杂，技术门槛相对较高

3、问题定位较复杂。

Web service方式

概念：

Web service是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。

Web Service技术， 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件， 就可相互交换数据或集成。依据Web Service规范实施的应用之间， 无论它们所使用的语言、 平台或内部协议是什么， 都可以相互交换数据。Web Service是自描述、 自包含的可用网络模块， 可以执行具体的业务功能。Web Service也很容易部署， 因为它们基于一些常规的产业标准以及已有的一些技术，诸如标准通用标记语言下的子集XML、HTTP。Web Service减少了应用接口的花费。Web Service为整个企业甚至多个组织之间的业务流程的集成提供了一个通用机制。

Web Service技术支持：

Web Service平台需要一套协议来实现分布式应用程序的创建。任何平台都有它的数据表示方法和类型系统。要实现互操作性，Web Service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。这些协议有：

XML和XSD：

可扩展的标记语言（标准通用标记语言下的一个子集）是Web Service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既与平台无关，又与厂商无关。XML是由万维网协会(W3C)创建，W3C制定的XML SchemaXSD定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。

Web Service平台是用XSD来作为数据类型系统的。当你用某种语言如VB. NET或C#来构造一个Web Service时，为了符合Web Service标准，所有你使用的数据类型都必须被转换为XSD类型。如想让它使用在不同平台和不同软件的不同组织间传递，还需要用某种东西将它包装起来。这种东西就是一种协议，如SOAP。

xml web service

SOAP：

SOAP即简单对象访问协议(Simple Object Access Protocol)，它是用于交换XML（标准通用标记语言下的一个子集）编码信息的轻量级协议。它有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码成为XML对象的规则，执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。例如，你可以使用SMTP，即因特网电子邮件协议来传递SOAP消息，这可是很有诱惑力的。在传输层之间的头是不同的，但XML有效负载保持相同。

Web Service希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于Web无缝集成”的目标。

WSDL：

Web Service描述语言WSDL就是用机器能阅读的方式提供的一个正式描述文档而基于XML（标准通用标记语言下的一个子集）的语言，用于描述Web Service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。

UDDI：

UDDI的目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够发现的访问协议的实现标准。

调用RPC与消息传递：

Web Service本身其实是在实现应用程序间的通信。我们有两种应用程序通信的方法：RPC远程过程调用和消息传递。使用RPC的时候，客户端的概念是调用服务器上的远程过程，通常方式为实例化一个远程对象并调用其方法和属性。RPC系统试图达到一种位置上的透明性：服务器暴露出远程对象的接口，而客户端就好像在本地使用的这些对象的接口一样，这样就隐藏了底层的信息，客户端也就根本不需要知道对象是在哪台机器上。

Web Service软件支持：

操作系统离不开丰富的应用软件的支持。同样，Web Service这项技术只有通过日益广泛的应用才能体现出其价值，比较流行的实现方法是使用.NET和Java两种技术，并且两种实现方法可以互相操作；如今我们已经可以看到使用微软、Oracle、SUN、Borland等不同厂商的Web Service构建工具建立的Web Service应用。

微软.NET：

微软的.NET技术应该算是时下最为流行的Web Service开发技术。首先因为其公司在以前相应的产品就占有相当大的市场份额，以至使新推出的.NET得以有比较稳定的用户群；其次也是更重要的是.NET平台不仅延续了微软一贯的编程风格，而且还增加了许多支持Web服务的关键性技术，使得.NET在操作的简单性和执行的稳定性，高效性上达到了一个非常好的结合。

微软的Visual Studio. NET便是一个便于Web服务的开发工具。微软的目标是，将其新编程语言——C#作为Web Service的首选语言。虽然C#看起来与Java类似，但是还有一些Java中没有的独特的功能。.NET技术中用于Web Service开发的主要工具是ASP. NET。从技术上说，ASP. net提供了一些超出ASP以前版本的优点(例如：代码和HTML（标准通用标记语言下的一个应用）的分离，与脚本语言相比较，对“真正”的编程语言如C#的支持)。

IBM的WebSphere：

IBM公司是业界第一家能够提供全面支持Web服务的电子商务基础设施中间件的公司。通过多年来与W3C(The World Wide Web Consortium)的共同努力，包括DB2、Lotus、Tivoli和WebSphere在内的所有IBM软件都实现了对SOAP、WSDL、UDDI、Linux、XML（标准通用标记语言下的一个子集）、J2EE等开放技术和标准的全面支持。

IBM公司的WebSphere也是比较好的基础架构软件开发平台。WebSphere软件平台及开发工具包括WebSphere Studio Application DeveloperWSAD基于J2EE、XML和Web服务等开放标准，并具备IBM在可靠性、扩展性和安全性上的主要优势。WebSphere是IBM在Web Services策略中的核心平台，它支持所有开发、发布、部署Web Services应用所必需的开放标准和技术，包括UDDI，SOAP，J2EE，WSDL，和对XML技术集成的增强，这使得它在全球有很多用户。

Borland的Jbuilder：

Borland公司在JBuilder7中，用户可以用其Borland Web Services Kit for Java和Borland JBuilder MobileSet 3进行更快捷地开发Web Service和无线应用。这样将使开发者能够在同一个开发环境中轻松地创建和集成Web Service。新推出的JBuidler8更是针对Web Service开发更提供了方便和高效的方法。

总之，在Web Service开发上，.NET和Java都是很好的选择，尽管两者都有一些需要完善的地方，但是它们还是最好的开发手段和技术。具体选择哪种开发工具，也是仁者见仁，智者见智的问题。从根本上说，这两种方法没有孰优孰劣的问题，只是根据使用者对这两种方法的掌握程度和对具体语言的偏爱程度来决定。

Web Service应用：

Web service到底是什么；在什么情况下你应该使用Web service。

研究一下当前的应用程序开发，你会发现一个绝对的倾向：人们开始偏爱基于浏览器的客户端应用程序。这当然不是因为客户端能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户端和服务器之间通信的问题。

传统的Windows客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。在我看来，结果就是一个发布容易，但开发难度大而且用户界面极其受限的应用程序。极端的说，就是你花了更多的资金和时间，却开发出从用户看来功能更弱的应用程序。不信？问问你的会计师对新的基于浏览器的会计软件有什么想法：绝大多数商用程序用户希望使用更加友好的Windows用户界面。

关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用HTTP协议。同时，当前许多防火墙也配置为只允许HTTP连接。

许多商用程序还面临另一个问题，那就是与其他程序的互操作性。如果所有的应用程序都是使用COM或.NET语言写的，并且都运行在Windows平台上，那就天下太平了。然而，事实上大多数商业数据仍然在大型主机上以非关系文件(VSAM)的形式存放，并由COBOL语言编写的大型机程序访问。而且，还有很多商用程序继续在使用C++、Java、Visual Basic和其他各种各样的语言编写。除了最简单的程序之外，所有的应用程序都需要与运行在其他异构平台上的应用程序集成并进行数据交换。这样的任务通常都是由特殊的方法，如文件传输和分析，消息队列，还有仅适用于某些情况的的API，如IBM的"高级程序到程序交流(APPC)"等来完成的。在以前，没有一个应用程序通信标准，是独立于平台、组建模型和编程语言的。只有通过Web Service，客户端和服务器才能够自由的用HTTP进行通信，不论两个程序的平台和编程语言是什么。

什么是Web Service：

对这个问题，我们至少有两种答案。从表面上看，Web service就是一个应用程序，它向外界暴露出一个能够通过Web进行调用的API。这就是说，你能够用编程的方法通过Web来调用这个应用程序。我们把调用这个Web service的应用程序叫做客户。例如，你想创建一个Web service，它的作用是返回当前的天气情况。那么你可以建立一个ASP页面，它接受邮政编码作为查询字符串，然后返回一个由逗号隔开的字符串，包含了当前的气温和天气。要调用这个ASP页面，客户端需要发送下面的这个HTTP GET

返回的数据就应该是这样：

这个ASP页面就应该可以算作是Web service了。因为它基于HTTP GET请求，暴露出了一个可以通过Web调用的API。当然，Web service还有更多的东西。

下面是对Web service更精确的解释：Web services是建立可互操作的分布式应用程序的新平台。作为一个Windows程序员，你可能已经用COM或DCOM建立过基于组件的分布式应用程序。COM是一个非常好的组件技术，但是我们也很容易举出COM并不能满足要求的情况。

Web service平台是一套标准，它定义了应用程序如何在Web上实现互操作性。你可以用任何你喜欢的语言，在任何你喜欢的平台上写Web service，只要我们可以通过Web service标准对这些服务进行查询和访问。

新平台：

Web service平台需要一套协议来实现分布式应用程序的创建。Web service平台必须提供一套标准的类型系统，用于沟通不同平台、编程语言和组件模型中的不同类型系统。在传统的分布式系统中，基于界面(interface)的平台提供了一些方法来描述界面、方法和参数（译注：如COM和COBAR中的IDL语言）。同样的，Web service平台也必须提供一种标准来描述Web service，让客户可以得到足够的信息来调用这个Web service。最后，我们还必须有一种方法来对这个Web service进行远程调用。这种方法实际是一种远程过程调用协议(RPC)。为了达到互操作性，这种RPC协议还必须与平台和编程语言无关。下面几个小节就简要介绍了组成Web service平台的这三个技术。

XML和XSD：

可扩展的标记语言（标准通用标记语言下的一个子集）是Web service平台中表示数据的基本格式。除了易于建立和易于分析外，XML主要的优点在于它既是平台无关的，又是厂商无关的。无关性是比技术优越性更重要的：软件厂商是不会选择一个由竞争对手所发明的技术的。

XML解决了数据表示的问题，但它没有定义一套标准的数据类型，更没有说怎么去扩展这套数据类型。例如，整形数到底代表什么？16位，32位，还是64位？这些细节对实现互操作性都是很重要的。W3C制定的XML Schema(XSD)就是专门解决这个问题的一套标准。它定义了一套标准的数据类型，并给出了一种语言来扩展这套数据类型。Web service平台就是用XSD来作为其数据类型系统的。当你用某种语言(如VB. NET或C#)来构造一个Web service时，为了符合Web service标准，所有你使用的数据类型都必须被转换为XSD类型。你用的工具可能已经自动帮你完成了这个转换，但你很可能会根据你的需要修改一下转换过程。

SOAP：

Web service建好以后，你或者其他人就会去调用它。简单对象访问协议(SOAP)提供了标准的RPC方法来调用Web service。实际上，SOAP在这里有点用词不当：它意味着下面的Web service是以对象的方式表示的，但事实并不一定如此：你完全可以把你的Web service写成一系列的C函数，并仍然使用SOAP进行调用。SOAP规范定义了SOAP消息的格式，以及怎样通过HTTP协议来使用SOAP。SOAP也是基于XML（标准通用标记语言下的一个子集）和XSD的，XML是SOAP的数据编码方式。

WSDL：

你会怎样向别人介绍你的Web service有什么功能，以及每个函数调用时的参数呢？你可能会自己写一套文档，你甚至可能会口头上告诉需要使用你的Web service的人。这些非正式的方法至少都有一个严重的问题：当程序员坐到电脑前，想要使用你的Web service的时候，他们的工具(如Visual Studio)无法给他们提供任何帮助，因为这些工具根本就不了解你的Web service。

解决方法是：用机器能阅读的方式提供一个正式的描述文档。Web service描述语言(WSDL)就是这样一个基于XML（标准通用标记语言下的一个子集）的语言，用于描述Web service及其函数、参数和返回值。WSDL既是机器可阅读的，又是人可阅读的，这将是一个很大的好处。一些最新的开发工具既能根据你的Web service生成WSDL文档，又能导入WSDL文档，生成调用相应Web service的代码。

UDDI：

Universal Description, Discovery and Integration

为加速Web Service的推广、加强Web Service的互操作能力而推出的一个计划,基于标准的服务描述和发现的规范(specification)。

以资源共享的方式由多个运作者一起以Web Service的形式运作UDDI商业注册中心。

UDDI计划的核心组件是UDDI商业注册，它使用XML文档来描述企业及其提供的Web Service。

UDDI商业注册提供三种信息：

White Page包含地址、联系方法、已知的企业标识。

Yellow Page包含基于标准分类法的行业类别。

Green Page包含关于该企业所提供的Web Service的技术信息，其形式可能是指向文件或URL的指针，而这些文件或URL是为服务发现机制服务的。