ONVIF协议与gSOAP快速入门指南

需积分: 10 191 浏览量更新于2024-07-25 收藏 870KB PDF 举报

"ONVIF_Feature_Discovery_Specification_v12_12[1] 是关于ONVIF协议的文档，其中包含了gSOAP 2.8.11用户指南，介绍了如何开发Web服务客户端应用程序和服务，以及不同版本gSOAP之间的差异。此文档对于网络视频监控领域的专业人士了解和实现ONVIF协议很有帮助。" ONVIF（开放网络视频接口论坛）是一种国际标准，旨在标准化网络视频监控设备间的通信。这个协议允许不同制造商的产品之间能够互操作，提高系统的兼容性和可扩展性。 gSOAP是用于开发Web服务的开源工具包，它支持SOAP（简单对象访问协议）和WSDL（Web服务描述语言），使得在C/C++中创建和使用Web服务成为可能。gSOAP 2.8.11用户指南是开发ONVIF协议应用的重要参考资料，涵盖了从快速入门到详细特性的多个方面： 1. **快速入门**：介绍如何开始开发ONVIF相关的Web服务客户端和服务器应用，帮助开发者迅速上手。 2. **XML数据绑定**：讨论如何将XML数据与C++类绑定，以便在服务中处理XML数据。 3. **版本差异**：详细对比了gSOAP的不同版本（如2.4与2.5，2.1与2.2，1.x与2.x）之间的变化，这对于维护旧代码或升级系统时非常重要。 4. **互操作性**：强调了gSOAP在确保不同系统间通信时的兼容性，这对于ONVIF协议的实施至关重要，因为该协议的目标就是促进设备间的互通。 5. **快速用户指南**：提供了一系列步骤和示例，指导用户如何构建SOAP/XML客户端、生成C++客户端代理类，以及处理响应元素名称、多输出参数等复杂情况。在实际开发过程中，开发者可以按照文档中的步骤生成C++客户端代理类，理解XSD类型编码的考虑因素，并学会如何处理匿名参数名和结构体/类复合数据类型的输出参数。这些功能和指导对于实现ONVIF协议的完整功能和高效通信具有关键作用。通过深入学习和实践这份文档，网络视频监控领域的工程师可以有效地利用ONVIF协议和gSOAP工具来创建符合标准的监控系统，确保设备间的数据交换和控制指令能够准确无误地执行。

trees) the XML output conforms to SOAP encoding for object graphs based on id-ref, see Section 7.5

for details.

To read the XML representation from standard input into a book object, use:

soap *ctx = soap new1(SOAP XML STRICT); // new context with option

book bk;

if (soap read book(ctx, &bk) != SOAP OK) ... error ...

else

cout ¡¡ bk.isbn ¡¡ ”, ” ¡¡ bk.title ¡¡ ”, ” ¡¡ bk.publisher ¡¡ endl;

... further use of bk ...

soap destroy(ctx); // delete deserialized objects

soap end(ctx); // delete temporaries

soap free(ctx); // delete context

Automatic built-in XML validation (enabled with SOAP XML STRICT) ensures that data members

are present so we can safely print them in this example, thus ensuring consistency of data with the

XML schema. Set the ctx->is input stream to read from a ﬁle/string stream instead of stdin.

The soap destroy and soap end calls deallocate the deserialized content, so use with care. In general,

memory management is automatic in gSOAP to avoid leaks.

The above uses a very simple example schema. The gSOAP toolkit handles all XML schema con-

structs deﬁned by the XML schema standard. The toolkit is also able to (de)serialize pointer-based

C/C++ data structures (including cyclic graphs), structs/classes, unions, enums, STL containers,

and even special data types such as struct tm. Therefore, the toolkit works in two directions: from

WSDL/schema to C/C++ and from C/C++ to WSDL/schema.

The toolkit also handles multiple schemas deﬁned in multiple namespaces. Normally the namespace

preﬁxes of XML namespaces are added to the C/C++ type deﬁnitions to ensure type uniqueness.

For example, if we would combine two schemas in the same application where both schemas deﬁne

a book object, we need to resolve this conﬂict. In gSOAP this is done using namespace preﬁxes,

rather than C++ namespaces (research has pointed out that XML namespaces are not equivalent

to C++ namespaces). Thus, the book class might actually be bound to an XML namespace and

the class would be named ns book, where ns is bound to the corresponding namespace.

More information on XML databinding support for C and C++, see Section 7.5.

1.5 Feature Overview

The highlights of gSOAP are:

• Unique interoperability features: the tools generate type-safe SOAP marshalling routines to

(de)serialize native and user-deﬁned C and C++ data structures.

• Support WSDL 1.1, SOAP 1.1, SOAP 1.2, SOAP RPC encoding style, and document/literal

style. gSOAP is one of the few SOAP toolkits that support the full range of SOAP 1.1 RPC

encoding features including sparse multi-dimensional arrays and polymorphic types. For

example, a service operation with a base class parameter may accept derived class instances

