[JBoss ESB Development] - Integrate JBoss SOA-P and SOA Software registry
by Scott Dawson
Scott Dawson [http://community.jboss.org/people/ScottDawson] created the discussion
"Integrate JBoss SOA-P and SOA Software registry"
To view the discussion, visit: http://community.jboss.org/message/579527#579527
--------------------------------------------------------------
I just modified a JBoss SOA Platform instance to use the SOA Software registry. I noticed that there is a JIRA issue ( https://issues.jboss.org/browse/SOA-1478 https://issues.jboss.org/browse/SOA-1478) regarding updating the JBoss-SOA Software integration documentation for SOA-P 5.x and I think I can give you most of the required updates based on my experience.
My software versions are:
JBoss SOA Platform 5.0.2.GA
SOA Software Service Manager 5.2 + updates through sm52-update-3.44
Linux (RHEL 5.5)
I used the SOASoftwareIntegration.pdf that ships with JBoss ESB 4.7. The list that follows are the points where I had to do something different from what is shown in that document.
1. The example URLs in the document are based on UDDI v2. I chose to make everything UDDI v3 compatible so the SOA Software URLs specified in jbossesb-properties don't need the "_v2" suffix as shown in the document. SOA Software's UDDI v3 URLs don't have the version number appended. Also, I had to specify the securityManagerURI in addition to the queryManagerURI and lifeCycleManagerURI shown in the document. Without the securityManagerURI, Scout errors occur.
2 I had to specify 2 registry interceptors in jbossesb-properties, again, to eliminate Scout errors. Fortunately, this configuration appears commented out in the file, so I only had to uncomment it:
<property name="org.jboss.soa.esb.registry.interceptors"
value="org.jboss.internal.soa.esb.services.registry.InVMRegistryInterceptor, org.jboss.internal.soa.esb.services.registry.CachingRegistryInterceptor"/>
With these changes, here is the resulting 'registry' section in the jbossesb-properties file, which is located in the server/<profile>/deployers/esb.deployer directory:
<code>
<properties name="registry">
<property name="org.jboss.soa.esb.registry.uddi.maxRows" value="100"/>
<property name="org.jboss.soa.esb.registry.queryManagerURI" value=" http://soa01:9901/uddi/inquiry http://soa01:9901/uddi/inquiry"/>
<property name="org.jboss.soa.esb.registry.lifeCycleManagerURI" value=" http://soa01:9901/uddi/publish http://soa01:9901/uddi/publish"/>
<property name="org.jboss.soa.esb.registry.securityManagerURI" value=" http://soa01:9901/uddi/security http://soa01:9901/uddi/security"/>
<property name="org.jboss.soa.esb.registry.implementationClass" value="org.jboss.internal.soa.esb.services.registry.JAXRRegistryImpl"/>
<property name="org.jboss.soa.esb.registry.factoryClass" value="org.apache.ws.scout.registry.ConnectionFactoryImpl"/>
<property name="org.jboss.soa.esb.registry.user" value="administrator"/>
<property name="org.jboss.soa.esb.registry.password" value="password"/>
<!-- the following parameter is scout specific to set the type of communication between scout and the UDDI (embedded, rmi, soap) -->
<property name="org.jboss.soa.esb.scout.proxy.transportClass" value="org.apache.ws.scout.transport.AxisTransport"/>
<property name="org.jboss.soa.esb.scout.proxy.uddiVersion" value="3.0"/>
<property name="org.jboss.soa.esb.scout.proxy.uddiNameSpace" value="urn:uddi-org:api_v3"/>
<property name="org.jboss.soa.esb.registry.interceptors"
value="org.jboss.internal.soa.esb.services.registry.InVMRegistryInterceptor, org.jboss.internal.soa.esb.services.registry.CachingRegistryInterceptor"/>
<!-- The following properties modify the cache interceptor behaviour -->
<property name="org.jboss.soa.esb.registry.cache.maxSize" value="100"/>
<property name="org.jboss.soa.esb.registry.cache.validityPeriod" value="600000"/>
<!-- Organization Category to be used by this deployment. -->
<property name="org.jboss.soa.esb.registry.orgCategory" value="org.jboss.soa.esb.:category"/>
</properties>
</code>
It appears that everything is working correctly. The app server comes up without errors and I see a couple of services in the 'Red Hat/JBossESB' organization in Service Manager. Based on past experience with the community version ESB (and the screenshots in the document), I expected to see more JBoss internal services but only 2 currently appear in the registry: DeadLetterService and JBpmCallbackService.
I hope this is helpful.
Regards,
Scott Dawson
Unisys
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/579527#579527]
Start a new discussion in JBoss ESB Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
13 years, 4 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - AS 7 "Detyped" Management API
by Brian Stansberry
Brian Stansberry [http://community.jboss.org/people/bstansberry%40jboss.com] commented on the document
"AS 7 "Detyped" Management API"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16235#comment-5159
--------------------------------------------------
As discussed above we're talking about a scheme where portions of the management model can be addressed via ordered list of key/value pairs:
[{base=>domain},{profile=>default},{subsystem=>web},{connector=>http}
Any portion of the model that can't be addressed that way would be treated as an attribute of an item that could. Attributes don't need to be simple times; they can be lists or a detyped representation of a more complex object graph.
Anyway, bit of a data dump... a couple weeks back I went through the model elements in Alpha1 to analyze how they'd fit into such an addressing scheme and see if there are any blockers. Result is attached in a spreadsheet. I didn't find any blockers. I attached it to this document in case anyone is interested. And in case it's a useful reference document for looking at the structure of the management model.
The structure of the spreadsheet isn't too intuitive. There's tab for each type of model. Within each tab is a series of "Key" and "Value" columns that describe the tree of addressable elements. To the left of all that is a column that lists some non-trivial attributes that are found at the relevant point in the tree. (Yes, I know, having them on the left is weird). Left of that is some comment about how to represent the attribute. One or more * in the comment indicates there's something to think about a bit.
--------------------------------------------------
13 years, 4 months
Re: [jboss-dev-forums] [JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Ales Justin
Ales Justin [http://community.jboss.org/people/alesj] commented on the document
"EJB3/JPA 2.0 support for AS7"
To view all comments on this document, visit: http://community.jboss.org/docs/DOC-16271#comment-5156
--------------------------------------------------
> We need to do more than just use the PersistenceProvider interface properly for this to work.
Sure, that's why is used "...". ;-)
It should be strictly interfaces or some well defined api classes.
> We also need to ensure the application classloader provided Hibernate, can be used over the Hibernate version bundled with the AS.
If the interfaces don't change much, it should be doable to some extent.
> We should have a unit test for this as well. Maybe it could include an old version of Hibernate EM and verify that it is used.
>
You can use the demo/test and enhance it a bit.
But it should be noted that this is not 100% to work,
some sort of compatibility matrix would be useful to have as a wiki entry.
--------------------------------------------------
13 years, 4 months
[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] modified the document:
"EJB3/JPA 2.0 support for AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about how the AS-7 JPA layer and related concerns. Its a rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
2. No transaction invocation
1. Loaded entities are detached at end of method call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. XPC is closed when dependent session bean(s) are closed (via @remove method).
5. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with.
7. EJB Container interaction
1. TBD
8. Desires1. Maintainable code (a ten minute fix will take ten minutes :)
2. Would like to do a better job of showing what is going on at the EM level (e.g. logging the EM units of work grouped by transaction).
3. Consider any EM (container) extensions that make it easier to measure performance (perhaps based on Hibernate statistics). Its always nice to see how long each transaction took and the units of work within the transaction. It would be nice if we could do this with any persistence provider (for performance comparison).
4. Deal with the Hibernate persistence provider via the same way as we would interact with other persistence providers (via PersistenceProvider mentioned above).
5. Peace
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 4 months
[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS7
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] modified the document:
"EJB3/JPA 2.0 support for AS7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about how the AS-7 JPA layer and related concerns. Its a rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
2. No transaction invocation
1. Loaded entities are detached at end of method call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. XPC is closed when dependent session bean(s) are closed (via @remove method).
5. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with.
7. EJB Container interaction
1. TBD
8. Desires1. Maintainable code (a ten minute fix will take ten minutes :)
2. Would like to do a better job of showing what is going on at the EM level (e.g. logging the EM units of work grouped by transaction).
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 4 months
[JBoss AS7 Development] - EJB3/JPA 2.0 support for AS-7
by Scott Marlow
Scott Marlow [http://community.jboss.org/people/smarlow%40redhat.com] modified the document:
"EJB3/JPA 2.0 support for AS-7"
To view the document, visit: http://community.jboss.org/docs/DOC-16271
--------------------------------------------------------------
This is about how the AS-7 JPA layer and related concerns. Its just a starting rough draft, mostly points copied from the JPA 2.0 spec.
1. Container-managed persistence context
1. Transaction scope (JPA 7.6.1)
1. Transaction active invocation
1. Persistence context is created if none already associated with transaction
2. Created persistence context ends when transaction ends
3. An extended persistence context can also be used, which survives when transaction ends.
2. No transaction invocation
1. Loaded entities are detached at end of method call.
2. Extended scope (JPA 7.6.2)
1. Only supported for stateful session beans.
2. Entity modifications can be made outside of a transaction and are applied on the next joined transaction (anywhere on the cluster).
3. Extended persistence context (XPC) is created when stateful bean that depends on a XPC is created.
4. XPC is closed when dependent session bean(s) are closed (via @remove method).
5. Inheritance
1. Stateful beans that create other (local) stateful beans, share the same XPC.
3. Persistence context propagation (JPA 7.6.3)
1. A persistence context will be propagated to multiple entity managers (instances) within the same local transaction.
2. Remote invocations do not propagate the persistence context.
4. Persistence context propagation requirements for component invocations (JPA 7.6.3.1)
1. no propagation if component is invoked without a JTA transaction or without the JTA transaction propagating:
1. Transaction scoped entity manager used within the invoked component, will create a new persistence context.
2. Extended scoped entity manager used within the invoked component, will use the XPC already bound to the (invoked stateful) bean.
3. If the entity manager is invoked within a JTA transaction, the persistence context is bound to the JTA transaction.
2. If a component is invoked and the JTA transaction is propagated into the component:
1. If (SFSB) component has a XPC and the transaction already has a different persistence context associated with it, an EJBException is thrown by the container.
2. If a persistence context is bound to the JTA transaction, it is propagated into any entity managers used in the invocation.
2. Container requirements review
1. Application-managed persistence context (JPA 7.8.1)
1. Container needs to inject entity manager factory into jndi for application use.
2. Must use PersistenceProvider.createContainerEntityManagerFactory method for 3^rd^ party support. Internal APIs are fine for our persistence provider.
3. Must use EntityManagerFactory.close method to close the entity manager factory prior to shutdown (again for 3^rd^ party support).
2. Container-managed persistence context (JPA 7.9.1)
1. For 3^rd^ party support, use EntityManagerFactory.createEntityManager . Consider using for our persistence provider as well.
2. May pass (PersistenceProperty (http://download.oracle.com/javaee/6/api/javax/persistence/PersistenceProp... PersistenceContext.properties to EntityManagerFactory.createEntityManager(Map).
3. Container EM wrapper could implement some EntityManager.unwrap(Class<T> cls) calls but should default to underlying EM for unhandled classes.
3. Deployment
1. Extract persistence metadata from persistence.xml
2. Determine the PersistenceProvider classname for each persistence unit (PU). The default class is currently org.hibernate.ejb.HibernatePersistence.
3. Invoke the PersistenceProvider.createContainerEntityManagerFactory(PersistenceUnitInfo, Map) to create the EMF that will be used to create all EntityManager's for the PU. The properties read from the PU are passed as the second parameter.
4. Also pass the “javax.persistence.validation.factory ” property if validation mode is not set to NONE. The validator factory value appears to be org.hibernate.validator.engine.ValidatorFactoryImpl. Consult ValidatorFactoryProvider which is currently used to bootstrap the validator factory in AS6.
5. The PU classes shouldn't be loaded until after the EMF is created.
6. The EntityManagerFactory is closed at undeploy time, which also closes all EntityManager's opened by each factory.
7. Switchboard changes for PU + PC???
4. Clustering
1. Determine impact on http://community.jboss.org/docs/DOC-13822 http://community.jboss.org/wiki/OptimizingentityandXPCreplication which may need to be tweaked for clustering other persistence providers. Judging by the jira status, this optimization is not in place yet (although Hibernate persistence provider HHH-2762 is done).
2. Determine impact on http://community.jboss.org/docs/DOC-9565 http://community.jboss.org/wiki/DevEJB3NewSFSBCache (consider support for other persistence providers).
3. Other changes?
5. Weld integration (JpaInjectionServices implementation is wired in at boot time).
6. Determine Hibernate release to target integration with.
7. EJB Container interaction
1. TBD
2. TBD
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-16271]
Create a new document in JBoss AS7 Development at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 4 months