{"id":715,"date":"2005-02-18T21:45:00","date_gmt":"2005-02-19T06:45:00","guid":{"rendered":"http:\/\/www.cloudidentity.com\/blog\/2005\/02\/18\/ws-reliablemessaging-2005-whats-new\/"},"modified":"2013-03-16T11:00:11","modified_gmt":"2013-03-16T20:00:11","slug":"376276","status":"publish","type":"post","link":"https:\/\/www.cloudidentity.com\/blog\/2005\/02\/18\/376276\/","title":{"rendered":"WS-ReliableMessaging 2005: what’s new"},"content":{"rendered":"

Scatter list of new or (IMHO) notable features of the 2005 version of WS-ReliableMessaging<\/a>. Overall I’d say that it changed very little, promising symptom of maturity of the specification. <\/p>\n

    \n
  1. Elements at the header level are now called “header block”\n
  2. Example Message Exchange (s2.4): sequence explicit creation (2,3) and termination (11,12) are no longer declared as optional steps\n
  3. Sequence<\/font> (s3) now includes a more pervasive <\/font>\/@any<\/font><\/a> extension mechanism. Extensions must not contradict the semantic of the spec element. If a receiver doen’t understand an extension, it should ignore it.\n
  4. (s3.1) Say goodbye to the Expires<\/font> element\n
  5. (s3.1) There is now the chance to send a message with empty body, a Sequence<\/font> with just a LastMessage<\/font> child and a special Action (http:\/\/schemas.xmlsoap.org\/ws\/2005\/02\/rm\/LastMessage<\/a>) in the case in which you wish to close the sequence but you don’t have any more application data to send.\n
  6. (s3.4) As suspected in the example, explicit outbound sequence creation is now mandatory. An inbound sequence can be “invited” by sending an explicit offer. More below.\n
  7. (s3.4) CreateSequence<\/font> underwent heavy restyling. it has now the following children:\n
      \n
    1.  AcksTo<\/font>: the EP which is supposed to listen to communications like acks and faults\n
    2.  Expires<\/font>: it just moved, after all? No, there’s more. Destination can accept the value or use a shorter one. There’s a special value for “no expiration” (P0S). If you don’t specify an Expires<\/font>, P0S will be the default value.\n
    3.  Offer<\/font>: the source offers the destination a “return queue”, that’s to say an inbound sequence. Offer<\/font> must contain the Identifier<\/font> of the inbound sequence, and may contain Expires<\/font> (same semantic as above)\n
    4.  SecurityTokenReference<\/font>: nice new trick, which may associate a security context to the sequence(s, if Offer<\/font> is present).<\/li>\n<\/ol>\n
    5. (s3.4) SequenceResponse<\/font> carries the Identifier<\/font> of the created sequence, as usual. Now it is explicitly forbidden to use that element as a header block. new children:\n
        \n
      1.  Expires<\/font>: as above.\n
      2.  Accept<\/font>: declares that destination is willing to dance with source and accepts its Offer<\/font>. It contains AcksTo<\/font>, which is the endpoint on the destination which will listen to the acks\/faults from the source about the offered sequence.<\/li>\n<\/ol>\n
      3. (s3.5) If you exceptuate explicit prohibition of travelling as a header block, SequenceTermination<\/font> seems pretty much unchanged\n
      4. (old s4) As stated yesterday<\/a>, all policy moved to another house. Some got lost in the way, like SequenceRef<\/font>.\n
      5. (s4) Faults section now refers explicitly WS-Addressing, and makes full use of its features.\n
      6. (old s6.7) Being Sequence creation now explicit, Sequence Refused got extint.\n
      7. (s5) Security Considerations is pretty much unchanged, which surprises me a little: I would have expected some elaboration of the new SecurityTokenReference<\/font> in CreateSequence<\/font>.<\/li>\n<\/ol>\n

         <\/p>\n

        <\/div>\n","protected":false},"excerpt":{"rendered":"

        Scatter list of new or (IMHO) notable features of the 2005 version of WS-ReliableMessaging. Overall I’d say that it changed very little, promising symptom of maturity of the specification. Elements at the header level are now called “header block” Example Message Exchange (s2.4): sequence explicit creation (2,3) and termination (11,12) are no longer…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"footnotes":""},"categories":[61],"tags":[],"class_list":["post-715","post","type-post","status-publish","format-standard","hentry","category-architecture-ws"],"_links":{"self":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/715","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/comments?post=715"}],"version-history":[{"count":1,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/715\/revisions"}],"predecessor-version":[{"id":1875,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/posts\/715\/revisions\/1875"}],"wp:attachment":[{"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/media?parent=715"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/categories?post=715"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.cloudidentity.com\/blog\/wp-json\/wp\/v2\/tags?post=715"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}