WCF技术剖析之二十五: 元数据(Metadata)架构体系全景展现[元数据描述篇]

简介: 原文:WCF技术剖析之二十五: 元数据(Metadata)架构体系全景展现[元数据描述篇]在[WS标准篇]中我花了很大的篇幅介绍了WS-MEX以及与它相关的WS规范:WS-Policy、WS-Transfer和WSDL,因为WCF元数据结构体系完全是基于WS-MEX等相关的规范之上。
原文: WCF技术剖析之二十五: 元数据(Metadata)架构体系全景展现[元数据描述篇]

[WS标准篇]中我花了很大的篇幅介绍了WS-MEX以及与它相关的WS规范:WS-Policy、WS-Transfer和WSDL,因为WCF元数据结构体系完全是基于WS-MEX等相关的规范之上。熟悉这些基本的WS规范,对于我们全面、深刻的理解WCF整个元数据架构体系具有十分重要的意义。不仅仅是针对元数据,对于后续章节陆续要介绍的内容,比如事务、可靠会话、安全等,我强烈建议读者在正式进行相关部分的学习之前,先对相关的WS规范作一个大致的了解。

通过对WS-MEX的介绍,我们知道:不论是采用WS-Transfer Get操作还是Get Metadata操作,获取到的元数据被封装到回复消息主体部分的<Metadata>结点中,而<Metadata>是一组<MetadataSection>元素的集合。在托管的世界里,<MetadataSection>元素和<MetadataSection>元素集合有相应的类型来表示,那就是我们接下来要着重介绍的MetadataSectionMetadataSet

一、MetadataSection

MetadataSection定义在System.ServiceModel.Description命名空间下,用于用于定义基于某种方言(Dialect)的元数据,该类型和WS-MEX中包含元数据SOAP消息主体的<MetadataSection>结点相匹配。我们不妨现在看看MetadataSection的定义:

   1: [XmlRoot(ElementName="MetadataSection", Namespace="http://schemas.xmlsoap.org/ws/2004/09/mex")]
   2: public class MetadataSection
   3: {    
   4:     //其他成员
   5:     public MetadataSection();
   6:     public MetadataSection(string dialect, string identifier, object metadata);   
   7:    
   8:     [XmlAnyAttribute]
   9:     public Collection<XmlAttribute> Attributes { get; }
  10:     [XmlAttribute]
  11:     public string Dialect { get; set; }
  12:     [XmlAttribute]
  13:     public string Identifier { get; set; }
  14:     [XmlElement("Location", typeof(MetadataLocation), Namespace="http://schemas.xmlsoap.org/ws/2004/09/mex")]
  15:     [XmlElement("MetadataReference", typeof(MetadataReference), Namespace="http://schemas.xmlsoap.org/ws/2004/09/mex")]
  16:     [XmlElement("Metadata", typeof(MetadataSet), Namespace="http://schemas.xmlsoap.org/ws/2004/09/mex")]
  17:     [XmlElement("schema", typeof(XmlSchema), Namespace = "http://www.w3.org/2001/XMLSchema")]
  18:     [XmlElement("definitions", typeof(ServiceDescription), Namespace = "http://schemas.xmlsoap.org/wsdl/")]
  19:     [XmlAnyElement]
  20:     public object Metadata { get; set; }   
  21:  
  22:     //四种预定义元数据方言(Dialect)
  23:     //MEX:http://schemas.xmlsoap.org/ws/2004/09/mex
  24:     public static string MetadataExchangeDialect { get; }
  25:     //WS-Policy:http://schemas.xmlsoap.org/ws/2004/09/policy
  26:     public static string PolicyDialect { get; }
  27:     //WSDL:http://schemas.xmlsoap.org/wsdl/
  28:     public static string ServiceDescriptionDialect { get; }
  29:     //XML Schema:http://www.w3.org/2001/XMLSchema
  30:     public static string XmlSchemaDialect { get; } 
  31: }

但看MetadataSection的定义,你可能觉得没有太多值得关注的地方,如果结合WS-MEX规范,既有很多值得玩味的地方了:

首先,在类型上应用了一个XmlRootAttribute特性,并定义的名称和命名空间分别为:MetadataSection和http://schemas.xmlsoap.org/ws/2004/09/mex。这和WS-MEX 1.1完全吻合。

其次,属性Dialect表述元数据方言,你可以定义任意字符串作为其属性值。在WS-MEX定义了五种预定义元数据方言:MEX、XML Schema、WSDL、WS-Policy和WS-Policy Attachment。除了WS-Policy Attachement,MetadataSection为前面四种定义了静态只读属性,以便方面编程使用。

