松散类型 Web 服务与强类型 Web 服务

最新推荐文章于 2023-09-16 14:31:29 发布
最新推荐文章于 2023-09-16 14:31:29 发布
阅读量985 收藏
点赞数
分类专栏： .Net ASp 文章标签： web soap xml 文档 types websphere
.Net 同时被 2 个专栏收录
158 篇文章 0 订阅
订阅专栏
ASp
9 篇文章 0 订阅
订阅专栏
您是否知道松散类型 Web 服务和强类型 Web 服务编程方法的区别？IBM 高级技术人员 Andre Tost 将对这些区别加以说明，并将解释为什么大多数情况下需要强类型服务。

引言

Web 服务越来越多地用于企业应用程序集成（Enterprise Application Integration，EAI），在 EAI 中，服务使用者和服务提供者使用企业服务总线（Enterprise Service Bus，ESB）进行通信。企业应用程序的集成由来已久了，通常是通过创建应用程序适配器完成的，应用程序适配器会将消息转换为内部专用格式和协议。

从表面上看，使用 Web 服务对应用程序进行集成似乎是和以前的集成方案一样（或者，至少十分相似）的概念。但与过去相比，Web 服务能使标准化程度更高，且能提供更好的工具，平台与编程语言间的互操作性也更好。

描述系统的相关服务接口仍然是一个挑战。开发人员通常使用两种方法之一应对这项挑战。一方面，Web 服务描述语言（Web Services Description Language，WSDL）定义可以利用消息的 XML 架构描述，允许准确描述交换的消息。另一方面，很多服务均使用通用接口构建：一个字符串传入，另一个字符串传出，或者交换纯二进制对象。对消息的正确解释的工作留给了使用者和提供者。尽管在出现更改时，认为这种方法更为灵活（因为消息的具体细节在服务实现中处理），但同时也更容易出错，而且要求进行更多的手动编程工作。

在本文中，我将比较这两种方式，并会就每种方式的应用场合进行举例说明。





回页首


松散类型 Web 服务

首先，让我们定义本文范围内的松散类型这一术语。松散类型意味着服务的接口定义（使用 WSDL）不包含强定义服务所使用的任何消息格式的架构。也就是说，应用程序可以不完全单独遵从来自服务接口定义的消息实例。

松散类型描述的一个例子就是将消息的实际内容编码为单个字符串的 Web 服务。此服务接口描述一个 xsd:string 类型的输入参数和一个输出参数。其 WSDL <types> 部分可能与下面的清单 1 类似。


清单 1. WSDL <types> 

				 
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitionstargetNamespace="http://mycomp.com"xmlns:impl=
   "http://mycomp.com"xmlns:intf="http://mycomp.com"xmlns:wsdl=
   "http://schemas.xmlsoap.org/wsdl/"xmlns:wsdlsoap=
   "http://schemas.xmlsoap.org/wsdl/soap/"xmlns:wsi=
   "http://ws-i.org/profiles/basic/1.1/xsd"xmlns:xsd=
   "http://www.w3.org/2001/XMLSchema">
  <wsdl:types>
   <schematargetNamespace="http://mycomp.com"xmlns=
     "http://www.w3.org/2001/XMLSchema"xmlns:impl=
     "http://mycomp.com"xmlns:intf=
     "http://mycomp.com"xmlns:wsdl=
     "http://schemas.xmlsoap.org/wsdl/"xmlns:xsd=
     "http://www.w3.org/2001/XMLSchema">
     <element name="executeResponse">
      <complexType>
       <sequence>
        <element name="executeReturn" nillable="true" type="xsd:string"/>
       </sequence>
      </complexType>
     </element>
     <element name="execute">
      <complexType>
       <sequence>
        <element name="message" nillable="true" type="xsd:string"/>
       </sequence>
      </complexType>
     </element>
    </schema>
  </wsdl:types>
 
</wsdl:definitions>