from a client. Derived class instances keep their identity through dynamic binding. The

toolkit also supports all XSD schema type constructs and has been tested against the

W3C XML Schema Patterns for Databinding Interoperability working group and of gSOAP

release 2.8.x passes all tests.

• Supports WS-Security, WS-Addressing, WS-ReliableMessaging, C14N exclusive canonicaliza-

tion. The protocols are implemented using code generation with wsdl2h and soapcpp2. The

gSOAP tools can be used to generate messaging protocols for other WS-* protocols.

• gSOAP supports XML-RPC and RSS protocols. Examples are provided.

• JSON support is included in the XML-RPC library to switch between XML-RPC and JSON

protocols. For more details, see the samples/xml-rpc-json folder in the package.

• The wsdl2h tool supports WS-Policy. Policy assertions are included in the generated service

description header ﬁle with recommendations and usage hints.

• gSOAP supports MIME (SwA), DIME, and MTOM attachments and has streaming capabil-

ities to direct the data stream to/from resources. gSOAP is the only toolkit that supports

streaming MIME, DIME, and MTOM attachment transfers, which allows you to exchange

binary data of practically unlimited size in the fastest possible way (streaming) while ensuring

the usefulness of XML interoperability.

• gSOAP supports SOAP-over-UDP.

• gSOAP supports IPv4 and IPv6.

• gSOAP supports Zlib deﬂate and gzip compression (for HTTP, TCP/IP, and XML ﬁle stor-

age).

• gSOAP supports SSL (HTTPS) using OpenSSL.

• gSOAP supports HTTP/1.0, HTTP/1.1 keep-alive, chunking, basic authentication, and digest

authentication using a plugin.

• gSOAP supports SOAP one-way messaging.

• The schema-speciﬁc XML pull parser is fast and eﬃcient and does not require intermediate

data storage for demarshalling to save space and time.

• The soapcpp2 compiler includes a WSDL and schema generator for convenient Web Service

publishing.

• The soapcpp2 compiler generates sample input and output messages for veriﬁcation and testing

(before writing any code). An option (-T) can be used to automatically implement echo

message services for testing.

• The WSDL importer wsld2h (converts to gSOAP header ﬁles) for automated client and server

development.

• Generates source code for stand-alone Web Services and client applications.

• Ideal for small devices such as Palm OS, Symbian, Pocket PC, because the memory footprint

is small.

• Ideal for building web services that are compute-intensive and are therefore best written in

C and C++.

• Platform independent: Windows, Unix, Linux, Mac OS X, Pocket PC, Palm OS, Symbian,

VXWorks, etc.

• Supports serializing of application’s native C and C++ data structures, which allows you to

save and load XML serialized data structures to and from ﬁles.

• Selective input and output buﬀering is used to increase eﬃciency, but full message buﬀering

to determine HTTP message length is not used. Instead, a three-phase serialization method is

used to determine message length. As a result, large data sets such as base64-encoded images

can be transmitted with or without DIME attachments by small-memory devices such as

PDAs.

• Supports C++ single class inheritance, dynamic binding, overloading, arbitrary pointer struc-

tures such as lists, trees, graphs, cyclic graphs, ﬁxed-size arrays, (multi-dimensional) dy-

namic arrays, enumerations, built-in XSD Schema types including base64Binary encoding,

and hexBinary encoding.

• No need to rewrite existing C/C++ applications for Web service deployment. However, parts

of an application that use unions, pointers to sequences of elements in memory, and void* need

to be modiﬁed, but only if the data structures that adopt them are required to be serialized

or deserialized as part of a service operation invocation.

• Three-phase marshalling: 1) analysis of pointers, single-reference, multi-reference, and cyclic

data structures, 2) HTTP message-length determination, and 3) serialization as per SOAP

1.1 encoding style or user-deﬁned encoding styles.

• Two-phase demarshalling: 1) SOAP parsing and decoding, which involves the reconstruction

of multi-reference and cyclic data structures from the payload, and 2) resolution of ”forward”

pointers (i.e. resolution of the forward href attributes in SOAP).

• Full and customizable SOAP Fault processing (client receive and service send).

• Customizable SOAP Header processing (send and receive), which for example enables easy

transaction processing for the service to keep state information.

2 Notational Conventions

The typographical conventions used by this document are:

Sans serif or italics font denotes C and C++ source code, ﬁle names, and shell/batch commands.

Bold font denotes C and C++ keywords.

Courier font denotes HTTP header content, HTML, XML, XML Schema content and WSDL

content.

[Optional] denotes an optional construct.

The keywords ”MUST”, ”MUST NOT”, ”REQUIRED”, ”SHALL”, ”SHALL NOT”, ”SHOULD”,

”SHOULD NOT”, ”RECOMMENDED”, ”MAY”, and ”OPTIONAL” in this document are to be

interpreted as described in RFC-2119.

3 Diﬀerences Between gSOAP Versions 2.4 (and Earlier) and 2.5

