lark.com

火鸟乐园——生活在.net时代
posts - 45, comments - 31, trackbacks - 1, articles - 3
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理

2006年10月10日

我的这个博客,对于我的作用,基本上是一个网络收藏夹。但作为收藏夹,他的功能又太弱了,用起来也太麻烦。一直期望有一个好用的网络收藏夹,曾尝试用QQ的网络收藏,MSN的网络收藏,但都不好用。现在找到一个好用的,www.365key.com,很不错。但是,我更希望IM工具能够提供这项服务。QQ,MSN实现这个功能不难啊,但,为什么不愿意做呢?
另外,现在cnblog是怎么回事,总是很难提交成功。不过,一台服务器支撑这么多用户,也难为人家了。

posted @ 2006-10-10 13:01 火鸟 阅读(62) 评论(0) 编辑

2006年9月12日

即使 SOAP 只是众多访问 Web 服务的可能的绑定之一,它已几乎成为 Web 服务的同义词。这意味着使用 Web 服务的应用程序通常通过绑到 SOAP 的特定实现的 API 来完成工作。本系列文章将描述一个更通用的、独立于 SOAP 的调用 Web 服务的方法,称之为“Web 服务调用框架”(Web Service Invocation Framework(WSIF))。它专门设计来直接调用用“Web 服务描述语言”(Web Services Description Language(WSDL))描述的 Web 服务,隐藏了底层访问协议(比如 SOAP)的复杂性。

Web 服务承诺为因特网分布式计算提供基于标准的平台,集中在简易性和灵活性。一种关键的 Web 服务技术是 WSDL,即“Web 服务描述语言”。使用 WSDL,开发者可以以抽象的形式描述 Web 服务,与用在其它分布式计算框架(比如 CORBA)的现有“接口描述语言”(Interface Description Language(IDL))类似。WSDL 也使 Web 服务开发者能够给服务指定具体的绑定。并且这些绑定描述怎样将抽象服务描述映射到特定访问协议。WSDL 的这部分是可扩展的,这就是说任何人都可以提出他们自己的绑定,使之可能通过某个定制的协议访问服务。

因此,从某种程度来说,使用 Web 服务是一种挑战。对于同样的服务可以有多个绑定。这些绑定中的一些可能适合于一些情形,其它可能适合于另外的情形。绑定本身可以代表抽象服务描述到用来访问服务的任意一种协议的映射。虽然有多种选择使用服务和允许绑定扩展是很有用的,但这给客户机以统一方式查看服务造成了困难。

我以当前客户机端 API 及其性能的讨论开始这篇文章。我将通过讨论来激发人们对 WSIF,即“Web 服务调用框架”的需要,然后继续进行 WSIF 的概述。

当前的调用风格及其缺点
用于 Web 服务的 SOAP 绑定是 WSDL 规范的一部分。在大多数编程语言中,该协议有可用的实现和工具,在许多情况下是免费的。这样,它使得开发者能以微乎其微的成本进行用于 Web 服务的独立于平台的开发。

因此,下述情况是不足为奇的:大多数开发者当想到使用 Web 服务时,在他们头脑中出现的是使用某个 SOAP 客户机 API 来装配一个 SOAP 消息并将它经由网络发送到服务端点。例如,使用 Apache SOAP,客户机将创建和植入一个 Call 对象。它封装了服务端点、要调用的 SOAP 操作的标识、必须发送的参数等等。而这是对 SOAP 而言,它仅限于将其用作调用 Web 服务的一般模型,这是因为下面的原因:

  • Web 服务不仅仅是 SOAP 服务
    将 Web 服务视为 SOAP 上提供的服务的同义词。这是对 Web 服务狭隘的见解。带有功能方面和访问协议 WSDL 描述的任何一段代码均可以被认为是 Web 服务。WSDL 规范为 Web 服务定义了 SOAP 绑定,但是原则上可能要添加绑定扩展,这样,例如,使用 RMI/IIOP 作为访问协议,EJB 就可以作为 Web 服务来提供。或者您甚至可以想象任意一个 Java 类可以被当作 Web 服务,以本机 Java 调用作为访问协议。就这个更广阔的 Web 服务定义来说,您需要用于服务调用的独立于绑定的机制。
  • 将客户机代码绑到一个特殊的协议实现要受到限制
    将客户机代码紧密地绑定到特殊的协议实现的客户机库造成了难以维护的代码。让我们假设您在客户机端有一个用 Apache SOAP v2.1 调用 Web 服务的应用程序。如果您想利用 v2.2 中出现的新的功能和错误修正,您将不得不更新所有的客户机代码,这是一项耗时的任务,将涉及到常见的令人头痛的迁移问题。类似的,如果您想从 Apache SOAP 移到一个不同的 SOAP 实现,这个过程并非无关紧要。所需要的是用于服务调用的独立于协议实现的机制。
  • 将新的绑定融入到客户机代码是很困难的。
    WSDL 允许有定义新的绑定的可扩展性元素。这使开发者能够定义绑定,这种绑定允许使用某种定制协议的代码作为 Web 服务。但是,事实上实现起来是很困难的。将不得不设计使用该协议的客户机 API 。应用程序本身可能正是使用 Web 服务的抽象接口,因此将必须编写一些工具来生成启用抽象层的存根。这些又一次是并非无关紧要的而且耗时的任务。所需要的是使绑定能够被更新或新的绑定能够容易地插入的服务调用机制。
  • 可以以灵活的方式使用多绑定
    例如,设想您已经成功地部署了一个应用程序,该应用程序使用提供多绑定的 Web 服务。为了使这个示例更具体,假设您有用于服务的 SOAP 绑定和允许您将本地服务实现(一个 Java 类)作为 Web 服务的本地 Java 绑定。显而易见,如果客户机部署在与服务本身相同的环境中,只能使用面向服务的本地 Java 绑定,并且如果情况确实如此,通过直接进行 Java 调用而不是使用 SOAP 绑定与服务进行通信将高效得多。Java 绑定作为一种快捷访问机制。接下来,想要利用多绑定可用性的客户机将必须具有一种能力 — 根据运行时信息对要用的实际绑定进行切换的能力。因此为了利用提供多绑定的 Web 服务,您需要一种服务调用机制,允许您在运行时在可用的服务绑定之间进行切换,而不需要生成或重编译存根。