请注意，由于这是“包装的文档/文本”Web 服务，因此包装元素称为“execute”。（此处并显示所有 WSDL，但剩余部分肯定包含文档/文本绑定。）单个输入和输出参数定义以粗体突出显示。

对于此定义，您并不能准确地知道请求和响应消息的内容的格式。它可能为字符分隔的字符串、固定长度的字符串，或者，甚至可以是 XML。无论何种情况，服务使用者和服务提供者需要就双方都能理解的共同格式达成一致，而且双方都需要开发代码以正确地构建和解释该格式。由于消息内容的具体定义并没有包括在 WSDL 定义中，因此这里没有可提供帮助的工具。

有利的一面是，如果消息结构发生更改，您无须更改新 WSDL 定义。只要确保所有的参与方均知道这一更改，并且能处理更改后的格式就行了。不过，此方法的缺点通常比优点更为突出，特别在将 XML 作为内容发送时更是如此。

在字符串中发送 XML

让我们更进一步了解在此字符串中发送 XML 数据时的情况。当现有应用程序包含 XML 格式的信息，并且要将此数据原封不动地通过 Web 服务接口发送时，就可能出现这种情况。（由于 XML 可以表示为字符串，所以将数据表示为字符串参数。）例如，假设需要使用以下格式的 XML 文档作为客户机请求的响应发送，如下面的清单 2 所示。


清单 2. 在字符串中发送 XML 

				
				Note:  This is an example only.
<customer>
  <name>Joe Smith</name>
  <address>
    <street>4308 Sunshine Blvd</street>
    <city>Rochester</city>
    <state>MN</state>
    <zip>55901</zip>
   </address>
</customer>

清单 3 演示了当使用清单 2 中的服务接口定义时，简单对象访问协议 (SOAP) 响应消息的格式。


清单 3. SOAP 响应消息 

				   <soapenv:Envelope xmlns:soapenv
   ="http://schemas.xmlsoap.org/soap/envelope/"xmlns:soapenc=
   "http://schemas.xmlsoap.org/soap/encoding/"xmlns:xsd=
   "http://www.w3.org/2001/XMLSchema"xmlns:xsi=
   "http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<p416:executeResponse xmlns:p416="http://mycomp.com">
<executeReturn>&lt;customer&gt;   &lt;name&gt;Joe Smith&lt;/name&gt;   
&lt;address&gt;   &lt;street&gt;4308 Sunshine Blvd&lt;/street&gt;     
&lt;city>Rochester&lt;/city&gt;   &lt;state&gt;MN&lt;/state&gt;
&lt;zip&gt;55901&lt;/zip&gt;   &lt;/address&gt;&lt;/customer&gt;</executeReturn>
</p416:executeResponse>
</soapenv:Body>
</soapenv:Envelope>

这看起来并不像 XML，对吧？这是由于对 SOAP 引擎而言，它是一个字符串。如果将 XML 传递到此字符串中，将对其进行编码，以使其不干涉 SOAP 引擎的 XML 处理。不过，在将其送回客户机之前，会再将已编码的字符串解码。此过程对于实际的服务客户机和提供者实现都是透明的，而这无疑是非常有利的。但另一方面，它增加了消息的大小，使得调试 SOAO 消息传递更难了，并增加了每条消息的处理时间。在本文的稍后部分，我将给出另一个示例，该示例将提供同样的功能，但避免了其中的这些问题。在这里我要指出的是，使用字符串参数通过 Web 服务接口发送 XML 通常被认为是糟糕的设计，应该加以避免。

有关在字符串中发送 XML 的示例，请参阅本文中提供的 EAR 文件，GenericString.ear。

使用 <xsd:any>

指示 WSDL 文件中不存在消息格式的严格定义的另一种方式就是使用 <xsd:any/> 元素。在架构中出现此元素将仅指示在运行时此位置可以出现任何类型的 XML。区别在于，实际的 XML 将进入消息中，而不会转换为编码的字符串。同时，消息的处理仍然必须手动编码，因为 WSDL 不包含任何关于此消息的提示。

