Why is messageTypeID int

Mar 20, 2007 at 4:19 PM
When I exlored SystemAdapterSample I realized that type os msgType is int.
(in ProcessMessage(System.Xml.XmlDocument xmlMessage, int msgType, ...)
Who will manage these type IDs? Microsoft? I think that this system should be usuable for sending proprietary message types which are not widely accepted as a standard message type. (I mean messages like request for booking from web ordering form, billing info from book-keeper)
Developer
Mar 20, 2007 at 10:18 PM
In an ideal world a global standard for message type IDs could be possible. In designing this, however, we had a more realistic expectation that the administrators of any eco-system within which HCE is deployed would manage the message types. In that way they could support the message types needed for their own purposes without having an imposed "standard set" that may not be applicable to them.

It's an interesting thought, however, of trying to establish a standard set through this community. I'd be interested to see what others think of this.

Brent
Mar 21, 2007 at 6:37 AM
I expected, that messageType identifier will be URL address which will point to schema, description, etc...

BrentSutherland wrote:
In an ideal world a global standard for message type IDs could be possible. In designing this, however, we had a more realistic expectation that the administrators of any eco-system within which HCE is deployed would manage the message types. In that way they could support the message types needed for their own purposes without having an imposed "standard set" that may not be applicable to them.

It's an interesting thought, however, of trying to establish a standard set through this community. I'd be interested to see what others think of this.

Brent

Developer
Mar 21, 2007 at 10:52 PM
Edited Mar 21, 2007 at 10:53 PM

headman wrote:
I expected, that messageType identifier will be URL address which will point to schema, description, etc...


Hi headman,

It actually works in a similar way. The MessageTypeID point to some metadata stored within Service Provider Register. This allows the Adapters to query for the most up-to-date list of message types that they are supposed to handle during its own initialization, including the most up-to-date location of the schemas - although the schemas definition shouldn't change the location of those schemas, used to validate the messages at run time, can change.

Once the Adapter receives an message to process, it will match the message type with the metadata stored within its own cache. This encapsulates all the information about message type metadata within the adapter. The idea is that the Service Provider actually sends the message in its own proprietary format and the adapter does the translation between that format and the "standard type" defined within that ecosystem (based on the message type).

Does this make sense?

Cheers, Wagner.
Mar 25, 2007 at 4:35 PM

It actually works in a similar way. The MessageTypeID point to some metadata stored within Service Provider Register.

Thank you for your explanation. Yes, it makes sense. Could you tell me which functions are inteneded for querying message type metadata from Service Provider Register metadata store?


The idea is that the Service Provider actually sends the message in its own proprietary format and the adapter does the translation between that format and the "standard type" defined within that ecosystem (based on the message type).

I think that in future majority of messages will be digitaly signed by authors of that data - doctors the signature will be made in Adaptor. Transformation of this digitaly signed document is imposible later in Service Provider Register and Adapter must be forced to send data in format which is acceptable for the receiver. Does it make sense?
Cheers, Petr
Developer
Mar 27, 2007 at 12:09 AM
Hey Petr,


Thank you for your explanation. Yes, it makes sense. Could you tell me which functions are inteneded for querying message type metadata from Service Provider Register metadata store?
...
I think that in future majority of messages will be digitaly signed by authors of that data - doctors the signature will be made in Adaptor. Transformation of this digitaly signed document is imposible later in Service Provider Register and Adapter must be forced to send data in format which is acceptable for the receiver. Does it make sense?


During initialisation, an Adapter execute a calls GetAllowedProviders and GetReferenceData functions. Behind the scenes, those two calls works just like any other message exchange, but those are sent to Service Provider Register. The first call retrieves a list of all providers your provider can communicate - this gives you the ability to find out each providers ID, friendly name, encryption type and public key. The second message get a list of all the messages you can either send or receive, including the most up-to-date schema location, so you can validate the messages sent and received.

One of the ideas is that all or part of this metadata can potentially be exposed to your end system - it doesn't need to be done, but is a possible scenario. This would allow your application to use this metadata to implement extra functionality that improves integration with an HCE enabled ecosystem(e.g using the Service Provider information to select where the message should go from the application itself).

Finally, when you talk about a scenario where the message will be digitally signed, I can see two possible scenarios:

1) The message being signed is already a standard type of message, otherwise you have to create, sign and transmit a diferent type of message to each one of your partners. In this case no translation is needed and the message can simply be encrypted, and send to the destination.

2) For some reason the message is unique for each partner. In this case, for transmission reasons the message should still be put inside some kind of common transmission wrapper, and this wrapper would be your agreed message type. In this scenario, the adapters send the message using the transmission wrapper, and once unwrapped, the receiver would first verify the signed message and consume it from there.

Does this make sense?

Cheers,