介绍 WSIF
“Web 服务调用框架”(WSIF)是为调用 Web 服务提供简单 API 的工具箱,而不管服务怎样提供或由哪里提供。它具有上面讨论中我确定的所有功能:

 

  • 有给任何 Web 服务提供独立于绑定访问的 API。
  • 提供端口类型编译器来生成允许使用抽象服务接口的调用的存根。
  • 允许无存根(完全动态)的 Web 服务调用。
  • 可以在运行时将更新的绑定实现插入到 WSIF。
  • 可以在运行时插入的新的绑定。
  • 允许将绑定选择延后到运行时。

 

分析 WSIF 的客户机 API
为了进行讨论,我将使用很常见的股票报价程序 — Web 服务的“Hello World”示例。请考虑下面清单 1 所示的使用 WSDL 的抽象服务描述。

清单 1:股票报价 Web 服务的 WSDL 描述

<?xml version="1.0" ?> 
<definitions targetNamespace="http://www.ibm.com/namespace/wsif/samples/stockquote-interface" 
             xmlns:tns
="http://www.ibm.com/namespace/wsif/samples/stockquote-interface" 
             xmlns:xsd
="http://www.w3.org/1999/XMLSchema" 
             xmlns
="http://schemas.xmlsoap.org/wsdl/"> 
  
<message name="GetQuoteInput"> 
    
<part name="symbol" type="xsd:string"/> 
  
</message> 
  
<message name="GetQuoteOutput"> 
    
<part name="quote" type="xsd:float"/> 
  
</message> 
  
<portType name="StockquotePT"> 
    
<operation name="getQuote"> 
      
<input message="tns:GetQuoteInput"/> 
      
<output message="tns:GetQuoteOutput"/> 
    
</operation> 
  
</portType> 
</definitions>


足够简单:它描述了只带有由一个端口类型提供一个操作的服务。该操作等待一个字符串,被解释为股票的报价机符号,然后返回当前该股票报价,一个浮点值。为了实际使用该服务,您需要某个定义访问机制的绑定以及该绑定的服务端点。清单 2 展示了该服务的 SOAP 绑定:

清单 2:股票报价 Web 服务的 SOAP 绑定

 

<?xml version="1.0" ?> 
<definitions targetNamespace="http://www.ibm.com/namespace/wsif/samples/stockquote" 
             xmlns:tns
="http://www.ibm.com/namespace/wsif/samples/stockquote" 
             xmlns:tns-int
="http://www.ibm.com/namespace/wsif/samples/stockquote-interface" 
             xmlns:xsd
="http://www.w3.org/1999/XMLSchema" 
             xmlns:soap
="http://schemas.xmlsoap.org/wsdl/soap/" 
             xmlns:java
="http://schemas.xmlsoap.org/wsdl/java/" 
             xmlns
="http://schemas.xmlsoap.org/wsdl/"> 
  
<import namespace="http://www.ibm.com/namespace/wsif/samples/stockquote-interface" 
          location
="stockquote-interface.wsdl"/> 
  
<binding name="SOAPBinding" type="tns-int:StockquotePT"> 
    
<soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> 
    
<operation name="getQuote"> 
      
<soap:operation soapAction="http://example.com/GetTradePrice"/> 
      
<input> 
        
<soap:body use="encoded" 
                   namespace
