[Design of JBoss jBPM] - General questions, SAP asking.
by pkovgan
Hi,
My name is Peter and I'm working for SAP .
Jboss Jbpm is great product of such kind and we make our efforts to accommodate this interesting stuff in our new generation business application.
We have several general questions and I will appreciate any help or helpful link.
0.(the first question): Could you, please, formalize what standards are actually supported by Jboss BPEL part of JBPM?
What BPEL version and what WS standards are must to be followed to effectively use your engine? All standards relative information you have will help us.
1. Does Jboss BPEL part of JBPM support old fashion axis web services?
Particularly: why web service developed and issued under axis 1.3 does not work in BPEL process(my tests)? Is it difference in wsdl that causes the problem? Is there workaround?
2. Is it feasible to establish java binding instead soap(xml) binding to those web services that used locally(relative to business process) on Jboss to avoid performance degradation? Is there plan to make such trick possible?
3. If Axis 1.3 Web Services are not supported now,do you have plans to support them later?
4. What current status of BPEL part of project? Does it move? Is there active development?
5. We need some person on your side to ask more questions, because we may have plans to accommodate your product in our new generation business application and so we need some contact.
Could you help?
Thanks a lot!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987130#3987130
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987130
19 years, 4 months
[Design of JBoss Portal] - Re: Deployment architecture for 3.x
by sverker
I would definitely vote for the approach you suggest at the end, i.e. use native integration whenever possible and fall back to hooks in web.xml for what's not possible to do natively.
The main reason is that if JBoss Portal integrates natively as a component into the app server, then I as a developer/administrator/user can use the same configurations and tools that I'm used to no matter if my app server is JBoss, JONAS, Geronimo, OracleAS or just a plain Tomcat or Jetty. Each of these have their own conventions on how to do things, which those who use them are used to. It shouldn't be necessary to have to bother with custom methods to deploy JBoss Portal apps if the necessary information already is available in the app server. Also, the integration should be as non-intrusive as possible so that I don't have to change app server config which might potentially create problems for other applications.
Take your competitor Liferay as example. Their approach is that they use a private deploy directory from where they pick up war files (and require a lot of changes to the app server config). That means that I can't create an ear which contains my application with a war file which is intended to plug into the Portal server component as that ear file will be deployed by the default deployer and the embedded war file will not be picked up by the portal-specific deployer.
When doing fallback to technique 2 all that should be necessary to do is to set up either a listener or a servlet in web.xml, whichever approach you chose, that serves as a bootstrap for the portal specific deployer.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987111#3987111
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987111
19 years, 4 months
[Design of JBoss Portal] - UserProfileModule LDAP implementation
by bdaw
I have some design issues with UserProfileModule implementation
First to clarify some things:
1) UserProfileModule is supposed to be an interface for access to User properties:
| public Object getProperty(User user, String propertyName)
| public void setProperty(User user, String name, Object property)
| public Map getProperties(User user)
|
Main idea was to give some abstraction and enable to to mix implementations - i.e LDAP UserModule implementation and Hibernate UserProfileModule implementation. In ldap user properties are mapped to entry attributes.
2) Currently (in 2.4) with Hibernate implementation user porperties are stored in a Map mapped to a table "jbp_user_prop"
The issue is that the table is related to "jbp_user" using surrogate key.
The first thing was to specify which fields User object must have. As I described here I decided that minimum fields are: userName, realEmail, enabled. The reason of this is simply because not every field can be mapped to attribue that occurs in default LDAP schema. Model for User must be consistent for both DB and LDAP. The rest of information related to the user should be obtained using UserProfileModule (like familyName, signature, phone, icq, skype and etc.)
The issue is that from the properties types defined in User interface many don't have proper attribute types in LDAP schema. And some of them are used by portal core features (theme, last login date, registered date...)
This means that it's impossible to have truly LDAP only implementation of UserProfile that is based only on LDAP attributes. This also means that in current portal design, mapping properties to LDAP attributes must be optional ? if one is not mapped it must be persisted anyway by portal. Implementation should be transparent so not to limit the possible properties . This will act like two levels of properties persistence.
The main issue here is that we can't simply use the 'jbp_user_prop' table as it uses User surrogate key managed by hibernate. We also want to avoid db schema changes in portal 2.6 as for now this would be the only change
Few ideas for the LDAP implementation:
1)Make separate table like 'jbp_ext_user_prop' and map properties there using 'userName'. This should be in separate SessionFactory, independent from current identity schema.
The LDAPUserProfileModuleImpl will just check if the mapping exist for LDAP attribute and if no store/retreive property in database
The HibernateUserProfileModuleImpl will use existing schema.
pros: it's the simplest way
cons: we end up with two tables that does the same
2)Make use of existing 'jbp_user_prop'. LDAPUserProfileModuleImpl will create empty instance of user if it doesn't exist in database and then use it to store properties.
Pros: we reuse the existing schem
cons: there is an overhead for user creation in DB
If we chose the first option and someone keeps users in both ldap and DB (for authentication purposes) and then switches identity between Hibernate/LDAP - user properties are lost.
My option is the 1) one anyway as it's not intrusive for schema and simple.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3987073#3987073
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3987073
19 years, 4 months