使用派生类型完成WCF服务生成的模式问题 [英] Problem with schemas generated from consumming WCF service with derived types

查看:48
本文介绍了使用派生类型完成WCF服务生成的模式问题的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

嘿伙计们,我是b $ b $
我在从WCF网络服务生成使用Consume WCF服务向导的模式后偶然发现了一个奇怪的情况。



在服务中,我有几个基本操作。让我们说"RetrieveRequest","CreateRequest","DeleteRequest"等。我有为这些基本操作生成的第一个模式。 

Hey guys,

I stumbled upon a weird scenario after I generated schemas with Consume WCF Service wizard from a WCF web service.

In the service, I have several base operations. Let's say "RetrieveRequest", "CreateRequest", "DeleteRequest", etc. I have a first schema that was generated for those base operations. 

模式看起来像那样(对不起,伙计们,由于我的帐户尚未经过验证,我无法发布图片,但我尝试尽可能地翻译模式):

The schema looks like that (Sorry guys, I can't post pictures since my account is not yet verified, but I tried to translate the schemas the best I could):

<架构>

--- RetrieveRequest

--- CreateRequest

--- DeleteRequest

<Schema>
---RetrieveRequest
---CreateRequest
---DeleteRequest

我还有另一个生成的模式,包含以下内容:

I also have another schema that was generated, containing the following:

< Schema>

---检索

- -----请求

---创建

------请求

---创建

------请求

<Schema>
---Retrieve
------Request
---Create
------Request
---Create
------Request

在此架构中,"请求"是记录实际上是第一个模式中声明的方法的基本数据类型。因此,例如"请求"和"请求"。在"检索"下是基本数据类型"RetrieveRequest"。生成的业务流程中声明的所有
消息部分和端口类型都基于第二个模式。 

In this schema, the "Request" records are in fact of the base data type of the methods declared in the first schema. So for example the "Request" under "Retrieve" is of base data type "RetrieveRequest". All of the message parts and port types declared in the generated orchestration are based on this second schema. 

然后,我有第三个模式,包含基地运作。它看起来像这样:

And then, I have a third schema, containing extensions of the base operations. It looks like this:

<架构>

--- RetrieveSystemRequest

--- RetrieveUserRequest

--- CreateSystemRequest

--- CreateUserRequest

--- DeleteSystemRequest

--- DeleteUserRequest

<Schema>
---RetrieveSystemRequest
---RetrieveUserRequest
---CreateSystemRequest
---CreateUserRequest
---DeleteSystemRequest
---DeleteUserRequest

这些操作的基本数据类型是在第一个模式上定义的。因此,对于"RetrieveSystemRequest"来说,基本数据类型是"RetrieveRequest",并且它的属性是"Derived By"。被设置为"Extention"。这个
操作包含的参数多于它派生的基本类型。 

The base data type of those operations are defined on the first schema. So let's say for "RetrieveSystemRequest", the Base Data Type is "RetrieveRequest", and it's property "Derived By" is set to "Extention". This operation contains more parameters than the base type it's derived from. 

我必须创建一条消息,以便为操作"RetrieveSystemRequest"发送给服务。该消息的消息部分如下所示:

I have to create a message to send to the service for the operation "RetrieveSystemRequest". The message part for that message looks like that:

< Schema>

--- RetrieveSystemRequest

----- -UserId

---------姓名

------ SystemId

<Schema>
---RetrieveSystemRequest
------UserId
---------Name
------SystemId

我的问题是,与RetrieveRequest操作的端口类型相关联的消息部件类型如下所示:

My problem is, the message part type that is tied to the port type for the RetrieveRequest operation looks like that:

< Schema>

---检索

------ RetrieveRequest

--------- UserId

------------姓名

<Schema>
---Retrieve
------RetrieveRequest
---------UserId
------------Name

我没有参数"SystemId"因为它来自基础"RetrieveRequest"的派生版本,而端口类型直接与基础版本绑定。

I don't have the parameter "SystemId" because it's coming from a derived version of the base "RetrieveRequest", while the port type is tied directly from the base version.

任何想法?我错过了一些我可以更改的模式的属性?

Any ideas? Something I am missing the the properties of the schemas that I can change?

目前我很想创建自定义端口类型,而不是基本操作而是扩展操作。我不喜欢这个解决方案的是,我目前不会有像我这样的6个操作,但更像是我的
端口类型中的30个操作。 

For the moment I'm tempted to create custom port types linked not to the base operations but to the extended operations. What I don't like about that solution is that I won't have 6 operations like I have for the moment, but more like 30 operations in my port type. 

感谢您的帮助。 

Thanks for your help. 

Patrick。 

Patrick. 

推荐答案

Patrick,

Patrick,

看起来您正在尝试从业务流程或物理端口访问Web服务。这是准确的吗?

Looks like you are trying to access a web service from an orchestration or a physical port. Is that accurate?

如果是这样,请使用您的"第一个架构"。忽略其上与您尝试执行的操作无关的所有字段。这应该工作。

If so, use your "first schema". Ignore all the fields on it that are not pertinent to the operation you are trying to execute. That should work.

如果您已尝试过并且未执行,会发生什么?你能给我们一些更多信息吗?如果您需要示例我会告诉我,我会一起鞭打。

If you have tried that and it didn't execute, what happened? Can you give us some more information? Let me know if you need examples and I'll whip something together.


这篇关于使用派生类型完成WCF服务生成的模式问题的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