="urn:xmltoday-delayed-quotes" 
                   encodingStyle
="http://schemas.xmlsoap.org/soap/encoding/"/> 
      
</input> 
      
<output> 
        
<soap:body use="encoded" 
                   namespace
="urn:xmltoday-delayed-quotes" 
                   encodingStyle
="http://schemas.xmlsoap.org/soap/encoding/"/> 
      
</output> 
    
</operation> 
  
</binding> 
  
<service name="StockquoteService"> 
    
<documentation>Stock quote service</documentation> 
    
<port name="SOAPPort" binding="tns:SOAPBinding"> 
      
<soap:address location="http://localhost:8080/soap/servlet/rpcrouter"/> 
    
</port> 
  
</service> 
</definitions>

这是一个标准的 SOAP 绑定,使用 RPC 风格和作为传输协议的 HTTP 与服务进行通信。在文档的 port 部分中,我定义了使用 SOAP 绑定可以访问服务的 URI。在清单 3 中,我将就通过 Apache SOAP 2.2 客户机端 API 和 WSIF 的客户机 API 使用该服务进行对比。

清单 3:用于服务访问的 Apache SOAP API 与 WSIF API 对比

Apache SOAP API

 

// Step 1: identify the service 
 Call call = new Call(); 
 call.setTargetObjectURI(
"urn:xmltoday-delayed-quotes"); 
 
// Step 2: identify the operation 
 call.setMethodName("getQuote"); 
 call.setEncodingStyleURI(encodingStyleURI); 
 
// Step 3: identify the parameters 
 Vector params = new Vector(); 
 params.addElement(
new Parameter("symbol"
                          String.
class, symbol, null));
 call.setParams(params); 
 
// Step 4: execute the operation 
 Response resp = call.invoke(url, 
                   
"http://example.com/GetTradePrice");
 
// Step 5: extract the result or fault 
 if(resp.generatedFault()) 
 

   Fault fault 
= resp.getFault(); 
   System.out.println(
"Ouch, the call failed: "); 
   System.out.println(
"  Fault Code   = " +  
                      fault.getFaultCode()); 
   System.out.println(
"  Fault String = " +  
                      fault.getFaultString()); 
   
throw new SOAPException("Execution failed " + fault); 
 }
 
 
else 
 

   Parameter result 
= resp.getReturnValue(); 
   
return ((Float) result.getValue()).floatValue(); 
 }


WSIF API

 

// Step 1: identify the service 
 Definition def = WSIFUtils.readWSDL(null,wsdlLocation);
 
// Step 2: identify the operation (choose an 
 
// appropriate service port) 
 WSIFDynamicPortFactory portFactory = 
        
new  WSIFDynamicPortFactory(def, nullnull); 
 
// Get default port 
 WSIFPort port = portFactory.getPort(); 
 
// The user can also explicitly select a port  
 
// to use. 
 
// WSIFPort port =  
 
//             portFactory.getPort("SOAPPort"); 
 
// Step 3: identify the parameters 
 
// Prepare the input message 
 WSIFMessage input = port.createInputMessage(); 
 input.setPart(
"symbol",  
               
new WSIFJavaPart(String.class, symbol));
 
// Prepare a placeholder for the output value 
 WSIFMessage output = port.createOutputMessage(); 
 
// Step 4: execute the operation 
 port.executeRequestResponseOperation("getQuote"
                             input, output, 
null);
 
// Step 5: extract the result or fault 
 WSIFPart part = output.getPart("quote"); 
 
return ((Float)part.getJavaValue()).floatValue();


正如您可以看到的,WSIF 的 API 由以 WSDL 编写的抽象服务描述驱动;它完全从实际使用的绑定中分离出来。该调用 API 是面向 WSDL 的,并且使用它更自然,因为它使用 WSDL 术语引用消息部件(message part)、操作等等。当您阅读一个 WSDL 描述,出于直觉会想到选用支持所需端口类型的端口,然后通过提供必需抽象输入消息(由必要部件组成)调用操作(不用担心怎样将消息映射到特定的绑定协议);WSIF API 就是这样设计的。

常用的 API,比如上面所示的 Apache SOAP API 采用了以特殊协议为中心的概念,比如在使用 SOAP 的情况下,目标 URI 和编码风格。这是不可避免的,因为 API 不是普遍适用于 WSDL,而是为特殊的协议设计。

两种使用 WSIF 的调用模型
WSIF 允许 Web 服务以两种方式调用。一种是无存根的动态调用,它要求直接使用 WSIF API;另一种是通过生成允许应用程序使用 Java 接口(直接对应于 WSDL 端口类型)和隐藏了 WSIF API 的存根的调用。

