不好意思，这里只是课外小抄哈～

在植物命名学中，变种（拉丁文：varietas，简称写做 var.）为一种分类级别，地位在种之下，如果牵涉到此种分类，则生物学名会变为三部分。（i.e.三民法）

范例
有一种枕形仙人掌「Escobaria vivipara (Nutt.) Buxb.」为一种广分布种，分布范围从加拿大至墨西哥。在新墨西哥州海拔低于 2,600米（8,500英尺） 的地方都能见到他的踪影。目前纪录就有九个变种。亚利桑那州纪录的变种为「Escobaria vivipara var. arizonica」，而新墨西哥州的变种则为「Escobaria vivipara var. neo-mexicana」。由于彼此仍属同一个种，因此他们有能力杂交形成具有繁殖能力的后代，所以在两种变种的地盘之间，常常会形成过渡带。

定义
植物变种的定义很多种，取决于不同作者变种在形态上可能会与其他变种差异极大，但有能力自由杂交并形成具有繁殖能力的后代。

其他命名用法
在园艺栽培命名上， nomenclature, at least in countries that are signatory to the UPOV Convention, “variety” or “plant variety” is a legal term.

在国际动物命名法规（ICZN），唯一被认可的种下名是亚种，这个名称是1961年首次使用。在动物学上，学界较少利用形态学及多态性来做分类命名，如果需要，也可做非正式的命名，但需按照国际动物命名法规的方针。
In bacteriological nomenclature “variety” is not allowed, but names published as varieties before 1992 are taken to be published as subspecies.
In viticulture nomenclature, what is referred to as “grape varieties” are in reality cultivars according to usage in the International Code of Nomenclature for Cultivated Plants or “plant varieties” in the legal sense rather than botanical taxonomy varieties, since they are propagated by cuttings and have properties that are not stable under sexual reproduction. However, usage of the term variety is so entrenched in viticulture that a change to cultivar is unlikely.

国际藻类、真菌、植物命名法规

中文百科
《国际藻类、真菌、植物命名法规》（英语： International Code of Nomenclature for algae, fungi, and plants；ICN）是一部关于植物命名的规则与建议，其中确立每一个分类单元（或分类群, taxon）只有一个正确的学名。此规则通行于全世界，更改必须经由国际植物学会议（International Botanical Congress, IBC）的讨论。全部的事项皆由国际植物分类学学会组织完成。
历史
法规内容
命名法规主要的条文(以维也纳法规为准)：
原则 (principles)：共有六条最基本的原则，「系构成植物命名法之基础」。
详细的法条区分为许多规则，而以条款 (Article) 及拟则 (Recommand)陈述。例证 (Ex.) 则附加于规则及拟则内供为说明。条款中的规则乃整理历来的命名法，作为将来之准绳；凡植物名称抵触规则者不能再使用。拟则供补充条款之用，「其目的在使将来之命名方法可逐步统一、清晰。凡植物命名无论在名称上或形式上与拟则抵触者，虽不予取消，但此后不得援以为例」。
规则与拟则适用于所有传统认知之现生或化石植物。例如：蓝绿菌(蓝绿藻)、真菌类，包括壶菌类、卵菌类、黏菌类等；及能施行光合作用之原生生物。
国际栽培植物命名委员会为使用于农业上、林业上、园艺上若干特定群之名称，授权制定「国际栽培植物命名法规」。
法规一直强调：名称变更之唯一正确理由，乃分类学者经充份研究后，有确凿之事实证据，或必须废弃违反本规则之学名。
最新变革
[第十八届国际植物学会议] (XVIII IBC) 国际植物命名法规重要变更：
一、自2012年1月1日起接受在电子出版品上发表新名
自2012年1月1日起，在印刷出版品上发表新名称已非必要；于网络上以PDF档（便携式文档格式）发表且具有国际标准书号（ISBN） 或国际标准连续出版物号（ISSN）之出版品亦可视为有效发表。
二、自2012年1月1日起命名时可用英文描述
自2012年1月1日起，发表新种时可用拉丁文或英文描述。
三、一种化石分类群一个正确名称；一种真菌，一个正确名称
放弃形态分类群 (morphotaxa) 之概念，若具不同名称之断片、生活史阶段或储藏阶段之化石可被证实属同一种时，仅可具有一正当名；该名称之决定应符合优先权之相关规定。真菌的部份则是舍弃有性世代、无性世代具不同学名的概念。
四、于MycoBank注册新名称是发表真菌新名的必要条件
近年来，真菌学家于MycoBank数据库、Index Fungorum数据库发表新种新名，为法规中规定的必要条件。
五、国际植物命名法规更名为国际藻类、真菌及植物命名法规
《国际植物命名法规》（International Code of Botanical Nomenclature）为有效反映该法规所涵盖之分类群，更名为《国际藻类、真菌及植物命名法规》（International Code of Nomenclature for algae, fungi, and plants）。