To comply with WS-I Basic Proﬁle 1.0a, gSOAP 2.5 and higher adopts SOAP document/literal

by default. There is no need for concern, because the WSDL parser wsdl2h automatically takes

care of the diﬀerences when you provide a WSDL document, because SOAP RPC encoding, literal,

and document style are supported. A new soapcpp2 compiler option was added -e for backward

compatibility with gSOAP 2.4 and earlier to adopt SOAP RPC encoding by default in case you

want to develop a service that uses SOAP encoding. You can also use the gSOAP soapcpp2 compiler

directives to specify SOAP encoding for individual operarations, when desired.

4 Diﬀerences Between gSOAP Versions 2.1 (and Earlier) and 2.2

You should read this section only if you are upgrading from gSOAP 2.1 to 2.2 and later.

Run-time options and ﬂags have been changed to enable separate recv/send settings for transport,

content encodings, and mappings. The ﬂags are divided into four classes: transport (IO), content

encoding (ENC), XML marshalling (XML), and C/C++ data mapping (C). The old-style ﬂags

soap disable X and soap enable X, where X is a particular feature, are deprecated. See Section 9.12

for more details.

5 Diﬀerences Between gSOAP Versions 1.X and 2.X

You should read this section only if you are upgrading from gSOAP 1.X to 2.X.

gSOAP versions 2.0 and later have been rewritten based on versions 1.X. gSOAP 2.0 and later is

thread-safe, while 1.X is not. All ﬁles in the gSOAP 2.X distribution are renamed to avoid confusion

with gSOAP version 1.X ﬁles:

gSOAP 1.X gSOAP 2.X

soapcpp soapcpp2

soapcpp.exe soapcpp2.exe

stdsoap.h stdsoap2.h

stdsoap.c stdsoap2.c

stdsoap.cpp stdsoap2.cpp

Changing the version 1.X application codes to accommodate gSOAP 2.X does not require a signif-

icant amount of recoding. The change to gSOAP 2.X aﬀects all functions deﬁned in stdsoap2.c[pp]

(the gSOAP runtime context API) and the functions in the sources generated by the gSOAP

soapcpp2 compiler (the gSOAP RPC+marshalling API). Therefore, clients and services developed

with gSOAP 1.X need to be modiﬁed to accommodate a change in the calling convention used in

2.X: In 2.X, all gSOAP functions (including the service operation proxy routines) take an addi-

tional parameter which is an instance of the gSOAP runtime context that includes ﬁle descriptors,

tables, buﬀers, and ﬂags. This additional parameter is always the ﬁrst parameter of any gSOAP

function.

The gSOAP runtime context is stored in a struct soap type. A struct was chosen to support applica-

tion development in C without the need for a separate gSOAP implementation. An object-oriented

approach with a class for the gSOAP runtime context would have prohibited the implementation

of pure C applications. Before a client can invoke service operations or before a service can accept

requests, a runtime context needs to be allocated and initialized. Three new functions are added

to gSOAP 2.X:

Function

Description

soap init(struct soap *soap) Initializes a static or stack-allocated context (required only

once)

struct soap *soap new() Allocates, initializes, and returns a pointer to a runtime

context

struct soap *soap copy(struct soap *soap) Allocates a new runtime context and copies contents of the

context such that the new environment does not share any

data with the original context

A context can be reused as many times as necessary and does not need to be reinitialized in doing

so. A dynamically allocated context is deallocated with soap free.

A new context is only required for each new thread to guarantee exclusive access to a new runtime

context by each thread. For example, the following code stack-allocates the runtime context which

is used for multiple service operation calls:

int main()

{

struct soap soap;

...

soap init(&soap); // initialize runtime context

...

soap call ns method1(&soap, ...); // make a remote call

...

soap call ns method2(&soap, ...); // make another remote call

...

soap destroy(&soap); // remove deserialized class instances (C++ only)

soap end(&soap); // clean up and remove deserialized data

soap done(&soap); // detach context (last use and no longer in scope)

...

}

The runtime context can also be heap allocated:

int main()

{

剩余281页未读，继续阅读

lzfhot2008

粉丝: 6
资源: 2

ONVIF协议与gSOAP快速入门指南

使用gsoap2.8.11轻松实现ONVIF_discover教程

OnvifServer_qtonvif_onvifserver_ONVIFSERVERQT.zip压缩包解析

onvifserver-master_ONVIF_server功能编译教程

ONVIF_Test_Specification_v12_12.pdf

ONVIF_Test_Specification_v12_12_Release_Notes.pdf

ONVIF_Base_Test_Specification_v12_12.pdf

ONVIF_Device_Test_Tool_v12_12_

ONVIF_Device_Test_Tool_v12_12_Release_Notes

Onvifshengzhe8688.rar_ONVIF_c onvif_c ONVIF_c# onvif_协议

onvif_src.rar_ONVIF_https://hhadu.com/_nvr onvif_onvif rtsp_rtsp

最新资源