[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by Kevin.Conner＠jboss.com
"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
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238202#4238202
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238202
17 years, 1 month
[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by Kevin.Conner＠jboss.com
"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
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238199#4238199
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238199
17 years, 1 month
[Design of JBoss jBPM] - Re: EJB 2.1 Beans in jbpm 4?
by camunda
Okay, I checked the Remote configuration now. Quite cool! Pretty nice for normal use cases I think.
I still have some concerns:
1.) For Marketing reasons I would like to see EJB 3 inside of it. Even if you don't use it directly, EJB 2.1 is just "odd old" ;-) Too unsexy for jbpm 4. Maybe not a high priority, but still. And as Jorram pointed out, the developers supporting it or people trying to figure out transaction problems or whatever have a harder live here.
2.) I wouldn't completly let got of the commands. Zwo use cases from my last projects of a big customer, where I still would prefer them:
a) Batch Commands: We just added a thin layer around the commands in order to be able to call them in a batch. The same command, but just with different parameters (e.g. from a csv). So in one batch you could execute a couple of thound commands (sync or async. Normally async with a big amount). Would be possible with the current API as well, but was/is much easier by using the commands directly.
b) Chained Commands: Think of the use case, where you have to fix an instance. E.g. you have to cancel it, start a different "fixing" process for it, maybe jump to a special node and execute a Groovy script to fix process variables. Okay, maybe not the best example here, but we had business requirements to do stuff like this. Therefro we introduced a CommandChain which can execute other commands IN ONE transaction. (Clue is you can execute the chain as batch :-)). If you use the remote ProcessEngine it executes every call in its own transaciton, right?
And again, I think it is even easier to implement with the commands, than with the API...
This is why I still like the commands. But maybe I am just too used to it? So if you have good points agaionst it just let me know :-)
Thoughts?
Cheers
Bernd
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238174#4238174
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238174
17 years, 1 month
[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by tfennelly
"Kevin.Conner(a)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?
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238158#4238158
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238158
17 years, 1 month
[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by tfennelly
"Kevin.Conner(a)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.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238157#4238157
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238157
17 years, 1 month