然后,属性Identifier表示元数据的标识符,这是一个以URI形式表示的字符串,由于受篇幅所限,在上面对WS-MEX的介绍中并没有提及,有兴趣的读者可以参考WS-MEX官方文档的第4部分。Identifier和Dialect最终被序列化后生成<MetadataSection>元素相应的属性(Attribute)。此外,MetadataSection还定义了类型为Collection<XmlAttribute>的Attributes属性,你可以自定义任意的XML属性,最终将会作为<MetadataSection>元素的属性。

而元数据的内容通过包含在属性Metadata中,当整个MetadataSection被序列化后,该属性的值将会被序列化成一个XML元素,其元素的名称和命名空间根据具体的类型决定。从应用在该属性上的一系列XmlElementAttribute特性我们可以看出:MetadataSection为以下几种特殊的类型定义了相应的名称和命名空间:

MetadataLocation

MetadataLocation表示以RUI形式表示的元数据文档的地址,WS-MEX 1.1规定了可以采用元数据文档地址的URI来替代相应元数据的内容。MetadataLocation定义在System.ServiceModel.Description命名空间下,定义如下:

   1: [XmlRoot(ElementName="Location", Namespace="http://schemas.xmlsoap.org/ws/2004/09/mex")]
   2: public class MetadataLocation
   3: {
   4:     public MetadataLocation();
   5:     public MetadataLocation(string location);
   6:  
   7:     [XmlText]
   8:     public string Location { get; set; }
   9: }

MetadataReference

按照WS-Addressing 2004或者WS-Addressing 1.0规范,如果元数据成为一种可被寻址的资源(Addressable Resource),那么可以通过终结点引用(Endpoint Reference)的方式来定位该资源。WS-MEX 1.1规定了可以采用元数据终结点引用来替代相应元数据的内容。元数据终结点引用可以通过MetadataReference来表示,MetadataReference定义于System.ServiceModel.Description命名空间下,定义如下:

   1: [XmlRoot(ElementName = "MetadataReference", Namespace = "http://schemas.xmlsoap.org/ws/2004/09/mex")]
   2: public class MetadataReference : IXmlSerializable
   3: {
   4:    
   5:     public MetadataReference();
   6:     public MetadataReference(EndpointAddress address, AddressingVersion addressVersion);  
   7:     public EndpointAddress Address { get; set; }
   8:     public AddressingVersion AddressVersion { get; set; }
   9: }

MetadataSet

MetadataSet就是我们即将要介绍的用于表示MetadataSection集合,将MetadataSet作为MetadataSection的元数据,意味元数据可以以一种嵌套的形式来表示。

XmlSchema

如果元数据的类型为XmlSchema,即表示以XML Schema方言(Dialect)表示的元数据。

ServiceDescription

关于这里的ServiceDescription,读者千万要注意:这里指的是System.Web.Services.Description.ServiceDescription,而不是System.ServiceModel.Description.ServiceDescription。后者是我们熟悉的对WCF服务的描述(对此不熟悉的读者,可以参考《WCF技术剖析(卷1)》的第7章),前者实际上是对一个WSDL文档的描述。由于WSDL的结构相对复杂,ServiceDescription的定义也不太简单,篇幅所限,本书不会对此作详细的介绍,有兴趣的读者可以参考MSDN类库。如果元数据的类型为ServiceDescription,即表示以WSDL方言(Dialect)表示的元数据。

最后,MetadataSection还定义了如下三个静态方法帮助你快速创建基于WS-Policy策略、XML Schema和WSDL元数据方言的MetadataSection对象:

   1: [XmlRoot(ElementName="MetadataSection", Namespace="http://schemas.xmlsoap.org/ws/2004/09/mex")]
   2: public class MetadataSection
   3: {
   4:    //其他成员
   5:     public static MetadataSection CreateFromPolicy(XmlElement policy, string identifier);
   6:     public static MetadataSection CreateFromSchema(XmlSchema schema);
   7:     public static MetadataSection CreateFromServiceDescription(ServiceDescription serviceDescription);
   8: }

二、 MetdataSet

