爱华网前言
SOA是一种架构模型，由网站服务技术等标准化组件组成，目的是为企业、学校或提供网络服务单位建构一个具弹性、可重复使用的整合性接口，促进内外部如内部应用程序、用户、与部门(系所)等相关单位完美的沟通，尽速达到网络服务提升的目标。
何谓SOA?
我们常听到 Information Technology (IT)产业的架构演进，由1980年代的主机(mainframe)架构，到1990年代的主从式(client server)架构，到1999年时是network centric架构，而到2004年时已复杂到所谓的 Service-Oriented Architecture架构(SOA，服务导向架构) 。此外也常聴到：如果企业不导入这个架构，企业在未来就会没有竞争力。因此，本文将针对SOA作浅显的简介，也希望透过本文的介绍，对于本校网站服务技术(web services) 未来的架构有所帮助。
首先让我们厘清一些SOA的迷思。正确来说 [1]：
SOA不是新玩意：多年前即有信息部门或公司成功地用SOA方式来建构、运行应用程序，且当时XML、web service都尚未提出。
SOA不是种技术：它是种建构、组织的方法，用来建立应用程序的运行环境，以及让学校的业务程序能以「功能化」方式发展、累积。
就算购买最新的XML、web services产品（如开发工具、执行平台、软件组件等），也不表示就可以建构出SOA式的应用程序。
简单来说，SOA是一种遵循规范，是针对学校或企业内应用程序的设计、开发、布建、管理所提出的遵循规范。从信息技术层面而言，一个执行学校或企业业务的应用程序称为一个独立的「逻辑单位」，而对学校或企业营运层面而言则可称为一项「服务」，在企业的整体运算环境中就存在着多个「独立逻辑、业务服务」，且需要对其进行妥善设计、开发、布建、管理等，也因此需要实行服务导向架构（SOA）。
要实现SOA，需要学校或企业的程序设计师改采「持续累积服务」的观念与角度来开发应用程序，即便这么做在短时间内看不到显著好处，程序员还是必须跳脱、超越过往对应用程序的想法，改以「既有服务可否再运用？」或者是「能否沿用其他同仁开发过的服务再建构？」的观点来面对程序开发。
SOA主张「程序开发技术」与「程序建构方法」的交替并用，以类似通讯沟通的作法，将数个所需的「业务服务」进行链接，以此来实现一个新的应用程序，而非「从头开发」。透过适当的程序组构及通讯式的程序链接，可让学校或企业快速因应学生或用户的需求与改变，新的应用程序只要透过「通讯微调」即可实现，而非「重新撰写」。
SOA不单只是程序开发的方法论，也提供行政管理层面的依循。例如它并非是以应用程序个体为角度来进行管理，而是直接将过往程序员开发出的程序视为「服务」来管理。而对「服务」间的「互动通讯」进行分析，SOA便可让程序设计部门的主管了解何时该执行哪个业务逻辑，以及为何要执行，如此信息管理者与分析师便可对服务程序进行优化调适。
SOA如何运作?
SOA服务导向架构是一种新兴的系统架构模型，主要概念是针对学校或企业需求组合而成的一组软件组件。组合的元素通常包括：软件组件、服务及流程三个部份。当学校或企业面对外部要求时，流程负责定义外部要求的处理步骤；服务包括特定步骤的所有程序组件，而软件组件则负责执行工作的程序。SOA 已成为现今软件开发的重要技术，透过 SOA 让异质系统整合变得容易，程序再使用度也提高。不必自行开发或拥有所有程序组件，发展者可以视其需要组合网络上最好的服务。不受限于特定厂商的产品功能或是平台，达到真正的开放性(Openness)。从分布式组件架构到 SOA概念上，SOA 如同面向对象、软件组件等软件技术一般，运用小的零组件组合成应用系统。但 SOA 强调的是如何将彼此关系松散的应用系统功能组件在网络上发行、组合及使用。SOA 具有下列技术特性[2]：
分布式架构 (distributed)－SOA 的组成组件是由许多分散在网络上的系统组合而来，可能是局域网络，也可能是来自广域网。例如网站服务技术 (web services) 就是运作 HTTP来相互链接的 SOA。如此的作法，也使得网站服务技术很快的就成为所有支持因特网的系统平台均能使用的技术。
关系松散的界面 (loosely coupled)－传统的系统主要是将应用系统功能需求切割成相互关联的小零组件：模块、对象或组件，开发者要花费极大的心力了解零组件是如何设计及使用，以确保不会违反零组件连接关系限制。如此一来，若要以不同零组件替换原始设计，就成为一件困难的事。SOA 的作法是以界面标准来组合系统，只要符合界面要求，零组件可以任意替换，大幅提高系统变更的弹性度。
依据开放的标准 (Open standard)－使用开放标准是 SOA 的核心特色，过去的软件组件平台如 CORBA、DCOM、RMI、J2EE 采用专属协议作为组件链接的规范，使得不同平台的组件无法相通。SOA 则着重于标准与互动性，将可避免不同平台 (.NET web services 与 Java web services) 开发程序间相互整合的困扰。
以流程角度出发 (process centric)－在建构系统时，首先了解特定工作的流程要求，并将其切割成服务界面(包括输入与输出数据格式)，如此其他的发展者就可以依据服务界面开发 (或选择) 合适的组件来完成工作。
最后举一个学校常用的例子来说明SOA在实际应用上带来的可能性。假设我们要建立一个在线投稿的网站，网站提供的服务包括了在线投稿作业、论文分派作业、论文审查作业、在线注册及报名作业等。传统的方式我们会尽快找一个类似的网站，再尽快将其他类似网站的原始码(source code)拿来修改，但其他类似网站的原始码所执行的平台有可能不是架站者所熟悉的操作系统。若要让架站者作一个客制化，并符合自己投稿主题的在线投稿的网站，可能要熟悉这个平台并修改网页及测试，再加上别人的网站可能有一些bug，如果要做到毫无问题，除错时间可能要花上三个月的时间。但是，如果我们导入SOA的架构的话，可能将来只要花费心力将作业服务模块化、对象化或组件化，然后将它们整合到网站中即可，不需要再花费时间和资源自己去维护一个在线投稿的网站，也不需要再自行建立和数据库链接、报名付款机制等。这个网站就像是建立在SOA上，整合了这些web services组件的一个应用程序系统。更重要的是，透过如http、XML、SOAP 等产业标准开放式协议，不必担心这些服务使用什么平台、甚么技术来建立，而将来如果有更好的服务或服务提供商时，也可以轻易的将服务更换或更新。对系统开发者来讲，可以快速轻松的将系统建构完成，将心思专注在规划更好、更完善的系统上；对服务提供商而言，只要能设计出一个好的服务，它的潜在用户市场将不再受到用户平台的限制而有无限的可能。单就这类应用所呈现的美好远景，应该可以解释为什么会到处听到有人在谈论SOA了。
因此 SOA 的实作，就是将所有程序逻辑及服务内容全部包裹在服务内部，并实作一个标准的接口与外部作沟通，这种做法跟传统的组件导向做法非常类似，唯一的差别是接口定义的方式、数据格式、与沟通管道必须是产业标准 (http、XML、SOAP 等)。 也就是说只要能实作出这样的接口，不论接口后面是什么，都可使成为 SOA。
结论
综合以上的介绍，SOA能带来的帮助，有以下好处：
1.增加企业盈收，或提升学校的服务质量。
2.提供可变动的网络服务型态。
3.降低学校或企业的成本。
4.降低开发服务的时间。
5.整合学校或企业的网络服务技术资源。
6.降低整体风险及意外。