无存根(动态的)调用
访问 Web 服务所需的所有信息 — 抽象接口、绑定和服务端点可以通过 WSDL 得到。如果您仔细查看上面的客户机 API 示例,您将会注意到唯一由用户提供的信息是用于服务的 WSDL 文件位置和所需要的股票报价符号。很明显接下来是用 WSFL API 在运行时装入这个服务和进行该调用。

WSIF 分发包包含了演示怎样执行 WSDL 的任意一个操作的 DynamicInvoker。它以 WSDL 文件的 URI 和所需的操作参数作为命令行参数(在最初的实现中只接受简单的类型,如字符串),并且直接使用 WSIF API 完成工作。其用来调用股票报价服务的示例如清单 4 所示;您可以在包含 WSIF 分发包的文档中查找详细信息。

因为这类调用不会导致生成存根类,并且不需要单独的编译周期,所以它很方便。

清单 4:使用 DynamicInvoker 访问股票报价服务

java clients.DynamicInvoker http://services.xmethods.net/soap/urn:
    xmethods-delayed-quotes.wsdl getQuote IBM
Reading WSDL document from 'http://services.xmethods.net/soap/urn:
    xmethods-delayed-quotes.wsdl'
Preparing WSIF dynamic invocation
Executing operation getQuote
Result:
Result=108.8
Done!

使用存根的调用
在应用程序需要更抽象的服务视图和不希望处理 WSIF 客户机 API 的情况下,无存根调用不适用。WSIF 提供一个端口编译器,如果给定一个 WSDL,与所用到的复杂类型的 Java 等价物(以 JavaBean 的形式)一起,端口编译器将为每一个端口类型生成一个客户机存根。使用生成存根的应用程序可以利用抽象服务接口,并且这样与协议和 WSIF 客户机 API 分离。对于实际服务调用,这些存根使用缺省端口。通过由 WSIF 的端口类型编译器生成的存根使用股票报价服务的示例如清单 5 所示。

清单 5:使用生成存根的 WSIF 访问股票报价服务。

 

StockquotePT service = new StockquotePTStub(WSIFUtils.readWSDL(null, wsdlLocation), 
    
nullnull);
float quote = service.getQuote("IBM");
System.err.println (
">> Received quote: "+quote);

值得注意的是存根驻留在某些受管环境(如应用程序服务器)的情况,它们能够被定制;例如,可以改变负责返回恰当端口的工厂来定制端口选择算法,或者可以改变用于调用自身的实际端口。

在这篇文章中,我略述了对 WSIF 的需要,分析其通过高级 API 进行独立于绑定的服务访问的主要特征以及生成可定制的存根(通过其抽象接口使用服务)的端口类型编译器的可用性。直接通过 SOAP 客户机 API 和使用 WSIF API 进行服务访问之间的对比展示了 WSIF(由服务的 WSDL 描述驱动)怎样将 Web 服务调用的全部问题从以绑定为中心的观点转移到更抽象的级别。这是 WSIF 的设计原则之一,使服务绑定能被看作是根据特殊协议进行调用所需的代码片断,可以在任何时候插入它们。

在接下来的文章,我将分析 WSIF 的体系结构,看一看它怎样允许新的或更新的绑定实现被插入,它怎样使定制的类型系统用于 Web 服务以及怎样使运行时环境使用定制的探索性方法在多端口之间进行选择。

参考资料

  • 请参加关于这篇文章的讨论论坛
  • 请下载 alphaworks 上的 WSIF 分发包,并且试验比较简单的样本。它将给您一个由 WSIF 支持的不同调用风格的第一手示例以及它优于特定协议客户机 API 的优势。
  • 重温 WSDL 规范,看一看允许哪一种扩展;如果用来为访问 Web 服务定义 SOAP 绑定,您也可以学习 WSDL 的扩展机制。
  • 重温 SOAP 规范本身。
  • 如果以前您没有对 Web 服务编过程,Web Services Toolkit 是很好的起点。
  • 请查看 WSDL4J,一个可扩展的 WSDL 分析框架,WSIF 在此基础上进行构建。

 

关于作者
Nirmal K. Mukhi 是 IBM 的 T J Watson Research Lab 的副研究员,自 2000 年 11 月,他一直在从事各种 Web 服务技术的研究。他还对 AI、创造性写作以及过时的计算机游戏感兴趣。您可以通过
nmukhi@us.ibm.com 与 Nirmal 联系。




转载自:http://www.itepub.net/page/article/htmldata/2004_10/17/76/article_3575_1.html

posted @ 2006-09-12 17:10 火鸟 阅读(88) 评论(0) 编辑

2006年8月17日

本文网址:http://bbs.mobile.163.com/mbbuy/13288,2.html   复制

