1 2 3 4 5 6 Previous Next 79 Replies Latest reply: Sep 14, 2009 4:33 AM by Tom Fennelly Go to original post RSS
  • 45. Re: Http Gateway - requirements please...
    Kevin Conner Master

     

    "tfennelly" wrote:
    OK, so I implemented a bit of this so as we can have something concrete to discuss. It's not in any way complete and there are things in it that I plan on refactoring (e.g. removing the ability to reference a web.xml/jboss-web.xml, as requested), as well as there being bits which are not yet implemented at all.

    I hope this means that you are keeping the set of changes as small as possible, remember that we are not into creating wonderful new frameworks here. We have two use cases for 4.x and that is it.

    "tfennelly" wrote:
    Also, Kev has an issue with using the mep to decide whether or not a response is sent back from a Http Gateway. Plan on discussing that separately.

    Kev has an issue in basing code on broken assumptions, but this has already been discussed to death. What else do you feel needs to be discussed?

    "tfennelly" wrote:
    The main thing I wanted to look at was the common codebase for EBWS and the new HttpGateway. I have implemented the bones of a "WebModel" concept that gets built up at deploy time and is then used to construct a single war file for the .esb deployment.

    See SVN: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/tfennelly/httpg2/product/rosetta/src/org/jboss/internal/soa/esb/listeners/war

    So the basic idea is simple... the Deployer:
    1. Creates an instance of WebDeploymentArchive. (Implemented)
    2. Calls EBWS specific code for it to add it's servlets etc to the model. (Not implemented).
    3. Calls HttpGateway specific code for it to add servlets etc to the model. (Implemented)
    4. Creates and deploys the war sub deployment. (Implemented)

    I hope this is the minimalist approach :)

    "tfennelly" wrote:
    Note that where I say "Implemented"... I'm not saying that part is complete and will not change!!! Really just saying "there's something there" for that part of the equation ;)

    The base context is based .esb name (as requested).

    For the Http Gateway, it's currently prefixing the urlPattern with the associated http provider bus name (and not hardcoded "http", as requested).

    But you are going to change this to what was requested, right?

    "tfennelly" wrote:
    This seem OK so far?

    Please remember that this is supposed to be as small an impact as is possible for the current codebase, we will only have two use cases for 4.x. We need to retain some ability to move fixes between the current platform branches and future ones.

    Kev


  • 46. Re: Http Gateway - requirements please...
    Tom Fennelly Master

    I give up!

  • 47. Re: Http Gateway - requirements please...
    Tom Fennelly Master

    OK... now that I've cooled off a little....

    1. I am trying to keep the changes to a min.
    2. I am trying to follow your design requests.
    3. Maybe we can talk about broken assumptions later.
    4. I will refactor so as to use a hardcoded "http" prefix on the urlPattern as requested.

  • 48. Re: Http Gateway - requirements please...
    Kevin Conner Master

    Sorry Tom, I did not mean to annoy you in any way. I am only asking so that I know that what you are doing is what is currently expected.

    There was a description of the mep, and why it does not apply to the client, earlier on this thread. If there is anything that you, or anyone else, feels is missing from this then please ask so that we can clarify the situation and make sure we are all in agreement.

    Kev

  • 49. Re: Http Gateway - requirements please...
    Tom Fennelly Master

    I have it now that both the http gateway and EBWS endpoints are being deployed in the same war file. All Http Gateway endpoint urls are now prefixed with "http".

    In terms of the changes to existing code... most of this involved removing code.

    I haven't prefixed the EBWS endpoints with "ebws" yet - it's as it was. Do we really want to do this? If we do, then we need to provide backward compatibility support.

    The changes can be viewed on the following workspace: http://anonsvn.jboss.org/repos/labs/labs/jbossesb/workspace/tfennelly/httpg2

    If there are specific changes that you feel are not required, let me know the specific instance(s).

  • 50. Re: Http Gateway - requirements please...
    Kevin Conner Master

     

    "tfennelly" wrote:
    I haven't prefixed the EBWS endpoints with "ebws" yet - it's as it was. Do we really want to do this? If we do, then we need to provide backward compatibility support.

    Yes we want to do this. As for backward compatibility, changing the URL is very minor as there is no functional difference that needs to be worked around. Given the rest of the changes, and their impact, I would be willing just to document this as a change between 4.6/4.7 & SOA 4/5.

    "tfennelly" wrote:
    If there are specific changes that you feel are not required, let me know the specific instance(s).

    If there is anything that is different from what has previously been discussed then can you please let me know?

    Kev

  • 51. Re: Http Gateway - requirements please...
    Tom Fennelly Master

    Ok, thanks.

    So, as far as my understanding goes, there are no differences from a functional point of view (one query aside, which is below). I do have other parts to implement, but the merging of http and ebws is basically done and is done with min impact, as best I could.

    I do want to make sure we're on the same page re what you want the urls for the http gateway endpoints to be. At the moment, I have it as:

    http://{host}/{.esbname}/http/{urlPattern_from_listener_config}
    


    There was also talk of doing something like:
    http://{host}/{.esbname}/http/{service_cat}/{service_name}/{urlPattern_from_listener_config}
    


    It's easy change to the later if that's what you prefer. I wasn't sure.

  • 52. Re: Http Gateway - requirements please...
    Kevin Conner Master

     

    "tfennelly" wrote:
    So, as far as my understanding goes, there are no differences from a functional point of view (one query aside, which is below). I do have other parts to implement, but the merging of http and ebws is basically done and is done with min impact, as best I could.

    Fantastic Tom, thanks.

    "tfennelly" wrote:
    I do want to make sure we're on the same page re what you want the urls for the http gateway endpoints to be. At the moment, I have it as:
    
    http://{host}/{.esbname}/http/{urlPattern_from_listener_config}
    


    There was also talk of doing something like:
    
    http://{host}/{.esbname}/http/{service_cat}/{service_name}/{urlPattern_from_listener_config}
    


    It's easy change to the later if that's what you prefer. I wasn't sure.

    IIRC the suggestion from Dave was to use the {service_cat}/{service_name} as the default value of the urlPattern so the URL would either be
    http://{host}/{.esbname}/http/{service_cat}/{service_name}

    or, if a url pattern was specified
    http://{host}/{.esbname}/http/{urlPattern_from_listener_config}


    There should be something earlier in this thread, let me see if I can find it.

    Kev

  • 53. Re: Http Gateway - requirements please...
    Tom Fennelly Master

    Ok thanks... both those options were mentioned but I missed the urlPattern override bit. That's fine, thanks.

  • 54. Re: Http Gateway - requirements please...
    Tom Fennelly Master

    So just to let people comment on how some of the security aspects might look....

    Specifying the http authentication method for the deployment could look like this:

    <http-provider name="http">
     <http-bus busid="ordermgt" />
    
     <auth method="BASIC" />
    </http-provider>
    


    Where the auth method can be an enum of "BASIC", "CLIENT" and "DIGEST".

    The allowed methods and roles could be defined on a per http-bus basis as follows (extending the last example):

    <http-provider name="http">
     <http-bus busid="sales">
     <methods>
     <!-- Restrict access to the GET, POST and OPTIONS (auto) methods... -->
     <method name="GET" />
     <method name="POST" />
     </methods>
     <roles>
     <!-- Restrict access to authenticated members of the "salesAdmin" role... -->
     <role name="salesAdmin" />
     </roles>
     </http-bus>
    
     <auth method="BASIC" />
    </http-provider>
    


    Where the method name can be an enum of the HTTP method types listed as requirements earlier in this thread, with the OPTIONS method always allowed (I think that was the requirement for OPTIONS). All methods are allowed by default.

    Transport guarantees might also be configured on a per bus basis as follows e.g.

    <http-provider name="http">
     <http-bus busid="sales">
     <transport guarantee="CONFIDENTIAL" />
     </http-bus>
    </http-provider>
    


    Where the guarantee is an enum of CONFIDENTIAL, INTEGRAL or NONE (default).

    Of course all of this is open to change. This is just one set of options/suggestions.

  • 55. Re: Http Gateway - requirements please...
    Tom Fennelly Master

    OK... so I think I eventually got it generating the security bits. Was a bit of pita :)

    It looks slightly different from above, but amounts to the same thing.

    So the http-provider definition (inside the jboss-esb.xml) is now looking like....

    <http-provider name="http">
     <http-bus busid="ordermgt" />
    
     <http-bus busid="sales">
     <allowed-roles>
     <role name="friend" />
     </allowed-roles>
     <protected-methods>
     <method name="GET" />
     </protected-methods>
     </http-bus>
    
     <auth method="BASIC" domain="java:/jaas/AcmeSecProvider" />
    </http-provider>
    


    How the roles and methods are currently working can be summed up as follows...

    Methods Specified | Roles Specified | Login Required
    ----------------------------------------------------------------------------
     No | No | No
     No | Yes | For All Methods
     Yes | Yes | For Specified Methods
     Yes | No | No - Specified Methods blocked to all
    


    I think this is right, yeah?

    Note how the security domain can be configured on the auth element.

  • 56. Re: Http Gateway - requirements please...
    Tom Fennelly Master

    The old "using the mep" for sync/async responses chestnut again... Sorry Kev ;)

    Here was what was said on IM that time...

    (12:18:47) Tom Fennelly: another quick one... the mep issue
    (12:18:55) Tom Fennelly: what was the issue with the?
    (12:19:26) Tom Fennelly: you don't wanna use it to decide whether or not a respnse is sent back?
    (12:19:33) Kevin Conner: The mep of the service has no bearing on the http gateway, it is an impleme
    ntation config
    (12:19:36) Kevin Conner: You can't
    (12:19:57) Kevin Conner: A response can be sent back from a OneWay mep if it chains the request
    (12:20:13) Kevin Conner: Service A (OneWay) -> Service B (RequestResponse)
    (12:20:37) Kevin Conner: It is an implementation detail and not part of the service contract


    I'm not trying to contradict Kev, but given our current model where the gateways are configured on the services, I don't understand why the service mep is not an indicator of whether or not the invoked http-gateway should return the service response as its response (mep=RequestResponse), or should simply return an empty response as its response (mep=OneWay).

    It seems to me like having an additional sync/async config on the gateway would be very confusing for users. I think this is what's being proposed, right?

    So, assuming we add a "sync" flag on the http-gateway, how should the gateway respond when...

    1. gateway sync=true, service mep=OneWay?

    2. gateway sync=true, service mep=RequestResponse?

    3. gateway sync=false, service mep=OneWay?

    4. gateway sync=false, service mep=RequestResponse?

    If the http-gateway used the mep, what use case breaks, and how does it break i.e. what actually goes wrong e.g. with the chained services example outlined in the IM?

  • 57. Re: Http Gateway - requirements please...
    Tom Fennelly Master

    Looks like we also need a way to map pipeline exceptions to http status codes, which makes sense I think.

    This should be straightforward enough. I was thinking we could allow the user to define the exception mappings globally (at the http-provider) and then allow overrides at the listener level.

  • 58. Re: Http Gateway - requirements please...
    Tom Fennelly Master

    I wrote up some wiki docs for this new gateway here: http://www.jboss.org/community/wiki/HTTPGateway

  • 59. Re: Http Gateway - requirements please...
    Jim Tyrrell Newbie

    A few thoughts from this page:
    http://www.jboss.org/community/wiki/HTTPGateway

    What about performance and tuning considerations?

    David W, was working on XSLT in/out of a gateway (it was faster the smooks for him) he was writing around Web Services, should that idea be included in this gateway. Does that even make sense?

    From that link:
    In the "Synchronous/Asynchronous Responses"
    To be worked out!! Currently using the Service MEP to decide whether or not the gateway should wait on the Service response (mep=RequestResponse), or deliver an empty response immediately (mep="OneWay"). Kev has indicated that we can't use the mep, so we need to find out how it should work.
    section.

    Why should we mandate one or the other, why can this not be configurable. Why would we change the "semantics" for this option around mep, although maybe that is not a valid thought either.

    I think both sync and async should be support with this, with hopefully the same kind of configurations as the mep parameter?