{"id":251,"date":"2004-01-07T20:25:00","date_gmt":"2004-01-08T00:25:00","guid":{"rendered":"http:\/\/www.markbaker.ca\/wp\/?p=260"},"modified":"2004-01-07T20:25:00","modified_gmt":"2004-01-08T00:25:00","slug":"ws-eventing","status":"publish","type":"post","link":"http:\/\/www.markbaker.ca\/blog\/2004\/01\/ws-eventing\/","title":{"rendered":"WS-Eventing"},"content":{"rendered":"<p><a href=\"http:\/\/msdn.microsoft.com\/ws\/2004\/01\/ws-eventing\">WS-Eventing<\/a>,\nfrom BEA, MS, and Tibco.<\/p>\n\n<p>The good news is that <em>finally<\/em>, we&#8217;ve got a Web services spec that\ntackles the hard problem, interfaces.  Yes, WS-Eventing is an application protocol\n(do we have to bind SOAP to it too?)<\/p>\n\n<p>The bad news is that it continues the track record of abusing other application protocols\n(if indeed it&#8217;s objective is to be used with them, which I can only assume is the case); the\nmore that goes in the SOAP envelope, the less suitable it is for use with them,\nas it just duplicates what they already provide.  Once again we see\n<a href=\"http:\/\/www-106.ibm.com\/developerworks\/webservices\/library\/ws-add\/\">WS-Addressing<\/a>\nas the culprit; wsa:Action and wsa:To exist to replace their counterparts in\nany underlying application protocol.  For example, for HTTP, the counterparts of\nwsa:Action and wsa:To are the\n<a href=\"http:\/\/www.zvon.org\/tmRFC\/RFC2616\/Output\/chapter5.html#sub1\">request method and request URI<\/a>,\nrespectively.<\/p>\n\n<p>A point of frustration for me is that the semantics\nof subscription itself are largely <em>uniform<\/em>.  What I mean is,\nwouldn&#8217;t it be great if <em>all<\/em> Web services supported &#8220;subscribe&#8221;?\nSo why not use HTTP\n<a href=\"http:\/\/www.markbaker.ca\/2002\/09\/Blog\/\/2003\/12\/22#2003-12-dave-o\">like I&#8217;ve done<\/a>,\nwhich is built for uniform semantics?  Using a SOAP envelope with MONITOR and\nfor the resultant notifications would be really sweet.<\/p>\n\n<p>One pleasant surprise is the form that notifications take, as in\n<a href=\"http:\/\/msdn.microsoft.com\/webservices\/understanding\/specs\/default.aspx?pull=\/library\/en-us\/dnglobspec\/html\/ws-eventing.asp#ws-eventing__ref47172354\">this example<\/a>.  Notice\nthe use of wsa:Action; the value is no longer a method, but is instead a\ntype.  Woot!  That&#8217;s the first time I&#8217;ve seen the &#8220;action&#8221; semantic\n<a href=\"http:\/\/www.oreillynet.com\/pub\/wlg\/2331\">used properly<\/a>\nin any Web services work.  Presumably this is due to notification\nsemantics being entirely geared towards simply getting some data to\nsome other application; basically, POST.  Of course,\ntechnically, I don&#8217;t believe any &#8220;action&#8221; is required in this case,\nas there&#8217;s no intent on behalf of the notification sender beyond\nsimple data submission; the intent is determined and assigned by the\nrecipient of the notification.  But that&#8217;s still progress!<\/p>\n\n<p>Another upside is the use of fine grained URIs for identifying the\nendpoints, e.g. &#8220;http:\/\/www.other.example.com\/OnStormWarning&#8221;, rather\nthan something like &#8220;http:\/\/www.other.example.com\/RPCrouter&#8221;.<\/p>\n\n<p>Overall, very disappointing from a protocol and pub\/sub POV, but the\nprogress on resource identification, uniform semantics (even if it&#8217;s\naccidental 8-), and intent declaration is quite encouraging.\nPerhaps the next attempt will be done as an HTTP extension with a\nSOAP binding to MONITOR (the existing binding to POST would suffice\nfor notifications).<\/p>","protected":false},"excerpt":{"rendered":"WS-Eventing, from BEA, MS, and Tibco. The good news is that finally, we&#8217;ve got a Web services spec that tackles the hard problem, interfaces. Yes, WS-Eventing is an application protocol (do we have to bind SOAP to it too?) The bad news is that it continues the track record of abusing other application protocols (if [&hellip;]","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[26],"class_list":["post-251","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-soap"],"_links":{"self":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/251","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/comments?post=251"}],"version-history":[{"count":0,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/posts\/251\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/media?parent=251"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/categories?post=251"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.markbaker.ca\/blog\/wp-json\/wp\/v2\/tags?post=251"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}