大家一直对手机电池的充电使用保养有着不同的认识,在这里我想统一一下大家的观点,并且纠正一下一些错误的看法.

  说到这个锂离子电池呢,先来简单的介绍一下,所谓锂离子电池就是使用能够吸藏·脱离锂离子的碳材料作为负极活性物质的电池,锂离子符号为

  Li-ion

  。大家知道作为电池一般都是由正极,负极,隔膜,电解液等基本的元素组成,那么锂离子电池所用的这些材料一般是以下一些物质:

  正极:钴酸锂(

  LiCoO2

  )、镍酸锂(

  LiNiO2

  )锰酸锂(

  LiMn

  2

  O

  4

  )等;

  负极:人造石墨系列、天然石墨系列、焦炭系列等等;

  隔膜:聚乙烯(

  PE

  )、聚丙稀(

  PP

  )等组成的单层或者多层的微多孔薄膜;

  电解液:碳酸丙稀酯(

  PC

  )、碳酸乙烯酯(

  EC

  )、二甲基碳酸酯(

  DMC

  )、二乙基碳酸酯(

  DEC

  )、甲基乙基碳酸酯(

  MEC

  )等组成的一元、二元或者三元的混合物

  市场上所售的锂离子电池大多是以钴酸锂为正极,石墨系列为负极的电池。

  锂离子电池的工作机理是:电池充电时,正极材料中的锂形成离子溶出,嵌入到负极改性石墨层中;电池放电时,锂离子从石墨层中脱嵌,穿过隔离膜回填到正极钴氧化锂的层状结构中。随充放电的进行锂离子不断的从正极和负极中嵌入和脱出,所以也有人称其为“摇椅电池”锂离子电池单体的额定电压为

  3.6V,充电限制电压为

  4.2V,放电限制电压为

  2.5V

  。

  锂离子电池的充电过程分为两个步骤:先是恒流充电,其电流恒定,电压不断升高,当电压充到

  4.2V

  的时候自动转换为恒压充电,在恒压充电时电压恒定,电流是越来越小的直到充电电流小于预先设定值为止,所以有人用直充对手机电池进行充电的时候明明电量显示已经满格了,可是还是显示正在充电,其实这个时候的电压已经达到了

  4.2V

  所以电量显示为满格,那时就是在进行恒压充电过程,那么有人也许会问,为什么要进行恒压充电呢,直接用恒流充到

  4.2V

  不就行了吗,其实很容易解释,因为每一个电池都有一定的内阻,当用恒流进行充电到

  4.2V

  的时候,这个

  4.2V

  其实并不是电池实际的电压,而是电池的电压加上电池内阻上消耗的电压之和,如果电流很大那么在内阻上消耗的电压也就很大,所以那是实际电池的电压可能比

  4.2V

  小很多,所以要用恒压充电过程,把充电的电流慢慢降下来,这样电池的实际电压就很接近

  4.2V

  。

  大家在使用锂离子电池的过程中其实没有必要了解这么多,大家只要知道如何的充电,如何的放电,如何的使用才能使电池最大限度的发挥作用和保持良好的循环性能。下面呢我就这一方面谈谈我的一些看法:

  1.锂离子电池最好是使用原装的充电器,否则会一定程度的损坏电池和影响其使用寿命;

  2.对于直充和座充的问题,我认为,如果时间允许的情况下最好用座充,这样既可以延长电池的使用寿命同时也可以增加单次的充电容量;

  3.如果电池长时间的不使用,那么最好是充入

  40

  %左右的电量在

  10

  ~

  30

  ℃的温度下保存,并每半年左右补一次电;

  4.对于刚买的新电池,有人说前三次充电必须要充十几个小时以便充分的激活电池,我认为没有这个必要,当然对于新电池来说前几次的容量可能比以后会有所减少,那是电池长期存储,活性物质表面钝化

  造成的

  ,我认为前几次充电用座充充到绿灯亮以后一两个小时足够了,当然充电时间会随你的充电器的充电电流和你电池的容量的不同会有变化,总之并不是充电时间越长越好,这样非但不能激活电池,相反会影响寿命,严重的话(如果你的充电器电压精度控制不够)还会爆炸。

  5.在电池的长期使用过程中往往大家有一个认识上的误区,我有必要跟大家说说,大家往往认为电池的使用次数是一定的,比如是

  500

  次,所以呢每一次都要充分的利用,所以就要求每一次充电一定要尽量的充满,每一次放电呢要尽量的放干净,似乎这样使用才是最有效的利用,其实不然,电池的使用寿命跟你的使用情况是存在一定的关系,假如你电池的循环寿命是

  500

  次的话,如果你使用得当,那么也许它可以使用

  700

  ~

  800

  次,所以说正确的使用方法是充电不要充太满,

  90

  %左右就够了,在使用过程中看到电量低了,马上就可以充电,而不要等到它自动关机甚至自动关机以后还不进行充电,我们在实验室曾经做过这样的试验:

  80

  %

  DOD

  的电池的使用寿命比

  100

  %

  DOD

  的电池的使用寿命长

  30

  %左右;

  6.还有一点也很重要,锂离子电池对充电器要求很严格,对于充电电压的限制很严格,你必须看清楚它的要求是

  4.1V

  还是

  4.2V

  ,因为如果负极使用的时石墨系列,那么限制电压时

  4.2V

  ,如果负极用的是焦炭系列的话那么限制电压是

  4.1V,

  这个一般电池上都会说明的,总之充电器和电池一定要匹配,你不能用

  4.2V

  的充电器去充

  4.1V

  的电池;

  7.还有一点必须强调:绝对不能用充镍·氢电池或者镍·铬电池的充电器来充锂离子电池,这样不仅会损坏电池而且有可能会爆炸;

  8.锂离子电池没有记忆功能,所以每次充电不像镍·氢电池和镍·铬电池一样需要放电,它可以随时随地的进行充放电。

  总的来说,不要迷信12小时的头三次充电,也不要总是害怕而去故意放电,只要尽量是用完充,充满用,不要过于的去强调什么,手机电池的寿命是很长的,否则只会弄巧成拙.