因此 Java™ APIs for XML-Based Remote Procedure Call (JAX-RPC) 规范描述了将 <xsd:any/> 映射到 javax.xml.soap.SOAPElement。此接口属于标准 SOAP with Attachments API for Java (SAAJ API)，定义 SOAP 消息各个元素的 Java 接口。可以采用分析普通 Document Object Model (DOM) 的方式对其进行分析。我将在后面给出这一点的示例。

以下是前面所使用过的 WSDL 定义；不过，我使用 <xsd:any/> 代替了泛型字符串，如下面的清单 4 所示。


清单 4. <xsd:any/> 

				
<wsdl:definitions targetNamespace="http://mycomp.com"xmlns:impl=
   "http://mycomp.com"xmlns:intf="http://mycomp.com"xmlns:wsdl=
   "http://schemas.xmlsoap.org/wsdl/"xmlns:wsdlsoap=
   "http://schemas.xmlsoap.org/wsdl/soap/"xmlns:wsi=
   "http://ws-i.org/profiles/basic/1.1/xsd"xmlns:xsd=
   "http://www.w3.org/2001/XMLSchema">
    <wsdl:types>
      <schema targetNamespace="http://mycomp.com" xmlns=
    "http://www.w3.org/2001/XMLSchema" xmlns:impl=
    "http://mycomp.com"xmlns:intf="http://mycomp.com" xmlns:wsdl=
    "http://schemas.xmlsoap.org/wsdl/" xmlns:xsd=
    "http://www.w3.org/2001/XMLSchema">
      <element name="executeResponse">
        <complexType>
          <sequence>
            <xsd:any/>
          </sequence>
       </complexType>
      </element>
      <element name="execute">
        <complexType>
          <sequence>
            <xsd:any/>
          </sequence>
       </complexType>
      </element>
    </schema>
 <wsdl:types>
<wsdl:definitions/>

使用 <xsd:any/> 比使用泛型字符串更可取，因为这样就不需要对消息进行编码。不过，它只能和 XML 消息一起使用，而且仍然要求代码出现在服务提供者和使用者端，以分析和构建消息。清单 5 演示了将我在清单 4 中所使用的相同的 Customer XML 文档发送回时的服务提供者的代码：


清单 5. 服务提供者代码 

				
package com.mycomp;

import javax.xml.soap.SOAPElement;
import javax.xml.soap.SOAPException;
import javax.xml.soap.SOAPFactory;

import com.ibm.websphere.webservices.soap.IBMSOAPFactory;

public class GenericAnySoapBindingImpl implements com.mycomp.GenericAny{
		 
	public String customer = 
	     "<customer>"  +
	        "<name>Joe Smith</name>"  +
	        "<address>"  +
	           "<street>4308 Sunshine Blvd</street>"  +
	           "<city>Rochester</city>"  +
	           "<state>MN</state>"  +
	           "<zip>55901</zip>"  +
	       "</address>"  +
	     "</customer>";
		 
  public javax.xml.soap.SOAPElement execute(javax.xml.soap.SOAPElement any) 
  throws java.rmi.RemoteException {
    	SOAPElement result = null;
    	try {
          SOAPFactory factory = SOAPFactory.newInstance();
    	  result = 
    	  ((IBMSOAPFactory)factory).createElementFromXMLString(customer);
    	} catch (SOAPException x) {}
        return result;
  }

}

清单 6 显示了以上请求的 SOAP 响应消息的内容。


清单 6. SOAP 响应消息 

				
				Note:  This is an example only.

<soapenv:Envelope xmlns:soapenv=
   "http://schemas.xmlsoap.org/soap/envelope/" 
   xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd=
   "http://www.w3.org/2001/XMLSchema" xmlns:xsi=
   "http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Header/>
