I was disappointed to learn Protobuf can't deserialize and map a message to the type it was serialized from: protobuf determining message type to deserialize
For example, when sending messages over a single socket connection we may want to route the message according to its type.
Are there any serialization schemes that can do this?
As it turns out, Protobuf does support this kind of usage in a roundabout kind of way. DazWilkin's answer in the comments about Any pointed me in the right direction.
Any is a Google type you can include in a custom Protobuf message, say WrapperMessage.
message WrapperMessage {
google.protobuf.Any anyMessage = 1;
}
You can pack and unpack other custom Protobuf messages into an Any. When unpacking the Any message, depending on the client Protobuf library, there will be some way to access a string representing the type, usually typeUrl, but some implementations allow access to fullName.
From there you should have what you need to switch on this type string and transform the Any into the specific Protobuf custom message type needed.
Related
I have a consumer with generic argument IEvent. This type is a base interface for all messages, and child interfaces of IEvent have some other properties. I'd like to have access to the raw message with all properties of nested types instead of only IEvent scope. These properties can be seen through RMQ admin dashboard and I think there should be a way to put them out.
You could use context.TryGetMessage<T>() to request the specific type, which essentially attempts to deserialize the message into the specified type (as long as it is in the list of messageTypes serialized into the header).
Otherwise, you can use context.TryGetMessage<JToken>(), and get the JToken from JSON.NET, which can be used to navigate the message body.
Honestly, this isn't the best approach to properly handling events, etc., so I'd refer to the documentation to see how to properly consume the various message types (and let MassTransit do the hard work).
In the context of a WCF project, I need to handle in the same way xml and non-xml messages (eg. Standard SOAP, WS-Attachments, etc..). The normal flow of WCF creates a Message object which can handle an Xml message, this is done by the encoder, so if one wants to handle different messages, it's needed to implement different kind of message-handling...
My needs is to create a message derivation class, which represent the concept of "received message" but not "handled" in the form of special data handling, but , about real data-handling, deferred in a secondary step.
so in the catch-all service I will get a Message messageObject as parameter, so the signature of the service will be Message Accept(Message messageObject)
Any idea?
thanks in advance
There is only single base Message type in WCF. This is a core type which is used by WCF infrastructure. The type is abstract so generally you can create your custom implementation but in such case you will probably have to replace some WCF channels to correctly use your new type.
If you need to transport message in custom format you are probably not looking for replacing Message type but either replacing encoder, serializer or both.
Is there a chance to get a data contract serializer used by operation (DataContractSerializer/NetDataContractSerializer/XmlSerializer etc) in runtime (for instance using operation behaviour). What I want to achieve is to create some diagnostic code that would serialize messages (in message inspector) using currently attached serializer to compare results.
Thanks, Pawel
Take a look at creating a message inspector on the service side. From there you can grab the message and check its encoder. The encoder will tell you how its serializing. This is not working code, but it would go something like this:IDispatchMessageInspector.AfterReceiveRequest( ref Message request....){ if ( request.MessageEncoder is typeof(BinaryMessageEncoder) //do stuff.....}
I'm looking to use the MsmqIntegrationBinding to integrate with a legacy queue which has a serialized object as the message body. Has anyone come up with a way to obtain the "metadata" of the message body and create a service side class to use within the service?
For example, if I put in a serialized Product object from System A and my service needs to consume it, how do I provide MsmqMessage the type if I do not have the Product class on my side? I was thinking of reading off a message in a separate program, deserializing, and then emitting via the code dom. Ideas?
I wholeheartedly recommend against attempting to emit the deserialized type at runtime in the message destination. Either work with the XML at the destination to obtain the data you desire, or build data contracts that both the source and destination can adhere to.
Hmm... in WCF, you can define service methods which take (and optionally return) an untyped Message type. This seems to fit your bill quite nicely.
Other than with strongly typed messages, you'll have to do all the putting together of the message on the client and the taking apart on the server by means of reading the raw XML - but that seems to be what you're looking for, right?
Find more information and samples here:
WCF - Handling Generic Messages
How to pass a generic object through WCF
Untyped messages on WCF
Untyped messages have some restrictions, e.g. you can only read them once on the server, but you should be able to manage your scenario with this, I think.
Marc
I need to retrieve binary (non-XML) documents as Messages in a custom WCF LOB Adapter (for consumption by BizTalk). The messages need to be represented as instances of System.ServiceModel.Channel.Message.
I can't find how to create an instance of this class when the content is binary (by "binary" I mean any arbitrary byte array or Stream, and not only binary representations of XML documents).
Is this possible? Or would wraping the binary contents in an XML enveloppe be the only way to do this in WCF?
Fundamentally, WCF messages are XML, since the S.S.C.Message class uses the Xml InfoSet as the base message representation.
So yes, in some way you need to "wrap" your binary content into an XML envelope (which doesn't need to be a SOAP envelope, mind you, depending on how your binding is configured).
That said, note that this doesn't preclude streaming to deal with large message payloads without buffering the entire message in memory; WCF still allows you to do this, though sometimes it's not greatly obvious how it works.
Since you're working with a custom channel, you've got one of two choices, I think:
Have your own channel add the XML wrapper around your binary content before passing it upwards or
Create a custom MessageEncoder that adds it in for you automatically.
In either case, if you're dealing with large messages, you'll want to make sure you use the MessageEncoder overloads that handle Streams instead of buffers, as they are the ones that give you the option of doing coordinated streaming with the service implementation.
WCF offers some ways to send binary attachments and stream data in various ways. We have an application at work that does this, but I haven't had a chance to dig through the code, so I can't offer too much help. Here are a few links that might get you started (Nicholas Allen's Indigo Blog is a great place for WCF info):
http://blogs.msdn.com/drnick/archive/2006/03/31/565558.aspx
http://weblogs.asp.net/cibrax/archive/2007/08/29/sending-attachments-with-wcf.aspx