<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/19/15 4:27 AM, Misagh Moayyed
      wrote:<br>
    </div>
    <blockquote
      cite="mid:9ca1a914.00000a2c.0000001f@mmoayyed.unicon.net"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.pl-smi
        {mso-style-name:pl-smi;}
span.pl-k
        {mso-style-name:pl-k;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1"><o:p></o:p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">V3 code:<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Something like this perhaps? <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal"><span
            style="font-size:9.0pt;font-family:"Courier New"">SimpleRequestAdapter
            inTransport = new SimpleRequestAdapter(…);<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:9.0pt;font-family:"Courier New"">MessageContext<SimpleRequestAdapter>
            inCtx = new MessageContext<SimpleRequestAdapter>();<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="font-size:9.0pt;font-family:"Courier New"">inCtx.setMessage(inTransport);</span></p>
      </div>
    </blockquote>
    <br>
    <br>
    No, not really.  The messaging stuff (message decoding, encoding and
    handlers) is the part of v3 that changed the most from v2.  It's
    completely different and bears almost no resemblance to the v2
    design.<br>
    <br>
    In particular, the notion of the various "-Transport-" interfaces is
    completely gone.<br>
    <br>
    If you haven't found your way to this document [1] yet, this is
    probably the best we have at the moment on the design of the new
    messaging API in v3 (although there's no code examples, read on). 
    Some of the terminology, class/interface names changed a little bit
    from that document.<br>
    <br>
    The gist of it is:<br>
    <br>
    - A MessageContext represents a single message, the type of which is
    represented by the generic parametrization of the context.  The
    generic type could be literally anything, but for our own SAML code
    it's usually just a SAMLObject, since that is the "payload" of a
    SAML binding.  For another protocol like OpenID or CAS, etc, it
    would be a similar type which represents the protocol message data
    structure.  For SOAP, it *could* be *either* an Envelope or the type
    of the payload, depending on whether you want to do "message
    oriented" vs "payload oriented" messaging; all the OpenSAML SOAP
    impls do payload, so the context will be paramed as SAMLObject like
    the other non-SOAP bindings.<br>
    <br>
    - The MessageDecoders and MessageEncoders operate directly on the
    type of input they support, e.g. HttpServletRequest and
    HttpServletResponse.  See the interfaces and abstract impls in
    messaging-api and messaging-impl.  Unlike v2, they generally don't
    do anything other than decode/encode the message from/to the
    MessageContext, and possibly populate some binding- or protocol-
    specific subcontexts.<br>
    <br>
    The unit tests for the decoders and encoders are probably the best
    non-IdP examples of this code that you could look at.<br>
    <br>
    - MessageHandlers operate on a single MessageContext and can do
    anything: evaluate security policy (inbound), populate subcontexts
    (inbound/outbound), build or mutate the message (outbound), etc.<br>
    <br>
    - An operation context binds 2 or more MessageContexts together to
    implement a message exchange pattern.  The only current one is the
    InOutOperationContext, which represents and inbound and outbound
    flow (either server-side or client) side. <br>
    <br>
    - As mentioned in the wiki doc, message flows are modeled as a
    logical pipeline.  For a server-side one, it's something like:<br>
    <br>
    <meta http-equiv="content-type" content="text/html;
      charset=windows-1252">
    <tt>Inbound MessageContext decoded -> invoke inbound MessageHandler
      -> "business logic" (aka profile handling) -> invoke
      outboundMessageHandler  -> outbound MessageContext encoded.</tt><br>
    <br>
    That's conceptually what the IdP does, but it's a little convoluted
    at this point, with all the SWF and ProfileAction stuff.<br>
    <br>
    You can actually now see a good example of a client-side flow in the
    new SOAP client [2] that I'm literally just finishing up.  It's on
    trunk only, so not released yet.  The logic in the send(...) method
    of org.opensaml.soap.client.http.AbstractPipelineHttpSOAPClient is
    pretty much the client-side conceptual pipeline model.  <br>
    <br>
    I don't have at the moment any code to illustrate, but a simple
    server-side pipeline impl would look very similar, except based on
    HttpServletMessagePipeline and of course the order of operations
    would be reversed, with inbound decoding first and then outbound
    encoding last.  There would likely be a "business logic" step in
    between those 2, possibly based on a ProfileAction (which assumes a
    ProfileRequestContext subtype).  When I have a few minutes I will do
    up an abstract impl of a server-side pipeline, to serve as an
    example for non-SWF, non-IdP OpenSAML usage.  It would actually be
    simpler than the client-side code in the SOAP client, I think.<br>
    <br>
    <br>
    [1]
<a class="moz-txt-link-freetext" href="https://wiki.shibboleth.net/confluence/display/DEV/MessagingAPIRefactoring">https://wiki.shibboleth.net/confluence/display/DEV/MessagingAPIRefactoring</a><br>
    <br>
    [2]
<a class="moz-txt-link-freetext" href="http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-soap-api/src/main/java/org/opensaml/soap/client/http/AbstractPipelineHttpSOAPClient.java?view=markup">http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-soap-api/src/main/java/org/opensaml/soap/client/http/AbstractPipelineHttpSOAPClient.java?view=markup</a><br>
    <br>
    <br>
  </body>
</html>