<soapenv:Body>
<p416:executeResponse xmlns:p416="http://mycomp.com">
  <customer>
    <name>Joe Smith</name>
    <address>
      <street>4308 Sunshine Blvd</street>
      <city>Rochester</city>
      <state>MN</state>
      <zip>55901</zip>
    </address>
  </customer>
</p416:executeResponse>
</soapenv:Body>
</soapenv:Envelope>

这比您在清单 5 中所看到的消息更具可读性，因为没有对其进行编码。不过，我必须手动构建响应消息。另外，我没有指出客户机响应的消息的架构。

本文中的 GenericAny.ear 部分提供了一个完整的示例，其中演示了 <xsd:any/> 元素的用法。

松散类型服务与文档/文本样式

松散类型 Web 服务的使用经常与在 WSDL 中定义的服务样式相关。可以将服务的调用样式定义为“文档”或“RPC”，编码方式可为“SOAP”或“文本”。这两项的最常见组合称为“文档/文本”。大部分 Web 服务引擎在缺省情况下都使用“包装的文档/文本”样式。有关这些不同样式的相关文档，请参阅 developerWorks 文章“Which style of WDSL should I use?”。

不过，所使用的样式与是否创建松散类型或泛型的接口没有任何关系。“包装的文档/文本”样式已定义，它将以调用远程过程结束。此远程过程具有一个或多个泛型参数，或强类型参数。同样，您也可以定义一个泛型接口（如上面仅接受一个字符串的接口），然后在 WSDL 绑定中将其声明为“rpc/encoded”。

换句话说，调用样式和接口的强类型这两项设计决策彼此的影响很小（如果有）。

松散类型 Web 服务评估

如上所述，松散类型 Web 服务可以在前面的接口定义中没有声明数据的结构情况下发送数据。很多情况下，这都很有用。例如，假设您具有一组粗粒度的服务，这些服务将可能很大的 XML 文档作为输入。这些文档可能具有不同的结构，具体取决于其使用的上下文。而且，这个结构可能在服务的生存期中经常更改。可以采用某种方式实现一个 Web 服务，使其可以处理所有这些不同类型的消息（很可能对消息进行分析，然后将其路由到其最终的目的地）。可以对消息格式进行更改，使它们具有向后兼容性，这样就无需更新现有的代码。

另一个例子是使用中介。中介具有 Web 服务接口，并接收消息。但很多时候，中介将消息路由到其最终的目的地之前仅对其进行某种常规处理。例如，提供消息记录功能的中介不需要强类型接口，因为它只记录其所接收到的所有消息的内容。

最后，可能存在不能在 XML 架构中描述的消息格式，或选择的 Web 服务引擎不能处理所得到的架构。例如，JAX-RPC 和 Java Architecture for XML Binding (JAXB) 规范就没有定义完整的 XML 架构元素的 Java 映射集。由于存在不能映射的行业标准架构，因此无论如何都必须手动对遵循这些标准的消息进行编码。大部分 JAX-RPC 一致性工具均采用与处理 <xsd:any/> 相似的方式处理这些架构元素，即将其映射到 javax.xml.soap.SOAPElement。

另一方面，您已在上面的示例中已看到，在 SOAP 信封中发送此类任意消息经常需要 SOAP 引擎进行额外的处理。消息一旦经过编码，其线格式可读性可能并不好。此外，您必须手动编写代码以处理消息的有效负载。由于 WSDL 中并没有消息的确切定义，因此 Web 服务工具不能生成此代码，而这将导致此类解决方案更容易出错。无法进行消息验证。如果消息格式更改，那么与确保所有使用者和提供程者正确处理新格式相比，更新服务接口并重新生成绑定代码会更容易。

了解了松散类型方法的种种明显缺点之后，让我们了解一种更好的选择。





回页首


强类型 Web 服务

