The Galactic Patrol : Web Services

Interested in Indigo?

bwill — Wed, 23 Mar 2005 02:42:00 GMT

I've been posting some comments about Indigo on my other blog - feel free to subscribe if you're interested in Indigo. Here are some of the Indigo entries I've written:

http://galactic-patrol.blogspot.com/2005/02/indigo-is-re-released-into-wild.html

http://galactic-patrol.blogspot.com/2005/02/to-indigo-clr-contract-is-not.html

http://galactic-patrol.blogspot.com/2005/02/serviceoperation-wheres-message.html

http://galactic-patrol.blogspot.com/2005/03/indigo-testing-take-pretty-things-and.html

http://galactic-patrol.blogspot.com/2005/03/got-indigo-questions.html

http://galactic-patrol.blogspot.com/2005/03/whats-right-way-to-dispose-channel.html

Fair warning, I do occasionally blog about non-technical topics.

WS-Eventing and WS-Addressing

bwill — Fri, 23 Apr 2004 23:45:00 GMT

Hank Wallace posted a question recently about the <NotifyTo> element in a WS-Eventing subscription request, and whether it really needed to contain an <Address> element or not. You can read my response in the comments, but while I was looking over the specs I realized that the presentation of this containment is a bit confusing.

In WS-Eventing, the <NotifyTo> element is defined as follows:

<NotifyTo>endpoint-reference</NotifyTo>

In WS-Addressing, an endpoint-reference is defined as follows:

<Address>xs:anyURI</Address>

</EndpointReference>

(Note that I’ve left out namespaces and optional elements for clarity.)

Gosh, this looks like you not only need the <Address> element, but also this <EndpointReference> guy! Maybe something like this?

<Address>http://MyServer/MyService</Address>

</EndpointReference>

</NotifyTo>

Wrong! Bad Bruce! You see, a closer reading of the WS-Addressing spec reveals this interesting tidbit:

“/wsa:EndpointReference

This represents some element of type wsa:EndpointReferenceType. This example uses the predefined <wsa:EndpointReference> element, but any element of type wsa:EndpointReferenceType may be used.”

And another look at the WS-Eventing spec reveals more:

“/s:Envelope/s:Body/*/wse:NotifyTo

Where to send notification messages. MUST be of type wsa:EndpointReferenceType.”

So it turns out that the <NotifyTo> element is in fact an instance of the EndpointReferenceType; <NotifyTo> and <EndPointReference> are the same. For the more colorfully-minded:

<NotifyTo>endpoint-reference</NotifyTo>

<Address>xs:anyURI</Address>

</EndpointReference>

Red elements are the same as red elements, blue are the same as blue. So the correct merging of the WS-Eventing and WS-Addressing specs is as follows:

<Address>http://MyServer/MyService</Address>

</NotifyTo>

What is an 'anonymous' sender?

bwill — Mon, 15 Mar 2004 10:01:00 GMT

A bit of terminology discussion here…

In a recent article, Yasser introduced this following use of the word ‘anonymous’:

“An application comes to life on the network by using an Indigo port, which acts as the gateway between the application and the network. Each port is identified by a unique URI known as the port's identity role. If the application doesn't need its port to be addressed by other applications on the network (e.g., the port is used only to send messages but never to receive messages), such a port may not have an identity role, in which case it is said to be anonymous.”

In some recent discussions on the Indigo team, this caused some confusion, because to many of us, when you say something is sent anonymously, that has a specific meaning as far as security identity. That is, we expected it to be similar to the Windows ‘Guest’ identity or ‘Everyone’ group; the security identity of last resort. As you can see above, though, this is another use of the term ‘anonymous’ that has not very much to do with security identity – instead it says that the sender is not addressable. That is, even though you received something from them, you can’t send anything back; they don’t have an address to send to. (That is, unless you happen to be lucky enough to have an HTTP response, or something similar, on which to piggy-back your information.)

What do you folks think? Is ‘anonymous’ the right term to use here, or is there something better?

Rich Turner's Indigo Blog

bwill — Mon, 08 Mar 2004 13:07:00 GMT

I’ve noticed that Rich Turner has been posting some excellent Indigo posts recently on his blog – go check it out!

Errata for WS-Eventing posts

bwill — Wed, 18 Feb 2004 00:40:00 GMT

A co-worker of mine kindly pointed out an error in my WS-Eventing messages; the <NotifyTo> element contains an <Address> element, not a text string. I’ve corrected the previous posts. My apologies for any confusion.

WS-Eventing Part III: The Notification Message

bwill — Tue, 17 Feb 2004 13:10:00 GMT

Ok, now pay close attention; this part gets real complicated. The required elements of a notification message (that is, the shark-attack message sent to the subscriber) are as follows:

…

That’s right, there are no required elements. Any SOAP message can be a valid notification. The event source and the event sink (aka the subscriber) must agree on the notification format, and the WS-Eventing spec doesn’t mandate how that agreement is achieved. A couple options occur to me off the top of my head. Documentation can specify the format, and both sides can simply use the same documented format for the message. Alternatively, the format could be published via WSDL at the event source, which the subscriber could use to process the notification message or generate a proxy for it. (Or would that be a stub?)

If the subscriber really needs to know which subscription a particular notification is associated with, that subscriber can attach a tag to the subscription request. That tag will then be included in all notification messages the event source sends to that subscriber. The tag looks like this:

<Action>http://schemas.xmlsoap.org/ws/2004/01/eventing/Subscribe</Action>

<MessageID>http://www.me.com/subscriptions/583</MessageID>

<ReplyTo>http://www.me.com/subscription-response-handler</ReplyTo>

<To>http://www.ocean.com/notifications/shark-attacks</To>

</Header>

<Body>

<Address>http://www.me.com/shark-attack-notification-handler</Address>

<MyCustomHeader>This is from my shark-attack subscription!</MyCustomHeader>

</ReferenceProperties>

</NotifyTo>

</Subscribe>

</Body>

</Envelope>

This will force the event source to add that tag as a header to every notification that it sends to that subscriber, like so:

<To> http://www.me.com/shark-attack-notification-handler</To>

<MyCustomHeader>This is from my shark-attack subscription!</MyCustomHeader>

</Header>

<Body>

<Location>Daytona Beach</Location>

</Subscribe>

</Body>

</Envelope>

WS-Eventing Part II: The Subscription Response

bwill — Fri, 13 Feb 2004 07:46:00 GMT

Before I talk about the optional elements on a WS-Eventing subscription, I’d like to quickly cover the response message you get back when your subscription request is accepted.

Taking a Header

Most of the stuff in the response message header is just bits of information from your request header, regurgitated back to you; your <ReplyTo> address from the request becomes the <To> address on the response, for example. Our example subscription request is shown below, as is the associated subscription response. I’ve color-coded it to show which bits get copied from one place to the other. I offer my apologies in advance for the lack of subtlety in color choices.

There is also the bit of fluff that says “yes, this really is a subscription response” – I’ve highlighted that in yellow below.

Subscription Request

<Action>http://schemas.xmlsoap.org/ws/2004/01/eventing/Subscribe</Action>

<MessageID>http://www.me.com/subscriptions/583</MessageID>

<ReplyTo>http://www.me.com/subscription-response-handler</ReplyTo>

<To>http://www.ocean.com/notifications/shark-attacks</To>

</Header>

<Body>

<Address>http://www.me.com/shark-attack-notification-handler</Address>

</NotifyTo>

</Subscribe>

</Body>

</Envelope>

Subscription Response

<Action>http://schemas.xmlsoap.org/ws/2004/01/eventing/SubscribeResponse</Action>

<RelatesTo>http://www.me.com/subscriptions/583</RelatesTo>

<To>http://www.me.com/subscription-response-handler</To>

</Header>

<Body>

</SubscribeResponse>

</Body>

</Envelope>

The Meat of the Message

More interesting is the new data that the service returns to you; namely, the <Id> and <Expires> elements. The act of receiving the subscription response tells you that your subscription was accepted; so why do we need these extra elements at all?

It turns out that these elements exist for administrative purposes. The service assigns an ID for your subscription, so that you can uniquely identify that subscription in later messages from you to the notification service – for example, if you want to unsubscribe, or extend your expiration time. The service gives you an expiration time because it doesn’t want to clog itself up with a bunch of stale subscriptions; if you want to keep your subscription alive, you better go renew it every once in a while.

Here is the subscription response message again, with the ID and expiration elements highlighted:

<Action>http://schemas.xmlsoap.org/ws/2004/01/eventing/SubscribeResponse</Action>

<RelatesTo>http://www.me.com/subscriptions/583</RelatesTo>

<To>http://www.me.com/subscription-response-handler</To>

</Header>

<Body>

</SubscribeResponse>

</Body>

</Envelope>

That’s the end of WS-Eventing for Dummies, Part II. I hope you enjoyed reading it as much as I enjoyed writing it. Next time, I’ll talk about some of the optional elements on the subscription request.

WS-Eventing: A Note on Namespaces

bwill — Fri, 13 Feb 2004 07:03:00 GMT

In part I of my discussion of WS-Eventing, I deliberately left the namespaces off the elements of the SOAP message. I did this for clarity, but I feel a little bad about where I say “This is finally valid WS-Eventing” – because its really not completely valid without the namespaces. So to salve my conscience, here is the final valid subscription from that article, with namespaces:

<s:Envelope

xmlns:s12='http://www.w3.org/2003/05/soap-envelope'

xmlns:wsa='http://schemas.xmlsoap.org/ws/2003/03/addressing'

xmlns:wse='http://schemas.xmlsoap.org/ws/2004/01/eventing' >

<s12:Header>

<wsa:Action>http://schemas.xmlsoap.org/ws/2004/01/eventing/Subscribe</wsa:Action>

<wsa:MessageID>http://www.me.com/subscriptions/583</wsa:MessageID>

<wsa:ReplyTo>http://www.me.com/subscription-response-handler</wsa:ReplyTo>

<wsa:To>http://www.ocean.com/notifications/shark-attacks</wsa:To>

</s12:Header>

<s12:Body>

<wse:Subscribe>

<wse:NotifyTo>

<wsa:Address>http://www.me.com/shark-attack-notification-handler<wsa:Address>

</wse:NotifyTo>

</wse:Subscribe>

</s12:Body>

</s12:Envelope>

WS-Eventing for Dummies

bwill — Wed, 11 Feb 2004 05:56:00 GMT

WS-Eventing is a standard that enables interoperable publish/subscribe systems. The spec itself is quite short and sweet – I recommend taking a look at it. As a tester, I’m quite pleased by the simplicity because it makes implementations easier to test (and hopefully more robust). I hope that you, as developers writing to the spec, find it easy to create those implementations.

So let’s see how subscriptions work with WS-Eventing...

The Simplest Subscription

I'm writing a client app, and I want to receive notifications about shark attacks. I know there is a server out there that sends such notifications to anyone who subscribes. Here is a first cut at a subscription message:

<Body>

</Body>

(This is not valid WS-Eventing)

(For legibility I'm stripping out the namespaces; please refer to the spec to get that info.)

What’s It All About?

Ok, that’s not a valid WS-Eventing subscription message; it is missing a few things. First off, there is no mention of shark attacks there; we’ll fix that first:

<To>http://www.ocean.com/notifications/shark-attacks</To>

</Header>

<Body>

</Body>

(This is not valid WS-Eventing)

Who Cares?

Well, that looks pretty sharp; but unfortunately having received our subscription, the service has no idea where to send the shark attack notifications! We need to let it know where to send that all-important shark attack info, and we do it like this:

<To>http://www.ocean.com/notifications/shark-attacks</To>

</Header>

<Body>

<Address>http://www.me.com/shark-attack-notification-handler</Address>

</NotifyTo>

</Subscribe>

</Body>

(This is not valid WS-Eventing)

Did It Work?

Ok, that’s starting to look pretty good. I’ve got a little surprise for you, though – according to the WS-Eventing spec, you get a response message to let you know that your subscription succeeded! Wow, that’s cool – but now we have to let the service know where to send the response message. We’ll use WS-Addressing’s handy-dandy ReplyTo header for that:

<ReplyTo>http://www.me.com/subscription-response-handler</ReplyTo>

<To>http://www.ocean.com/notifications/shark-attacks</To>

</Header>

<Body>

<Address>http://www.me.com/shark-attack-notification-handler</Address>

</NotifyTo>

</Subscribe>

</Body>

(This is not valid WS-Eventing)

Insert Tab A Into Slot B

What else could we possibly need? Well, honestly that’s the most important stuff, but the WS-Eventing spec does require a few more elements. For example, we need to be able to handle multiple subscription requests from the same subscriber. If you sent two copies of the message above (perhaps with shark-attacks and jellyfish-attacks), then you wouldn’t have any way to distinguish the two subscription responses that come back. So let’s add an ID to each message that the service will return to us in the associated response:

<MessageID>http://www.me.com/subscriptions/583</MessageID>

<ReplyTo>http://www.me.com/subscription-response-handler</ReplyTo>

<To>http://www.ocean.com/notifications/shark-attacks</To>

</Header>

<Body>

<Address>http://www.me.com/shark-attack-notification-handler</Address>

</NotifyTo>

</Subscribe>

</Body>

(This is not valid WS-Eventing)

Administrivia

We still don’t have a valid WS-Eventing subscription message, but we are so close! All we need now is a little bit of header fluff that says “yes, this really is a WS-Eventing subscription.” And here we go…

<Action>http://schemas.xmlsoap.org/ws/2004/01/eventing/Subscribe</Action>

<MessageID>http://www.me.com/subscriptions/583</MessageID>

<ReplyTo>http://www.me.com/subscription-response-handler</ReplyTo>

<To>http://www.ocean.com/notifications/shark-attacks</To>

</Header>

<Body>

<Address>http://www.me.com/shark-attack-notification-handler</Address>

</NotifyTo>

</Subscribe>

</Body>

(This is finally valid WS-Eventing)

And there it is.

There’s More Where That Came From

There are some optional elements in the subscription message that I haven’t discussed; and there are some other messages defined in the WS-Eventing spec. I’ll talk about those in the future. In the meantime, let me know if you found this useful.

WS-Eventing published

bwill — Tue, 27 Jan 2004 11:15:00 GMT

I noticed the WS-Eventing proposed standard has been published – this is directly related to the Indigo feature area I work on.

how to contact me

bwill — Fri, 12 Dec 2003 08:12:00 GMT

I published this info when I started my GotDotNet blog; with the move, now is a good time to re-present the info:

Bruce Williams

I am a test developer for Indigo – current and future Web Services technology at Microsoft.

e-mail: bwill@microsoft.com

IM: domanite@hotmail.com

Breaking [Serializable]

bwill — Tue, 25 Nov 2003 21:37:00 GMT

Doug is asking folks if we should change how [Serializable] works under partial-trust, to be more compatible with our upcoming XML serialization efforts. Follow this link and let him know what you think.