[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by Kevin.Conner@jboss.com
"tfennelly" wrote : So that was some basic configuration. How about adding security etc?
Yes, security has to be included. It needs to cover authentication, transport guarantees, security constraints and integrate into the security work done by Daniel.
"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.
"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.
"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.
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238130#4238130
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238130
16 years, 9 months
[Design of JBoss jBPM] - Re: Status / Documentation of gwt-console & report-server
by heiko.braun@jboss.com
That's right, the docs are still missing. Some of the functionality is only available in particular situations, i.e:
- depending on the process itself (i.e task forms)
- the type & contents of process deployments (i.e. process image)
- plugin functionality (forms)
Before you go ahead a d discuss UI elements, it would make more sense to think about meaningful constraints, that can be applied to process deployments. Currently the console has to cope with a lot of unknowns, which derive from the "everything possible, but nothing mandatory" style of coding that jbpm4 reflects.
Up to now I tried to include functionality in the console that is applicable to most of the use cases, but of course there is much more do add. However if it only applies to a small percentage of use cases and furthermore isn't even constrained to a certain degree we cannot simply add it.
I'll give you an example:
Process variable inspection is one of those cases. There is currently no constraint on variables whatsoever. The "hashmap" style of design allows for everything and nothing at the same time. Of course it would be useful have that feature in the console, but without any type descriptions associated with the process it will only work in particular situations and break in others.
I can list plenty of other features that have been hold back, because the core codebase doesn't allow for reliable hook into runtime inspection.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238129#4238129
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238129
16 years, 9 months
[Design of JBoss ESB] - Re: Http Gateway - requirements please...
by Kevin.Conner@jboss.com
"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.
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.
"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?
"tfennelly" wrote : Apart from potential implementation similarities, what else should the new HttpGateway have in common with the EBWS functionality?
I'll try and cover this later when I post about the original plans.
Kev
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238121#4238121
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238121
16 years, 9 months
[Design of JBoss jBPM] - Extending jBPM, Plugging in custom IdentityService implement
by shekharv
I was trying to identify how one could extend the current jbpm identity implementation or plugin one's own IdentityServiceImpl. I dug around in the code a bit and noticed that there are a couple of bindings.xml files that really are responsible for configuring what Implementation classes are responsible for each of the high level Service interfaces that we have in jBPM. TaskService, ExecutionService, etc.
jbpm.wire.bindings.xml
jbpm.user.bindings.xml
Had a few points to note about the approach mentioned above,
1.) Is this the intent of the designers of the system and the api developers to provide extension points into the engine in this manner?
2.) There is also the jbpm.user.bindings.xml. From the looks of how the bindings are being stored(as a list) it does not seem that any bindings that we add to this file would override the bindings in the jbpm.wire.bindings.xml. So it seems to be more of an additive nature than overriding. So you could add new bindings, but you cannot replace/override the ones that the engine sets up by itself(default wire.bindings.xml)
3.)Taking the above point into consideration, should the jbpm.wire.bindings.xml be user configurable option? If needed? So that there is a more straightforward way to 'register' one's custom implementations for Identity and other Services(If needed). Or should the jbpm.user.bindings.xml be loaded in such a manner that it can override the existing ones. So store the bindings in a Map rather than a List?
All this is based on my understanding of the way things are being setup within the engine, we have really been working with jbpm4 for a little over a week now. So I could be really miles away from the truth and the bigger picture. Excuse me if that is the case.
Plugging in a custom IdentityServiceImpl would be a big gain if we are able to hook it up seamlessly to work with our own auth mechanism.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238088#4238088
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238088
16 years, 9 months
[Design of Management Features on JBoss] - Re: EJB3 managed component names and types
by ALRubinger
I've pushed another alpha release of the metrics deployer, this one:
* Includes the MetaMapper for the invocation statistics
* Updates the component subtypes as requests
SLSB and SFSB tests now passing again. There are some TODOs in the tests themselves I haven't yet done anything with; where those intended for me or were you marking it for yourself for later, Ian?
MDB and Entity tests still not passing as no MDBs or Entities are deployed. ;) These should be pretty trivial, but I've got to call it a night and stop here for now.
Outstanding question: "invocationStatsLastResetTime" is a managed property upon the MOs themselves, but is also available via the "invocationStats" mapped property. Which would you like (I'm assuming not both)?
I believe the weekly Jopr confcall is tomorrow, though I'll be unavailable by voice I'll try to pop into IRC if I can.
S,
ALR
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4238085#4238085
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4238085
16 years, 9 months