The International Code of Nomenclature for algae, fungi, and plants (ICN) is the set of rules and recommendations dealing with the formal botanical names that are given to plants, fungi and a few other groups of organisms, all those “traditionally treated as algae, fungi, or plants”. It was formerly called the International Code of Botanical Nomenclature (ICBN); the name was changed at the International Botanical Congress in Melbourne in July 2011 as part of the Melbourne Code which replaces the Vienna Code of 2005. As with previous codes, it takes effect as soon as ratified by the congress (on Saturday 23 July 2011), but the documentation of the code in its final form takes some time to prepare after the congress. Preliminary wording of some of the articles with the most significant changes has been published in September 2011.
The name of the Code is partly capitalized and partly not. The lower-case for “algae, fungi, and plants” indicates that these terms are not formal names of clades, but indicate groups of organisms that were historically known by these names and traditionally studied by phycologists, mycologists, and botanists. This includes blue-green algae (Cyanobacteria); fungi, including chytrids, oomycetes, and slime moulds; photosynthetic protists and taxonomically related non-photosynthetic groups. There are special provisions in the ICN for some of these groups, as there are for fossils.
The ICN can only be changed by an International Botanical Congress (IBC), with the International Association for Plant Taxonomy providing the supporting infrastructure. Each new edition supersedes the earlier editions and is retroactive back to 1753, except where different starting dates are specified.
For the naming of cultivated plants there is a separate code, the International Code of Nomenclature for Cultivated Plants, which gives rules and recommendations that suppleme

SOAP
中文百科
SOAP（原为Simple Object Access Protocol的首字母缩写，即简单对象访问协议）是交换数据的一种协议规范，使用在计算机网络Web服务（web service）中，交换带结构信息。SOAP为了简化网页服务器（Web Server）从XML数据库中提取数据时，节省去格式化页面时间，以及不同应用程序之间按照HTTP通信协议，遵从XML格式执行资料互换，使其抽象于语言实现、平台和硬件。此标准由IBM、Microsoft、UserLand和DevelopMentor在1998年共同提出，并得到IBM，莲花（Lotus），康柏（Compaq）等公司的支持，于2000年提交给万维网联盟（World Wide Web Consortium；W3C），目前SOAP 1.1版是业界共同的标准，属于第二代的XML协定（第一代具主要代表性的技术为XML-RPC以及WDDX）。
用一个简单的例子来说明SOAP使用过程，一个SOAP消息可以发送到一个具有Web Service功能的Web站点，例如，一个含有房价信息的数据库，消息的参数中标明这是一个查询消息，此站点将返回一个XML格式的信息，其中包含了查询结果（价格，位置，特点，或者其他信息）。由于数据是用一种标准化的可分析的结构来传递的，所以可以直接被第三方站点所利用。
英语百科
SOAP, originally an acronym for Simple Object Access Protocol, is a protocol specification for exchanging structured information in the implementation of web services in computer networks. It uses XML Information Set for its message format, and relies on application layer protocols, most notably Hypertext Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP), for message negotiation and transmission.
Characteristics
SOAP can form the foundation layer of a web services protocol stack, providing a basic messaging framework for web services. This XML-based protocol consists of three parts:
an envelope, which defines the message structure and how to process it
a set of encoding rules for expressing instances of application-defined datatypes
a convention for representing procedure calls and responses
SOAP has three major characteristics:
extensibility (security and WS-routing are among the extensions under development)
neutrality (SOAP can operate over any transport protocol such as HTTP, SMTP, TCP, UDP, or JMS)
independence (SOAP allows for any programming model)
As an example of what SOAP procedures can do, an application can send a SOAP request to a server that has web services enabled—such as a real-estate price database—with the parameters for a search. The server then returns a SOAP response (an XML-formatted document with the resulting data), e.g., prices, location, features. Since the generated data comes in a standardized machine-parsable format, the requesting application can then integrate it directly.
The SOAP architecture consists of several layers of specifications for:
message format
Message Exchange Patterns (MEP)
underlying transport protocol bindings
message processing models
protocol extensibility
SOAP evolved as a successor of XML-RPC, though it borrows its transport and interaction neutrality and the envelope/header/body from elsewhere (probably from WDDX).