posted @ 2006-08-17 21:41 火鸟 阅读(135) 评论(2) 编辑

11国支持闪联标准

  据闪联工作组组长孙育宁昨日介绍,7月底,ISO开始投票程序,这次的投票数量总共有20票,而闪联获得了19票赞成。经过2年多艰苦的努力,闪联正式通过ISO/IEC立项,目前已经有包括美、英、法、德、澳在内的11个国家明确表示参与闪联标准。

  “通过该立项意味着闪联技术的先进性和产业定位获得了各国专家的高度认可。”孙育宁表示,这意味着闪联已经成为我国3C领域内第一个迈向国际化的标准,闪联成为国际标准已经只剩下了程序和时间问题。

  “尽管闪联成为国际标准还需要有一个较长时间的程序和过程,但我对此表示乐观。”孙育宁认为,闪联成为国际标准还代表着中国十几年来在家庭网络方面缺席国际标准制定的被动局面已经彻底打破,表明我国电子信息业的核心竞争力正在增强。

  在闪联之前,我国的WAPI标准在争取成为国际标准的过程中屡次遭受排挤,在ISO的数次会议上也遭受过不平等待遇,为此ISO还特意召开了几次调解会,但至今WAPI仍然无法顺利登上国际舞台,获得平等话语权。相比之下,闪联走出国门的过程比较顺利。

  今年3月,闪联组织代表中国家庭网络标准出席了中日韩三国区域性家庭网络标准会议。会上,闪联与日韩规模最大、最具影响力的标准组织签署协议,成立了亚洲第一个跨地区的家庭网络标准组织。此后,闪联积极争取台湾厂商如C-Media等的支持,以期从产业的供应环节应用新技术,并大幅削减生产成本。

  “实体化”推动闪联

  在内业人士看来,成立实体公司是推动闪联标准的一个关键步骤。2005年年底,闪联成立实体公司,由工作组组长孙育宁担任该公司总裁。但是当时此举一度遭受外界质疑。

  “任何一个标准都是由市场来检验,同时由完整的产业链才能把它运作起来的。以前业界很多标准的效果不好,但闪联此举应该是个很好的形式。”中国电子技术标准化研究所副总工程师王立健认为,一直以来与我国的WAPI竞争的最大一个标准组织WIFI实际上就是类似“公司实体”的运作形式,“尽管WIFI联盟形式上不是一个实体公司,但它背后一直是英特尔在推动,产品也主要以英特尔公司的迅驰产品为主要应用”。

  在获悉闪联有望成为国际标准之后,闪联工作组内部成员这样评价此次成果。

  “闪联作为下一代互联网的核心应用模式,代表3C技术发展趋势,也代表了3C产业发展的未来。闪联被ISO/IEC接纳还意味着包括信产部、发改委、科技部在产业引导和推动方面的成果,也显示了包括中关村管委会、中关村科技园区对创新科技和民族品牌的大力支持。另外,闪联作为中国企业自主集体创新的典型,也有可能引领中国整个电子信息技术领域实现新的跨越。”

  闪联成员建议强推闪联

  对于闪联下一步如何“走”,昨日,闪联高层表示目前还不便透露。

  “闪联应多用行政的手段要求政府采购闪联产品。

  应把它变成一种强制标准,同时应该注意为联盟成员谋求更多利益。“对于闪联标准的好消息,闪联组织核心成员长城电脑公司相关负责人昨日向记者表示,闪联取得的成绩值得欣慰,他同时对闪联的下一步提出”建设性意见“。

  本报记者 焦集瑩

  资料 闪联标准

  闪联标准(信息设备资源共享协同服务标准)是指通过定义一系列的协议标准,支持各种3C设备智能互联、资源共享和协同服务,实现“3C设备+网络运营+内容/应用”

  的全新网络架构,为未来的终端设备提供商、网络运营商和网络内容和应用提供商创造出健康清晰的赢利模式,为用户提供高质量的信息服务和娱乐方式。

  2003年闪联成立之初便有联想、康佳、长城、TCL、海信等几大3C领域厂商的鼎力支持,此后每年都发展数十家会员单位。目前闪联已成为我国最大的3C领域标准组织,拥有包括电脑软硬件、数码、通信、黑电、白电、网络及内容提供商等在内的完整产业链条。


 