就像上面讨论松散类型服务时一样，也需要对“强类型”这一术语加以定义。该术语指在 XML 架构中包含了完整的输入与输出消息定义的服务，此 XML 架构或者包含在 WSDL 定义中，或者由该 WSDL 定义引用。

服务使用者和服务提供者必须交换的唯一信息就是 WSDL 定义，因为该定义中包含着构建它们所需的所有信息。例如，以上面将 Customer 文档作为 Web 服务的结果返回的示例为例，强类型 WSDL 定义可能与下面的清单 7 类似。


清单 7. 强类型 WSDL 定义 

				
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions targetNamespace="http://mycomp.com" xmlns:impl=
   "http://mycomp.com" xmlns:intf="http://mycomp.com" xmlns:wsdl=
   "http://schemas.xmlsoap.org/wsdl/" xmlns:wsdlsoap=
   "http://schemas.xmlsoap.org/wsdl/soap/"xmlns:wsi=
   "http://ws-i.org/profiles/basic/1.1/xsd" xmlns:xsd=
   "http://www.w3.org/2001/XMLSchema">
   <wsdl:types>
     <schema targetNamespace="http://mycomp.com" xmlns=
    "http://www.w3.org/2001/XMLSchema" xmlns:impl=
    "http://mycomp.com" xmlns:intf="http://mycomp.com" xmlns:wsdl=
    "http://schemas.xmlsoap.org/wsdl/" xmlns:xsd=
    "http://www.w3.org/2001/XMLSchema">
      <element name="getCustomerResponse">
       <complexType>
        <sequence>
         <element name="getCustomerReturn" nillable="true" type="impl:Customer"/>
        </sequence>
       </complexType>
      </element>
      <element name="getCustomer">
       <complexType>
        <sequence>
         <element name="criteria" nillable="true" type="xsd:string"/>
       </sequence>
       </complexType>
      </element>
      <complexType name="Customer">
       <sequence>
        <element name="address" nillable="true" type="impl:Address"/>
        <element name="name" nillable="true" type="xsd:string"/>
       </sequence>
      </complexType>
      <complexType name="Address">
       <sequence>
        <element name="city" nillable="true" type="xsd:string"/>
        <element name="state" nillable="true" type="xsd:string"/>
        <element name="street" nillable="true" type="xsd:string"/>
        <element name="zip" nillable="true" type="xsd:string"/>
       </sequence>
      </complexType>
  </schema>
 </wsdl:types>
</wsdl:definitions>

现在将不会简单地定义一个字符串或 <xsd:any/> 参数作为返回类型，而要使用一个名为 Customer 的已完整定义的复杂类型。可以将这用于生成 Java 代码，以将任何消息映射到具有 getter 和 setter 的常规 Java 对象中。您无需编写代码来手动分析 XML。

清单 8 显示了此类服务的 Java 实现的格式。


清单 8. 已定义的复杂类型 

				

package com.mycomp;

public class TypedCustomerRetrieval {
     public Customer getCustomer(String criteria) {
		Customer customer = new Customer();
		Address address = new Address();
		address.setCity("Rochester");
		address.setState("MN");
		address.setStreet("4308 Sunshine Blvd");
		address.setZip("55901");
		 
		customer.setName("Joe Smith");
		customer.setAddress(address);
		return customer;
     }

}

JAX-RPC 工具将生成这里使用的 Customer 和 Address 类。与上面的清单 6 一样，通过网上传递的数据是纯 XML。事实上，这些数据与 <xsd:any/> 示例中的数据完全一样。另外还有一个好处，由于存在消息的完整架构，因此可以根据此架构进行验证（尽管大部分引擎由于性能的原因并不这样做）。

本文提供了完整的 TypedService.ear 文件。此文件以及本文的所有其他 ear 文件都还包含测试客户机。

接口与实现