SOAP was designed as an object-access protocol in 1998 by Dave Winer, Don Box, Bob Atkinson, and Mohsen Al-Ghosein for Microsoft, where Atkinson and Al-Ghosein were working. Due to politics within Microsoft, the specification was not made available until it was submitted to IETF 13 September 1999. Because of Microsoft’s hesitation, Dave Winer shipped XML-RPC in 1998.
The submitted Internet Draft did not reach RFC status and is therefore not considered a “standard” as such. Version 1.1 of the specification was published as a W3C Note on 8 May 2000. Since version 1.1 did not reach W3C Recommendation status, it can not be considered a “standard” either. Version 1.2 of the specification, however, became a W3C recommendation on June 24, 2003.
The SOAP specification was maintained by the XML Protocol Working Group of the World Wide Web Consortium until the group was closed 10 July 2009. SOAP originally stood for “Simple Object Access Protocol” but version 1.2 of the standard dropped this acronym.
After SOAP was first introduced, it became the underlying layer of a more complex set of Web Services, based on Web Services Description Language (WSDL), XML Schema and Universal Description Discovery and Integration (UDDI). These different services, especially UDDI, have proved to be of far less interest, but an appreciation of them gives a more complete understanding of the expected role of SOAP compared to how web services have actually evolved.

• Specification
  SOAP Building Blocks. A SOAP message is an ordinary XML document containing the following elements:
  Element Description Required
  Envelope Identifies the XML document as a SOAP message. Yes
  Header Contains header information. No
  Body Contains call, and response information. Yes
  Fault Provides information about errors that occurred while processing the message. No
  Transport methods
  Both SMTP and HTTP are valid application layer protocols used as transport for SOAP, but HTTP has gained wider acceptance as it works well with today’s internet infrastructure; specifically, HTTP works well with network firewalls. SOAP may also be used over HTTPS (which is the same protocol as HTTP at the application level, but uses an encrypted transport protocol underneath) with either simple or mutual authentication; this is the advocated WS-I method to provide web service security as stated in the WS-I Basic Profile 1.1.
  This is a major advantage over other distributed protocols like GIOP/IIOP or DCOM, which are normally filtered by firewalls. SOAP over AMQP is yet another possibility that some implementations support. SOAP also has an advantage over DCOM that it is unaffected by security rights configured on the machines that require knowledge of both transmitting and receiving nodes. This lets SOAP be loosely coupled in a way that is not possible with DCOM. There is also the SOAP-over-UDP OASIS standard.
  Message format
  XML Information Set was chosen as the standard message format because of its widespread use by major corporations and open source development efforts. Typically, XML Information Set is serialized as XML. A wide variety of freely available tools significantly eases the transition to a SOAP-based implementation. The somewhat lengthy syntax of XML can be both a benefit and a drawback. While it promotes readability for humans, facilitates error detection, and avoids interoperability problems such as byte-order (endianness), it can slow processing speed and can be cumbersome. For example, CORBA, GIOP, ICE, and DCOM use much shorter, binary message formats. On the other hand, hardware appliances are available to accelerate processing of XML messages. Binary XML is also being explored as a means for streamlining the throughput requirements of XML. XML messages by their self-documenting nature usually have more ‘overhead’ (Headers, footers, nested tags, delimiters) than actual data in contrast to earlier protocols where the overhead was usually a relatively small percentage of the overall message.
  In financial messaging SOAP was found to result in a 2–4 times larger message than previous protocols FIX (Financial Information Exchange) and CDR (Common Data Representation).
  XML Information Set does not have to be serialized in XML. For instance, a CSV or JSON XML-infoset representation exists. There is also no need to specify a generic transformation framework. The concept of SOAP bindings allows for specific bindings for a specific application. The drawback is that both the senders and receivers have to support this newly defined binding.