posted @ 2006-08-17 17:18 火鸟 阅读(36) 评论(0) 编辑

MPEG2 TS与ISMA的比较
  1. 目的比较
ISMA仅是为了Internet上的流媒体服务而做的标准,因此其目标是互联网上的低码率点播节目和低并发率。TS则是媒体行业通用的标准,其目标是基于宽带的数字视频广播,并且支持多种基本媒体流和多种媒体编码标准,已经有十多年实际的大规模普遍性应用,得到全球广播行业和互联网行业的一致认同。而ISMA的历史相对较晚,且在行业上的认同度较低,也没有大规模的部署案例。
2. Streaming Server的兼容性与升级
a) 文件格式的兼容性
在ISMA中,不同的编码标准有不同的文件格式,比如MPEG-4和H.264的文件格式都不一样,因此在文件格式上是没有任何兼容性的。而TS的存储则与媒体编码格式无关,MPEG-2 TS可以将任何格式的内容封装到它里面。在对TS流进行存储时,只需将其进行分段处理,然后加上Index信息,并与TS流共同存储即可。因此采用TS流的文件格式具有更好的兼容性,这对IPTV平台的平滑升级来说,是一个完美的解决方案。
b) 流格式的兼容性
i. ISMA 1.0/1.1与ISMA 2.0
体系架构区别较大,升级困难,主要表现在以下几个方面:
? ISMA1.0视频基于MPEG-4 Part2,以SP和ASP为基础,并没有涉及到H.264, 而ISMA2.0则是基于H.264;
? ISMA2.0不兼容ISMA1.0,即ISMA1.0的servers和Clients不能平滑升级到ISMA2.0系统具体原因表现在:
? 视频RTP包的封装模式不兼容:ISMA1.0的视频RTP打包遵循“RFC3016: RTP Payload Format for MPEG-4 Audio/Visual Streams”,而ISMA2.0的视频RTP打包符合“RTP Payload Format for H.264 Video”(目前该RFC没有正式发布),加入了一些特有的限制和扩展,如不允许采用交织模式、不允许通过RTP包传输视频序列参数和帧图像参数等;
? SDP消息格式不兼容:由于ISMA1.0和ISMA2.0 视频RTP打包方式的不一样,导致SDP的消息承载格式和内容也不一样,如交织模式的定义参数不能在SDP消息中出现,有关视频序列参数和帧图像参数通过SDP传输、增加了一些特有的域等;
? 文件的存储方式不一致:ISMA1.0基于MPEG-4 Part14(*.MP4), 而ISMA2.0的文件格式基于MPEG-4 Part15(*.avc1),对ISMA1.0的文件格式进行了扩展,如H.264的参数存在文件中的AVCDecoderConfiguration等。
ii. H.264
目前H.264专业级编码器主要是以TS为主,而支持H.264的ISMA2.0刚出来,还没有支持。
3. 处理方法和性能
a) 处理方法
ISMA的处理方法是:从编码端到解码端的所有环节,均需建立多个音视频和其他数据流的RTP Session,因此在做Streaming Server的I/O时,需要管理多个输入输出,多个Buffer的管理以及它们之间的同步,将极大地增加Streaming Server的处理能力要求,也带来了较大的算法复杂性,同时降低了系统的稳定性和可*性。而TS则将多个音视频和其他数据流复用在一起,仅需建立一个RTP Session,因此在做I/O,Buffer管理和音视频同步等方面将会简单和容易得多。
b) 端口需求
在NAT和防火墙上,ISMA需要为音视频RTP分别分配端口,是TS流的两倍。
c) 性能
从上面的处理方法可以看出,用ISMA标准需要管理更多的RTP Session,要管理更多的I/O和Buffer,将极大的消耗Streaming Server和STB的CPU性能和内存,从而严重地影响系统的性能。根据Darwin系统及其实验,我们在一台高性能机器上,也只能跑较少的Stream并且会有掉线情况发生。若采用TS流,则会支持几百个2M以上的Stream并且不会掉线。
d) AV Sync
ISMA的AV Sync是依*RTP中的Time Stamp来实现,因此在同步时,需要等到音视频的RTP都到达后才能实现AV Sync。而TS流则不存在此问题,因为其时间信息都在一个流中。而且TS的AV Sync只需在编码和解码端实现,中间的其他环节,如流服务器等,不需要参与,可以降低Streaming Server的算法和处理复杂度。ISMA则相反,不光需要编解码器,同时需要Streaming Server参与AV Sync的处理,消耗了Streaming Server的资源,增加了算法复杂度和性能代价,并且降低了系统的可*性和稳定性。
e) 解码端
用ISMA对解码器的要求也比TS流更高。TS流的主要工作是在解复用上,即解复用器需要分析PSI信息,然后根据PSI信息获取音视频的PID,在通过PID滤波,得到视音频流,输出到各自的Buffer中。由于TS是固定的188字节包结构,因此PID在包中的位置固定,滤波很容易实现。根据我们的评估,采用软件TS流解复用的方法,在Equator BSP-15平台上,占用的CPU资源不足5%。而用ISMA时,由于多个RTP Session,因此需要有多个Buffer,并对其管理。所以采用ISMA时使用的Memory和CPU资源也更多。
4. 对直播的支持
a) 频道切换
若采用ISMA方式,在Live TV做频道切换,STB需要从系统中重新获取ISMA的文件头。因为STB解码时所需的很多信息在此文件头中。所以系统还必须还有一整套ISMA的文件头的生成和管理。同时还会造成解码频道切换的延迟。
在Live TV做频道切换时,STB还需要获取SDP以便得到解码所需要的一些具体参数。再加上传统的ISMA流中I帧间隔较长,一般多于4秒,从而造成STB的频道切换时间长,完全不能满足电信标准规定的2秒钟。
b) 直播参数的改变
在做Live TV时,如果编码器的参数被修改了之后,需要STB与编码器或Streaming Server重新建立RTSP Session,以获取新的SDP,然后才能从SDP中得到解码所需要的一些具体参数。而在TS流中,所有的解码参数均是伴随着码流一起下来的,因此不需要建立另外的Session,解码器反应速度会更快。
5. Trickmode和DRM
a) 在ISMA中,没有一个关于Trickmode的详细的定义,特别是在RTP中。因此各个厂家的Trickmode定义都不一样,导致没有一个统一的标准,标准也就失去意义。若采用TS流的方式,则我们可以在其extension中详细定义Trickmode的相关信息,可以定义该RTP是Trickmode还是正常播放,以及Trickmode的具体模式等。同时还可以通过扩展,定义丢包重传机制,保障用户的服务质量。
b) 在ISMA中,虽然定义了DRM采用AES的加密方法,但其DRM不具有扩展性。表现在:不支持多种DRM方法和加密标准,不支持对Key的管理。而TS则刚好解决了这一点,可以在RTP的extension中可以定义Key的管理方法和映射关系,以及不同的DRM方法和标准。使得系统在DRM方面具有广泛的兼容性。
6. 内容考虑
a) CP的支持
目前,大部分CP都是电视台、电影公司和广电公司,他们主要的片源都是采用MPEG-2 TS流封装格式。因此TS能更好的适应CP的主要现状和需求。
b) 专业编码器支持
目前全球的主要专业编码器如Tandberg,Harmonic等都支持TS流封装格式,只有少数厂家支持ISMA流格式。
7. 芯片支持
目前,所有的MPEG-4和H.264的解码芯片均支持TS。所以选择TS可以为STB提供更多的选择方案,利于降低STB的成本。
8. 家庭网络
a) STB要接入家庭网络,需要支持DLNA。而在DLNA中,MPEG-2及TS是必选标准。
b) 目前家庭网络中所有的摄像机和数码相机均支持MPEG-2 TS而不支持ISMA。
c) 目前家庭网络中所有的DVR,编辑设备均支持TS,而很少支持ISMA。
9. 传统数字电视的支持
a) 目前在广电领域,DVB全部是采用TS流封装格式。因此,若采用TS,可以做到与广电领域完全兼容,特别是在STB上的处理方式可以完全一致,增加了IPTV与DVB的兼容性,这样更有利于电信与广电的竞争。
b) 广电的趋势是今后支持H.264 (MPEG-4 AVC),并采用TS流封装格式。因此有利于我们平滑升级到H.264。则可以直接从卫星上接受信号并直接进入IPTV系统,不用转码。
c) TS是一个真正的开放性的标准,有利于实现真正的“三网合一”。
10. 媒体汇聚和交换
采用TS格式,利于媒体的交换和汇聚。IPTV网络的最终目标是发展为内容交换网络。显然,媒体文件过大,并不利于内容的交换。而TS每个包只有188个字节,格式固定,利于交换。同时,TS是媒体行业通用的标准,这样利于媒体的汇聚,可以支持我们从网络的不同节点获取内容,并汇聚成一个完整的内容。

posted @ 2006-08-17 17:15 火鸟 阅读(1566) 评论(0) 编辑