我前面曾提到，某些架构元素不能映射到 Java 中。另外，服务实现者有时候也可能希望开发自己的方式映射传入的 SOAP 消息。另一个例外就是作为 Web 服务一部分的文档可能具有很多元素。服务的开发人员可能不希望将其映射到具有数百个参数的服务接口。

这些情况不要求将 Web 服务设计为松散类型服务，而需要就接口与实现进行讨论。服务可以在其接口定义中采用强类型方式，而在其实现中采用泛型方式 。JAX-RPC 规范要求一致性引擎提供跳过常规 XML 到 Java 类型映射的方法，而使用备用机制。例如，WebSphere® Application Server (Application Server) 允许将任何请求和/或响应消息映射为 javax.xml.soap.SOAPElement 类型的实例（与 <xsd:any/> 的映射方式相似，请参阅上面的清单 4）。例如，上面所列出的 WSDL 摘要中包含完整的类型定义，可以将其映射为以下 Java 服务端点接口，如下面的清单 9 所示。


清单 9. Java 服务端点接口 

				
				注意：这仅是一个示例。

public interface TypedCustomerRetrieval extends java.rmi.Remote {
    public javax.xml.soap.SOAPElement getCustomer
    (javax.xml.soap.SOAPElement parameters) 
throws java.rmi.RemoteException;
}

在此接口中没有 Customer 或 Address 的概念。它完全留给开发人员处理传入和传出的 XML。（请参阅参考资料部分，参考条目中给出了更为详细描述这方面的文章。）

强类型 Web 服务评估

强类型 Web 服务为服务的使用者和提供者提供了服务的数据结构的完整定义。这种正式约定使 SOAP 和 XML 的使用对客户端代码和服务器端代码透明，工具可以方便地从这种正式约定生成代码。如上面所示，在不能或不应使用生成的代码的情况下，可以采用松散类型方式实现强类型接口。顺便说一下，服务提供者和服务使用者可以采用不同的方式进行实现。服务实现者可能喜欢采用手动方式对消息进行映射和分析。不过，通过为使用者提供完整的架构，该使用者可以选择借助工具生成适当的映射代码。这两者之间不需要任何进一步的文档。

在这两种情况下，由于不需要进行编码，所以通过网络传输的消息通常会更小。





回页首


总结

在本文中，我演示了 Web 服务可以如何具有不同的类型级别。松散类型服务使用泛型参数定义，其中不以架构的形式包含消息内容的说明。它们可以包含二进制、字符串或 XML 格式（经过编码的）的信息，但需由服务的使用者和提供者就使用的格式达成一致，并相应地进行处理。当消息格式发生更改，消息格式会随服务内容不同而变化，以及处理普通工具不能处理的高级复杂数据结构时，松散类型服务更加灵活。另外，它们还可以对消息解释进行手动优化。

强类型 Web 服务在 WSDL 中包含完整的架构定义。通常这将提高自动化程度、代码生成质量、工具支持水平和改善标准化中间件的使用。这样还能产生更为稳定的代码，使开发人员不必创建基础结构级别的代码。而且，即使采用泛型方式实现的服务也可以提供强类型接口定义。

在我所遇到的大多数实际场景中，强类型服务接口更为适用。正如我在前面指出的，最好避免使用泛型字符串类型的接口。

不过，并没有万能的东西。常常需要由设计解决方案的架构师确定描述接口的最佳方法，具体取决于解决方案的具体要求、运行环境，甚至还要考虑开发团队的首选的样式。






回页首


下载

描述名字大小下载方法
EAR 文件ws-loosevstrong.zip120 KB FTP
关于下载方法的信息Get Adobe® Reader®

回页首


参考资料

学习

获得产品和技术
  • 了解 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 中的应用程序开发工具和中间件产品。您可以免费下载这些产品的评估版，也可以选择 Linux™ 或 Windows® 版本的 developerWorks 的免费 Software Evaluation Kit。