Example message:

POST /InStock HTTP/1.1 Host:https://weixin_45981643/article/details/105898666 Content-Type: application/soap+xml; charset=utf-8 Content-Length: 299 SOAPAction: "eudic-http://www.w3.org/2003/05/soap-envelope"

<?xml version=1.0was-addressing> <soap:Envelope xmlns:soap=eudic-http://www.w3.org/2003/05/soap-envelope> <soap:Header> </soap:Header> <soap:Body> <m:GetStockPrice xmlns:m=eudic-http://www.weixin_45981643/article/details/105898666.blog.csdn.net/stock/Surya> <m:StockName>ICSDN</m:StockName> </m:GetStockPrice> </soap:Body> </soap:Envelope>

SOAP’s neutrality characteristic explicitly makes it suitable for use with any transport protocol. Implementations often use HTTP as a transport protocol, but obviously other popular transport protocols can be used. For example, SOAP can also be used over SMTP, JMS and Message Queues.

SOAP, when combined with HTTP post/response exchanges, tunnels easily through existing firewalls and proxies, and consequently doesn’t require modifying the widespread computing and communication infrastructures that exist for processing HTTP post/response exchanges.

Disadvantages
When using standard implementations and the default SOAP/HTTP binding, the XML infoset is serialized as XML. To improve performance for the special case of XML with embedded binary objects, the Message Transmission Optimization Mechanism was introduced.
When relying on HTTP as a transport protocol and not using WS-Addressing or an ESB, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other.
The verbosity of the protocol led to the domination in the field by services using the HTTP Directly
Transport methods

• ==Web服务寻址（WS-Addressing）==是一个W3C推荐标准，为Web服务提供一种与传输层无关的，传送寻址信息的机制。规范主要由两部分组成：传送Web服务端点的引用的数据结构，以及一套能够在特定的消息上关联寻址信息的消息寻址属性。

WS-Addressing是将消息路由数据包含在SOAP头中的一种标准方法。利用WS-Addressing的消息可以在标准化的SOAP头中包含自己的包含发送元数据，而不是依赖于网络层传输来传送路由信息。网络级传输只负责将消息发送到能够读取WS-Addressing元数据的分配器那里。一旦消息抵达了URI所制定的分配器，网络层传输的工作就完成了。

通过在标准的SOAP头中(wsa:ReplyTo)指定应答消息应该发送到哪里的端点引用，WS-Addressing可以支持异步交互方式。 服务提供者使用另一个连接，将应答消息发送给wsa:ReplyTo所指定的端点。这就将SOAP请求/应答消息的交互与HTTP请求/应答协议分离，这样，跨越任意时间的长时间运行的交互成为可能。