June 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by tfennelly

"Kevin.Conner(a)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(a)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(a)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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238153#4238153 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238153

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by tfennelly

"Kevin.Conner(a)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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238150#4238150 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238150

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by tfennelly

"Kevin.Conner(a)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(a)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(a)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. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238145#4238145 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238145

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Status / Documentation of gwt-console & report-server

by kukeltje

a decent *runtime* error that would be View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238144#4238144 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238144

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

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 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238142#4238142 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238142

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Status / Documentation of gwt-console & report-server

by kukeltje

I agree with Tom about the showing of variables. Afaik, the jsf console does the same. The suggestion about the constraints regarding processdeployments is a valid one as well. Would the 'assume nothing, expect everything' be a good approach? Like there *can* be a processimage or there can be forms but if one is not there, at least show a decent error? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238141#4238141 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238141

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"beve" wrote : I might be missing something obvious here but why can't we let users specify servlet filters? | Would this not give users some flexibility regarding transforming the response (compression perhaps) or adding logging. The only downside is that it introduces another model, servlets in addition to esb, but this may be something that they already have in house. It is certainly something to bear in mind. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238139#4238139 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238139

16 years, 9 months

1
0
0 / 0

[Design of JBoss jBPM] - Re: Status / Documentation of gwt-console & report-server

by tom.baeyens＠jboss.com

from a prioritization perspective, first focus should be to complete this list of functionalities http://www.jboss.org/community/wiki/GWTConsoleFeatureSet if for those functionalities something is lacking in the core engine, discuss it and we'll deal with it. another aspect that i want to see prioritized is that the example processes all should be fully executable using the console only. for showing the process variable values, you can do introspection on the actual values that you get. you could render strings, numbers and dates and just use toString for all the other types. process variable editing can be addressed later. that is not a priority i think. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238133#4238133 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238133

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

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 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238132#4238132 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238132

16 years, 9 months

1
0
0 / 0

[Design of JBoss ESB] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"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 View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238131#4238131 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238131

16 years, 9 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums June 2009