讨论
影子里的阳光
关注
专栏目录
JS篇(028)-你对松散类型的理解
手掌日月摘星辰
09-14 455
参考答案： JavaScript 中的变量为松散类型，所谓松散类型就是指当一个变量被申明出来就可以保存任意类型的值，就是不像 SQL 一样申明某个键值为 int 就只能保存整型数值，申明 varchar 只能保存字符串。一个变量所保存值的类型也可以改变，这在 JavaScript 中是完全有效的，只是不推荐。相比较于将变量理解为“盒子“，《JavaScript 编程精解》中提到应该将变量理解为“触手”，它不保存值，而是抓取值。这一点在当变量保存引用类型值时更加明显。 JavaScript 中变量可能包含两种
2022年优秀-Web服务实用培训教程.pptx
11-17
- WSDL（Web Services Description Language）：用于定义服务的接口和通信细节，使得服务的消费者能了解如何与服务交互。 - XML Schema（XSD）：定义了服务间交换的数据结构和类型，确保数据的一致性和有效性。 - ...
Web服务类型：SOAP和REST
cunfen6312的博客
07-28 562
Web服务类型：SOAP和REST (Types of Web Services: SOAP and REST) There are two types of web services: Web服务有两种类型： SOAP Web Services SOAP Web服务 REST Web Services REST Web服务 SOAP Web服务 (SOAP Web Services...
Web服务及其应用类型
纯净水
06-27 938
Web服务技术在构造电子商务和电子政务系统方面具有许多非常明显的优势,目前已经成为信息化领域的主流技术。 Web服务的特点 总的来说,Web服务具备以下一些特征: 由于Web服务是一种部署在Web上的对象,因此Web服务具备对象的良好封装性,用户能且仅能看到Web服务提供的功能列表。 对Web服务调用者透明。当一个Web服务的实现发生变更时,Web服务调用者是不会感到这一点的。对于Interne
Web服务（Web Service）
最新发布
听海边涛声
09-16 3441
Web服务（Web Service）
《JavaScript高级程序设计》学习笔记8：JavaScript是松散类型的
王同学LM的专栏
09-09 363
JavaScript让我喜欢的第一点是其松散类型的特点。（与C++比） ECMAScript的变量是松散类型的，所谓松散类型就是可以用来保存任何类型的数据。 var message = 'hi'; message = 100; 除了上面这个简单的例子，JavaScript的松散类型还体现在： 1. 数组 ECMAScript数组的每一项可以保存任何类型的数据，也就是说，可以用数组...
基于J2EE和Web服务的人力资源系统研究.pdf
11-07
这些技术的结合使得Web服务可以与不同的平台和语言进行交互，具有很强的互操作性。 在构建人力资源系统时，组件化设计是一种有效的方法。组件化设计是指将系统分解为多个可以独立开发、测试和部署的小型功能模块，...
Web服务协调中的长时间运行的事务与π演算研究
{cguidi，lucchi，mazzara}@ cs.unibo.it摘要最近，术语Web服务编排已经被引入来解决与Web服务组合和协调相关的一些问题。在过去的几年里，已经提出了几个描述业务流程编排的建议，其中许多语言（例如BPEL 4WS）使用...
WebApplication与WebSite区别.rar_webapplication_website
09-21
相反，`WebSite`是另一种Web项目类型，它更侧重于快速开发和简单部署。Web站点不需预先编译，而是采用按需编译（Just-In-Time Compilation）的方式，这意味着IIS在接收到请求时会自动编译代码。Web站点的结构相对...
"基于契约的Web服务：可视化合同图转换规则
理论计算机科学电子笔记116（2005）145-156www.elsevier.com/locate/entcs基于契约的Web服务Reiko Heckel1帕德博恩大学计算机科学、电气工程和数学学院沃伯格海峡10033098帕德博恩，德国马克·罗曼2帕德博恩大学...
强类型语言与弱类型语言_松散类型与强类型语言
cuk0051的博客
08-31 420
强类型语言与弱类型语言In programming we call a language loosely typed when you don’t have to explicitly specify types of variables and objects. 在编程中，当您不必显式指定变量和对象的类型时，我们将其称为松散类型的语言。 A strongly typed language ...
web服务器有哪几种
2301_77822280的博客
05-03 953
当我们打开电脑，通过浏览器看到的网站，所有网站服务器多是我们所说的web服务器，具体解释就是一种驻留在Internet上的计算机程序，web服务器通过存储网站文件，放置大小不一各类数据文件，来进行工作，所以世界上每个角落多有它的身影。第三种：Jboss 这种我确实没听说过，听说虽然Jboss不如上述两个服务器出名，但它是一个基于J2EE的能开放源代码的应用服务器，这也是它最大的特性，它经过了 LG PL的许可，因此能在任何商业应用中被免费使用，这样的方式无形之中也拓宽了它的人群受众和推广度。
Web服务器常用分类
weixin_41830501的博客
07-19 5471
1.IIS IIS（Internet信息服务）英文InternetInformationServer的缩写。它是微软公司主推的服务器。IIS的特点具有：安全性，强大，灵活。 2.Tomcat Tomcat是Apache软件基金会（ApacheSoftwareFoundation）的Jakarta项目中的一个核心项目，由Apache、Sun和其他一些公司及个人共同开发而成。Tomcat技术先进...
Web服务器的类型
发展是曲折的但也是前进的
08-08 1132
1. 纯web 服务器，它们仅将用户的请求回复一个简单的静态HTML 页面。在这种情况下，你需要将Fl ex 应用程序的SWF 文件嵌入到一个HTML 页面中。 2. web 应用服务器，如JRun、ColdFusion 或者PHP，它们可以动态地生成页面。在这种情况下，你 将使用到与服务器技术相关的库，并动态地处理它们的内容。 3. J2EE 应用服务器或servlet 容器。向一个J2
常见Web服务器类型简介
林中明月间丶
06-12 516
https://blog.csdn.net/yumushui/article/details/38496857
tomcat
0X2B | ~0X2B 的博客
01-10 481
Tomcat是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目，由Apache、Sun 和其他一些公司及个人共同开发而成。由于有了Sun 的参与和支持，最新的Servlet 和JSP 规范总是能在Tomcat 中得到体现，Tomcat 5 支持最新的Servlet 2.4 和JSP 2.0 规范。因为Tomcat 技术先进、性能
常用的WEB服务器简介
weixin_34310369的博客
12-18 317
常用的WEB服务器 WEB服务器也称为WWW服务器、HTTP服务器，其主要功能是提供网上信息浏览服务。Unix和Linux平台下常用的服务器有Apache、Nginx、Lighttpd、Tomcat、IBM WebSphere等，其中应用最广泛的是Apache。而Window NT/2000/2003平台下最常用的服务器是微软公司的IIS。 1、Apache是世界上应用最多的WEB服务器，优势主要...
WEB服务器的基本介绍
jks212454的博客
07-29 1804
WEB服务器的分类一、Web服务器介绍二、Web服务器分类1.IIS2.Tomcat3.Zeus4.Nginx5.Apache6.Lighttpd三、tomcat/nginx/apache区别1.apache和tomcat比较①相同点②不同点2.Nginx与Apache比较四、总结 一、Web服务器介绍 HTTP服务器本质上也是一种应用程序——它通常运行在服务器上，绑定服务器的IP地址并监听某个TCP端口，接收并处理HTTP请求，这样客户端(如Chrome这样的浏览器)就能通过HTTP协议获取服务器上的网页
SOA、Web服务与WCF详解及关系
通过WCF，开发者可以构建出符合SOA理念的、强类型化的、安全的、高性能的服务，并且这些服务可以被任何支持Web服务标准的客户端调用。 在实际应用中，通过WCF，开发者可以创建一个Web服务接口，例如，一个查询员工...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值