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

     

    "Kevin.Conner@jboss.com" wrote:
    "tfennelly" wrote:
    Exactly the same as EBWS again, or should we try and create a new mechanism that abstracts this type of thing (creating sub deployments) away from the deployer and then use this as an opportunity to start evolving the EBWS specific code out of the deployer (where I would think it doesn't belong)?


    EBWS and the http gateway are essentially the same animal and should be shared. There are very few differences between the two, especially once we extend EBWS to support what will be available to HTTP.


    I agree that merging them is ideally what we want, but given the current arch where the listeners are tied in with the services etc, merging what are essentially 2 separate listeners together (as alike and all as they are) without them both being based on a common "framework" would only seem possible (to me) via a hack.

    "Kevin.Conner@jboss.com" wrote:
    We should definitely take this code out of the deployer but going to the extent of a fully extensible framework is not required. We only need to support HTTP and EBWS.


    I'm not really suggesting a "fully extensible" framework... more like a "common" framework/codebase that the Http Gateway and EBWS would build off. If it turns out that the Webservice Proxy could also use this, then great.


    "Kevin.Conner@jboss.com" wrote:
    "tfennelly" wrote:
    Do we want to merge deployments of the same type as in this case, where the EBWS and the new HttpGateway both require war deployments? What would that gain and would the added complexity be worth it?


    Yes, these should be merged into the same war file so that we have a single deployment. Even with the current EBWS code we already have an issue where we conflict with other deployments, Expanding the number of these deployments, especially when not necessary, seems strange to me.

    BTW what added complexity do you get from adding more servlets into a deployment? Can you expand on where you think the issue lies?


    It's not the end result that's complex in my view, so you are right... there's nothing complex about adding more servlets into a deployment. For me, it's about how you achieve this in the current deployer i.e. gather together the info to create the single war, without it being a hack. In the current arch where we don't have a common codebase for doing this and EBWS cannot be built upon (in its current form), shoehorning http in alongside it would end up being a hack. Hence I think we need to rework some of EBWS in order to get a common base upon which this stuff can be built.

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

     

    "Kevin.Conner@jboss.com" wrote:
    "tfennelly" wrote:
    <http-provider name="myhttp" host="localhost" port="9999">
     <http-bus busid="http1" context="/orders" />
    </http-provider>

    The context would not be part of this as the requirement is to keep this to a single deployment. It would share the same context as the EBWS, i.e. based on the esb deployment name by default.


    Right... context would only be required if we are creating multiple deployments. If not and if we are supporting urlPattern, the it seems like it is not needed.

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

     

    "Kevin.Conner@jboss.com" wrote:
    "tfennelly" wrote:
    1. Add a strict config model inside the ESB config file whereby we only allow certain configurations and we manually map those appropriately to the web.xml going into the generated .war sub deployment.

    This allows us to remain in control of what we support and is the preferred method.


    Kev, please lets not say "it is the preferred method" just yet!!

    At the moment, I don't agree with your analysis for a number of reasons. As far as I see it, we can easily control what we merge from the user defined web.xml into the generated web.xml, so having control is not really an issue IMO. Also, I don't agree that we should be restricting the user unless there is a "grave" danger that they would not be able to resolve easily. I don't see this as being one.

    The down side as I see it would be that implementation of the "strict model" becomes quite a bit more complex since a mapping process would be more complex (IMO) than a filtering process. We have to document this new config model (the web.xml approach is already well documented and familiar to the user). We have to maintain it going forward. In some ways, I feel we are reinventing the wheel with this approach.

    "Kevin.Conner@jboss.com" wrote:
    "tfennelly" wrote:
    2. We allow the user to specify a suplemental web.xml that gets merged into the generated web.xml. The user would define the "extra" configs as per the web.xml schema. We could allow them specify this inline in the esb config, or externally. We might want to restrict the config types we allow in this e.g. you can't define any servlet/filter configs etc??

    This is likely to lead to problems unless the restrictions are so strict as to end up with the equivalent of the first suggestion. Adding explicit support, especially under our control, is much easier than disabling parts.


    Well firstly, I wouldn't be in favor of restricting the user in this case, but even if we do decide to do that, I think if we keep the config the same as that of the web.xml, the maping process is considerably easier for us to implement/document and is more natural to the user. Same points as I made above.

    "Kevin.Conner@jboss.com" wrote:
    "tfennelly" wrote:
    The existing http gateway also supports configuration of allowed http methods. Do we need to bring this along?


    Yes, we need to retain support for the following verbs, DELETE, HEAD, GET, POST and PUT. We also need to provide automatic support for OPTIONS so that someone can determine what capabilities are present.

    Only TRACE, as currently implemented, is not required.


    Sorry Kev... I wasn't clear in the original... what I mean't was a config to restrict the methods allowed through a given bus. The existing HTTP Gateway has an "allowMethods" config, whose default is basically all methods (I think). This config option allows the default to be overridden.

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

     

    "Kevin.Conner@jboss.com" wrote:
    "tfennelly" wrote:
    Apparently we can't do this and I don't really get why. Can you explain your logic here Kev please?

    I know we have discussed this on a number of occasions, Monday being the last. All I can do is repeat what was said before.

    (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 implementation 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



    Right, we didn't continue after that point and that comment didn't really add up for me :)

    As I see the use cases around this, we have the following type of interaction (which doesn't look like the interaction you have above):
    (sync-http-client) --> (http-gateway) --> (Service)
    


    One way or another, the Http Gateway is going to be returning a synchronous response to the sync client. The question is what does the Http Gateway return? Even after your comments on IM, I still don't see why we can use the mep of the service.

    Of course, perhaps I have totally misunderstood what a "RequestResponse" mep means and that it doesn't mean what it says on the tin (to steal a phrase from a TV add for paint :) ). If I have, I suspect I'm not the only one.

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

     

    "Kevin.Conner@jboss.com" wrote:
    Sorry, meant to add the following to my last.

    As the example above shows, the mep on the service is an implementation detail specific to that service and is used by the pipeline to determine how it should handle requests.

    The original rosetta code assumed that any message getting to the end of the pipeline was a response and, therefore, sent it whether it was required or not. This lead to duplicate actions (returning messages or nulls), duplicate replies being sent etc.

    The mep was introduced to control this, providing explicit instruction to the pipeline stating how it should handle any responses.

    This is nothing to do with a client contract, which we don't really have, and cannot be used to determine client behaviour.

    Look through the async continuation stuff for more examples of how easy it is to use OneWay services to implement request/response behaviour.

    Kev


    Sorry... I sent the last one before getting to this.

    Sorry again, but this all seems a bit confusing to me in the context of the Http Gateway use cases, that I have in my head. Perhaps I'm a total idiot, but I just don't follow this. Am I alone here?

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

     

    "Kevin.Conner@jboss.com" wrote:
    I have just had a chat with Tom and we feel that this topic needs further discussion before we proceed with integrating the gateway. We would both like to get this right rather than rush something into the release.

    As a result I am going to move this out of the 4.6 release, at least for now, but we cannot afford to let this go on for too long. Lets give this a week to progress then document what is expected.

    Kev


    +1000 :)

    Thanks for your comments Kev!

  • 21. Re: Http Gateway - requirements please...
    Mark Little Master

    Can we please have this in 4.7 then? We really need it for SOA-P 5.

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

     

    "tfennelly" wrote:
    I agree that merging them is ideally what we want, but given the current arch where the listeners are tied in with the services etc, merging what are essentially 2 separate listeners together (as alike and all as they are) without them both being based on a common "framework" would only seem possible (to me) via a hack.

    But this is not done at the listener level, it is done during deployment. It would be straight forward to handle this in a clean manner, without any need for hacks.

    "tfennelly" wrote:
    I'm not really suggesting a "fully extensible" framework... more like a "common" framework/codebase that the Http Gateway and EBWS would build off.

    Sure, we are in agreement here. The first version wasn't that though, which is what I was referring to.

    "tfennelly" wrote:
    It's not the end result that's complex in my view, so you are right... there's nothing complex about adding more servlets into a deployment. For me, it's about how you achieve this in the current deployer i.e. gather together the info to create the single war, without it being a hack.[/quote
    There is no need for this to be a hack.

    "tfennelly" wrote:
    In the current arch where we don't have a common codebase for doing this and EBWS cannot be built upon (in its current form), shoehorning http in alongside it would end up being a hack. Hence I think we need to rework some of EBWS in order to get a common base upon which this stuff can be built.

    Definitely, the outcome of this has to be a cleaning up of what we currently have. How can they be merged otherwise?

    Kev


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

     

    "tfennelly" wrote:
    Kev, please lets not say "it is the preferred method" just yet!!

    Okay, it is my preferred method :)

    "tfennelly" wrote:
    At the moment, I don't agree with your analysis for a number of reasons. As far as I see it, we can easily control what we merge from the user defined web.xml into the generated web.xml, so having control is not really an issue IMO.

    Really? How do you propose to validate everything they have added and make sure that it does not interfere with what we configure? It is much easier for us to use a configuration which we control to generate a valid deployment.

    "tfennelly" wrote:
    Also, I don't agree that we should be restricting the user unless there is a "grave" danger that they would not be able to resolve easily. I don't see this as being one.

    The potential exists and it needn't.

    "tfennelly" wrote:
    The down side as I see it would be that implementation of the "strict model" becomes quite a bit more complex since a mapping process would be more complex (IMO) than a filtering process. We have to document this new config model (the web.xml approach is already well documented and familiar to the user). We have to maintain it going forward. In some ways, I feel we are reinventing the wheel with this approach.

    It is certainly true that it would save us some development time if we did not have to handle the mapping but then it is my opinion that doing that development up front will make it easier for users and us, in terms of support/questions.

    "tfennelly" wrote:
    Well firstly, I wouldn't be in favor of restricting the user in this case, but even if we do decide to do that, I think if we keep the config the same as that of the web.xml, the maping process is considerably easier for us to implement/document and is more natural to the user. Same points as I made above.

    Sure, but this then goes back to validating all they have and making sure it doesn't impact on what we need. So you are moving from a safe mapping/generating to a process which requires much tighter validation.

    "tfennelly" wrote:
    Sorry Kev... I wasn't clear in the original... what I mean't was a config to restrict the methods allowed through a given bus. The existing HTTP Gateway has an "allowMethods" config, whose default is basically all methods (I think). This config option allows the default to be overridden.

    Sorry, I guess I wasn't clear :). Yes, it should be configurable.

    Kev

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

     

    "tfennelly" wrote:
    As I see the use cases around this, we have the following type of interaction (which doesn't look like the interaction you have above):
    (sync-http-client) --> (http-gateway) --> (Service)
    

    Sure it does, you just need to add the second service
    (sync-http-client) --> (http-gateway) --> (OneWay, routing Service) -> (RequestResponse service)
    


    "tfennelly" wrote:
    One way or another, the Http Gateway is going to be returning a synchronous response to the sync client. The question is what does the Http Gateway return? Even after your comments on IM, I still don't see why we can use the mep of the service.

    The gateway can still make a synchronous call to a service defined with an mep of OneWay as, in the example above, it is a subsequent service which is responsible for sending the reply. Your code will, erroneously, assume that it is oneway from the client's perspective when that is not the case. It is the combination of the services which provide the request/response behaviour.

    Kev

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

     

    "tfennelly" wrote:
    Sorry again, but this all seems a bit confusing to me in the context of the Http Gateway use cases, that I have in my head. Perhaps I'm a total idiot, but I just don't follow this. Am I alone here?

    Here is the link to the asynchronous continuation stuff.

    http://www.jboss.org/community/wiki/AsyncContinuation

    Kev

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

     

    "mark.little@jboss.com" wrote:
    Can we please have this in 4.7 then? We really need it for SOA-P 5.

    It is definitely scheduled for SOA 5, which means 4.7 if not 4.6. I haven't moved the issue yet but will now do so.

    Kev

  • 27. Re: Http Gateway - requirements please...
    David Ward Master

     

    "Kevin.Conner@jboss.com" wrote:
    "tfennelly" wrote:
    Kev, please lets not say "it is the preferred method" just yet!!

    Okay, it is my preferred method :)
    Kev


    Just to throw in my opinion, it's my preferred method too...

    "Kevin.Conner@jboss.com" wrote:

    "tfennelly" wrote:
    At the moment, I don't agree with your analysis for a number of reasons. As far as I see it, we can easily control what we merge from the user defined web.xml into the generated web.xml, so having control is not really an issue IMO.

    Really? How do you propose to validate everything they have added and make sure that it does not interfere with what we configure? It is much easier for us to use a configuration which we control to generate a valid deployment.
    Kev


    Even though part of me wants to side with Tom and Daniel on this (so as to allow maximum flexibility to the user), I think we would be opening up a big can of worms. I don't think we want to - or even should - support everything you can put into a web.xml. We're not trying to be an entire "Servlet [Container] Gateway" here, just an HTTP Gateway.

    David


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

     

    "Kevin.Conner@jboss.com" wrote:
    "mark.little@jboss.com" wrote:
    Can we please have this in 4.7 then? We really need it for SOA-P 5.

    It is definitely scheduled for SOA 5, which means 4.7 if not 4.6. I haven't moved the issue yet but will now do so.

    Kev


    Actually I moved this already guys to 4.x. There didn't seem to be a 4.7.

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

    OK... so I think we are in agreement then that EBWS in it's current form would need to change in order to provide a common basis for these http related features? I thought Kev was suggesting otherwise.

    Re using mapped Vs filtered "suplemental" web.xml data (for want of a better term), how about we identify:
    1. What we think would need to be validated?
    2. Where the possible sources of conflict would be if we didn't validate (which nobody is proposing)?

    Obviously they both go hand in hand :)

    I think the same level of validation can be achieved with either approach. With either approach you can restrict the user defined config to containing specific values, after that (for me) it's just about the format and I think keeping it in line with the web.xml makes sense from a user perspective (they know web.xml) and removes the need to perform a mapping (because it's already in the target format).

    What we differ on perhaps is the strictness of the validation. Kev and Dave prefer the "we only allow values X, Y and Z and we block everything else" approach, where as Danny and I seem to prefer the "we don't allow A, B, or C but do allow everything else" approach (if that makes sense :) ).

1 2 3 4 Previous Next