MetadataSet是WS-MEX 1.1中置于SOAP消息主体部分整个元数据的描述,即对置于SOAP主体部分的<Metadata>所有内容的体现。既然<Metadata>结点是一组<MetadataSection>元素的集合,MetadataSet相应地也就是一组MetadataSection对象的集合,这可以从MetadataSet的定义看出来:

   1: [XmlRoot("Metadata", Namespace="http://schemas.xmlsoap.org/ws/2004/09/mex")]
   2: public class MetadataSet : IXmlSerializable
   3: {
   4:     //其他成员
   5:     public MetadataSet();
   6:     public MetadataSet(IEnumerable<MetadataSection> sections);
   7:  
   8:     [XmlAnyAttribute]
   9:     public Collection<XmlAttribute> Attributes { get; }
  10:     [XmlElement("MetadataSection", Namespace="http://schemas.xmlsoap.org/ws/2004/09/mex")]
  11: public Collection<MetadataSection> MetadataSections { get; }
  12:  
  13:     XmlSchema IXmlSerializable.GetSchema();
  14:     void IXmlSerializable.ReadXml(XmlReader reader);
  15:     void IXmlSerializable.WriteXml(XmlWriter writer);
  16: }

三、WCF元数据架构模型

WCF通过终结点的形式将某个服务暴露出来,而元数据的目的在于帮助服务的消费者如何有效地与该终结点进行交互,以实现对该服务的正常调用。元数据帮助像SvcUtil.exe这样的代码生成工具能够有效地生成客户端代码和配置。WCF在内部构建了一个完善的元数据架构体系,很好地实现了元数据的导出、发布、获取和导入,这个框架体系对元数据的处理大体如图1所示。

image 图1 WCF元数据架构体系

图1可以看出,整个元数据框架体系大体分成服务端体系和客户端体系,服务端复杂元数据的导出和发布,客户端实现元数据的获取与导入。元数据的导出、发布、获取和导入这4个基本操作在整个框架体系中的分别实现以下的功能:

在后续的文章中,的我们将针对上述的四个元数据基本操作,对WCF的元数据框架的实现原理进行深入地剖析。

作者: Artech
出处: http://artech.cnblogs.com
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。
目录
相关文章
|
15天前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
8天前
|
监控 安全 API
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
本文详细介绍了PaliGemma2模型的微调流程及其在目标检测任务中的应用。PaliGemma2通过整合SigLIP-So400m视觉编码器与Gemma 2系列语言模型,实现了多模态数据的高效处理。文章涵盖了开发环境构建、数据集预处理、模型初始化与配置、数据加载系统实现、模型微调、推理与评估系统以及性能分析与优化策略等内容。特别强调了计算资源优化、训练过程监控和自动化优化流程的重要性,为机器学习工程师和研究人员提供了系统化的技术方案。
128 77
使用PaliGemma2构建多模态目标检测系统:从架构设计到性能优化的技术实践指南
|
14天前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####
|
21天前
|
Cloud Native 持续交付 云计算
云原生技术在现代IT架构中的转型力量####
本文深入剖析了云原生技术的精髓,探讨其在现代IT架构转型中的关键作用与实践路径。通过具体案例分析,展示了云原生如何赋能企业实现更高效的资源利用、更快的迭代速度以及更强的系统稳定性,为读者提供了一套可借鉴的实施框架与策略。 ####
23 0
|
15天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
25天前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
40 3
|
1月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
15天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
128 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
17天前
|
设计模式 负载均衡 监控
探索微服务架构下的API网关设计
在微服务的大潮中,API网关如同一座桥梁,连接着服务的提供者与消费者。本文将深入探讨API网关的核心功能、设计原则及实现策略,旨在为读者揭示如何构建一个高效、可靠的API网关。通过分析API网关在微服务架构中的作用和挑战,我们将了解到,一个优秀的API网关不仅要处理服务路由、负载均衡、认证授权等基础问题,还需考虑如何提升系统的可扩展性、安全性和可维护性。文章最后将提供实用的代码示例,帮助读者更好地理解和应用API网关的设计概念。
45 8
|
1月前
|
Dubbo Java 应用服务中间件
服务架构的演进:从单体到微服务的探索之旅
随着企业业务的不断拓展和复杂度的提升,对软件系统架构的要求也日益严苛。传统的架构模式在应对现代业务场景时逐渐暴露出诸多局限性,于是服务架构开启了持续演变之路。从单体架构的简易便捷,到分布式架构的模块化解耦,再到微服务架构的精细化管理,企业对技术的选择变得至关重要,尤其是 Spring Cloud 和 Dubbo 等微服务技术的对比和应用,直接影响着项目的成败。 本篇文章会从服务架构的演进开始分析,探索从单体项目到微服务项目的演变过程。然后也会对目前常见的微服务技术进行对比,找到目前市面上所常用的技术给大家进行讲解。
50 1
服务架构的演进:从单体到微服务的探索之旅
下一篇
DataWorks