1 2 Previous Next 18 Replies Latest reply on Oct 19, 2011 2:42 AM by jervisliu

    Use Guvnor NG as a Service Repository to manage SOA services

    jervisliu

      Hi,

       

      I've made an example which shows how to use Guvnor as a Service Repository to manage SOA services: http://community.jboss.org/wiki/UseGuvnorNGAsAServiceRepositoryToManageSOAServices

       

      Let me know if this indeed meets the requirements from SwithYard as a service repository. If not, lets start to discuss what we want and what we can do next. Your input will be highly appreciated.

       

      Thanks,

      Jervis

        • 1. Re: Use Guvnor NG as a Service Repository to manage SOA services
          kcbabo

          Hey Jervis,

           

          Thanks very much for putting this together.  We should be able to address most/all of our initial repository requirements based on what you have documented in the article.  I downloaded the version of Guvnor mentioned in the article, but I'm unable to deploy it successfully on AS 5.1 or AS 7.0.2.  Do I need to use a different version of AS or are there some other steps involved other than copying the war into the deploy directory?  I know that Rob hit this first on Friday, so I don't think it's something specific to my environment.

           

          I looked at the history of the Hudson build you linked to and the last successful build (with no test errors) was on Oct. 4th.  Should we use this build intsead?

           

          The error on AS 5.1:

          08:16:44,238 ERROR [AbstractKernelController] Error installing to PreReal: name=vfsfile:/private/tmp/jboss-5.1.0.GA/server/default/deploy/guvnor.war/ state=PostClassLoader mode=Manual requiredState=PreReal
          org.jboss.deployers.spi.DeploymentException: Error during deploy: vfsfile:/private/tmp/jboss-5.1.0.GA/server/default/deploy/guvnor.war/
                    at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
                    at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:177)
                    at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1439)
                    at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1157)
                    at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1098)
                    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
                    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
                    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
                    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
                    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
                    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
                    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
                    at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:781)
                    at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:702)
                    at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.process(MainDeployerAdapter.java:117)
                    at org.jboss.system.server.profileservice.repository.ProfileDeployAction.install(ProfileDeployAction.java:70)
                    at org.jboss.system.server.profileservice.repository.AbstractProfileAction.install(AbstractProfileAction.java:53)
                    at org.jboss.system.server.profileservice.repository.AbstractProfileService.install(AbstractProfileService.java:361)
                    at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:348)
                    at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:1631)
                    at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:934)
                    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1082)
                    at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:984)
                    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:822)
                    at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:553)
                    at org.jboss.system.server.profileservice.repository.AbstractProfileService.activateProfile(AbstractProfileService.java:306)
                    at org.jboss.system.server.profileservice.ProfileServiceBootstrap.start(ProfileServiceBootstrap.java:271)
                    at org.jboss.bootstrap.AbstractServerImpl.start(AbstractServerImpl.java:461)
                    at org.jboss.Main.boot(Main.java:221)
                    at org.jboss.Main$1.run(Main.java:556)
                    at java.lang.Thread.run(Thread.java:680)
          Caused by: java.lang.NoClassDefFoundError: javax/validation/MessageInterpolator$Context
                    at java.lang.ClassLoader.defineClass1(Native Method)
                    at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631)
                    at java.lang.ClassLoader.defineClass(ClassLoader.java:615)
                    at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
                    at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:572)
                    at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:532)
                    at java.security.AccessController.doPrivileged(Native Method)
                    at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:530)
                    at org.jboss.classloader.spi.base.BaseClassLoader.loadClassLocally(BaseClassLoader.java:507)
                    at org.jboss.classloader.spi.base.BaseDelegateLoader.loadClass(BaseDelegateLoader.java:134)
                    at org.jboss.classloader.spi.filter.FilteredDelegateLoader.loadClass(FilteredDelegateLoader.java:131)
                    at org.jboss.classloader.spi.base.ClassLoadingTask$ThreadTask.run(ClassLoadingTask.java:452)
                    at org.jboss.classloader.spi.base.ClassLoaderManager.nextTask(ClassLoaderManager.java:251)
                    at org.jboss.classloader.spi.base.ClassLoaderManager.process(ClassLoaderManager.java:150)
                    at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:265)
                    at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
                    at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
                    at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
                    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
                    at org.jboss.classloading.plugins.visitor.AbstractResourceContext.loadClass(AbstractResourceContext.java:118)
                    at org.jboss.webbeans.integration.deployer.env.WebBeanDiscoveryDeployer$WBDiscoveryVisitor.visit(WebBeanDiscoveryDeployer.java:134)
                    at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:264)
                    at org.jboss.virtual.plugins.vfs.helpers.WrappingVirtualFileHandlerVisitor.visit(WrappingVirtualFileHandlerVisitor.java:62)
                    at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:361)
                    at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:376)
                    at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:376)
                    at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:376)
                    at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:376)
                    at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:306)
                    at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:374)
                    at org.jboss.virtual.plugins.context.AbstractVFSContext.visit(AbstractVFSContext.java:306)
                    at org.jboss.virtual.VFS.visit(VFS.java:421)
                    at org.jboss.virtual.VirtualFile.visit(VirtualFile.java:437)
                    at org.jboss.classloading.plugins.vfs.VFSResourceVisitor.visit(VFSResourceVisitor.java:101)
                    at org.jboss.deployers.vfs.plugins.classloader.VFSDeploymentClassLoaderPolicyModule.visit(VFSDeploymentClassLoaderPolicyModule.java:160)
                    at org.jboss.webbeans.integration.deployer.env.WebBeanDiscoveryDeployer.deploy(WebBeanDiscoveryDeployer.java:109)
                    at org.jboss.webbeans.integration.deployer.env.WebBeanDiscoveryDeployer.deploy(WebBeanDiscoveryDeployer.java:45)
                    at org.jboss.deployers.vfs.spi.deployer.AbstractOptionalVFSRealDeployer.deploy(AbstractOptionalVFSRealDeployer.java:57)
                    at org.jboss.deployers.spi.deployer.helpers.AbstractOptionalRealDeployer.internalDeploy(AbstractOptionalRealDeployer.java:74)
                    at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:50)
                    at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:171)
                    ... 29 more
          Caused by: java.lang.ClassNotFoundException: javax.validation.MessageInterpolator$Context
                    at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
                    at java.security.AccessController.doPrivileged(Native Method)
                    at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
                    at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
                    at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
                    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
                    at java.lang.Class.forName0(Native Method)
                    at java.lang.Class.forName(Class.java:247)
                    at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:292)
                    at org.jboss.classloader.spi.base.BaseClassLoaderDomain.loadClass(BaseClassLoaderDomain.java:1119)
                    at org.jboss.classloader.spi.base.BaseClassLoader.loadClassFromDomain(BaseClassLoader.java:798)
                    at org.jboss.classloader.spi.base.BaseClassLoader.loadClass(BaseClassLoader.java:441)
                    at java.lang.ClassLoader.loadClass(ClassLoader.java:247)
                    ... 70 more
          

           

           

          The error on AS 7.0.2:

          08:10:33,223 INFO  [org.jboss.weld] (MSC service thread 1-4) Processing CDI deployment: guvnor-5.4.0-SNAPSHOT-jboss-as-7.0.war
          08:10:33,249 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC00001: Failed to start service jboss.deployment.unit."guvnor-5.4.0-SNAPSHOT-jboss-as-7.0.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."guvnor-5.4.0-SNAPSHOT-jboss-as-7.0.war".POST_MODULE: Failed to process phase POST_MODULE of deployment "guvnor-5.4.0-SNAPSHOT-jboss-as-7.0.war"
                    at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:121) [jboss-as-server-7.0.2.Final.jar:7.0.2.Final]
                    at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
                    at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
                    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_26]
                    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_26]
                    at java.lang.Thread.run(Thread.java:680) [:1.6.0_26]
          Caused by: java.lang.NoClassDefFoundError: org/jboss/logmanager/Logger$AttachmentKey
                    at org.jboss.seam.solder.logging.internal.JBossLogManagerProvider.<clinit>(JBossLogManagerProvider.java:36)
                    at org.jboss.seam.solder.logging.internal.LoggerProviders.findProvider(LoggerProviders.java:33)
                    at org.jboss.seam.solder.logging.internal.LoggerProviders.<clinit>(LoggerProviders.java:28)
                    at org.jboss.seam.solder.logging.internal.Logger.getLogger(Logger.java:2164)
                    at org.jboss.seam.logging.Logger.<init>(Logger.java:44)
                    at org.jboss.seam.logging.Logger.getLogger(Logger.java:1965)
                    at org.jboss.seam.logging.Logger.getLogger(Logger.java:1991)
                    at org.jboss.seam.config.xml.bootstrap.XmlConfigExtension.<clinit>(XmlConfigExtension.java:68)
                    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [:1.6.0_26]
                    at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [:1.6.0_26]
                    at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [:1.6.0_26]
                    at java.lang.reflect.Constructor.newInstance(Constructor.java:513) [:1.6.0_26]
                    at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadExtension(WeldPortableExtensionProcessor.java:117)
                    at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.loadAttachments(WeldPortableExtensionProcessor.java:100)
                    at org.jboss.as.weld.deployment.processors.WeldPortableExtensionProcessor.deploy(WeldPortableExtensionProcessor.java:86)
                    at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:115) [jboss-as-server-7.0.2.Final.jar:7.0.2.Final]
                    ... 5 more
          Caused by: java.lang.ClassNotFoundException: org.jboss.logmanager.Logger$AttachmentKey from [Module "deployment.guvnor-5.4.0-SNAPSHOT-jboss-as-7.0.war:main" from Service Module Loader]
                    at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:191)
                    at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:361)
                    at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:333)
                    at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:310)
                    at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:103)
                    ... 21 more
          

           

           

           

           


          • 2. Re: Use Guvnor NG as a Service Repository to manage SOA services
            rcernich

            Hey Keith, Jervis,

             

            I was able to workaround the problem in AS7 using a jboss-deployment-structure.xml file which included logmanager.  That said, it appears this package used to be included via manifest.mf, but for whatever reason that file is getting wiped during the build (I also tried a local build).  Once I got the application deployed, I was getting an exception:

             

            18:48:34,828 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/guvnor-5.4.0-SNAPSHOT-jboss-as-7.0].[securityService]] (http--127.0.0.1-8080-2) Allocate exception for servlet securityService: org.jboss.weld.exceptions.IllegalArgumentException: WELD-001324 Argument bean must not be null

                at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:747) [weld-core-1.1.2.Final.jar:2011-07-26 15:02]

                at org.jboss.as.weld.injection.InjectableField.inject(InjectableField.java:62) [jboss-as-weld-7.0.2.Final.jar:7.0.2.Final]

                at org.jboss.as.weld.injection.WeldEEInjection.inject(WeldEEInjection.java:79) [jboss-as-weld-7.0.2.Final.jar:7.0.2.Final]

                at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:60) [jboss-as-weld-7.0.2.Final.jar:7.0.2.Final]

                at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]

                at org.jboss.as.ee.component.ManagedReferenceInterceptor.processInvocation(ManagedReferenceInterceptor.java:53)

                at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]

                at org.jboss.invocation.WeavedInterceptor.processInvocation(WeavedInterceptor.java:53) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]

                at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]

                at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)

                at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:287) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]

                at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.0.Final.jar:1.1.0.Final]

                at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:152)

                at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:77)

                at org.jboss.as.web.deployment.component.WebComponentInstantiator$1.<init>(WebComponentInstantiator.java:57) [jboss-as-web-7.0.2.Final.jar:7.0.2.Final]

                at org.jboss.as.web.deployment.component.WebComponentInstantiator.getReference(WebComponentInstantiator.java:55) [jboss-as-web-7.0.2.Final.jar:7.0.2.Final]

                at org.jboss.as.web.deployment.WebInjectionContainer.instantiate(WebInjectionContainer.java:99) [jboss-as-web-7.0.2.Final.jar:7.0.2.Final]

                at org.jboss.as.web.deployment.WebInjectionContainer.newInstance(WebInjectionContainer.java:78) [jboss-as-web-7.0.2.Final.jar:7.0.2.Final]

                at org.jboss.as.web.deployment.WebInjectionContainer.newInstance(WebInjectionContainer.java:72) [jboss-as-web-7.0.2.Final.jar:7.0.2.Final]

                at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1156) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:952) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:188) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:139) [jboss-as-web-7.0.2.Final.jar:7.0.2.Final]

                at org.jboss.as.web.NamingValve.invoke(NamingValve.java:57) [jboss-as-web-7.0.2.Final.jar:7.0.2.Final]

                at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:154) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:362) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:667) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:952) [jbossweb-7.0.1.Final.jar:7.0.2.Final]

                at java.lang.Thread.run(Thread.java:662) [:1.6.0_26]

            • 3. Re: Use Guvnor NG as a Service Repository to manage SOA services
              jervisliu

              Unfortunately Guvnor is a bit broken right now it does not work with AS 7 or 5.1. It still works with Tomcat 6 though. Try this build, I've verified, it worked: https://hudson.jboss.org/jenkins/job/guvnor/1086/artifact/guvnor-distribution/target/. Use guvnor-5.4.0-SNAPSHOT-tomcat-6.0.war

              • 4. Re: Use Guvnor NG as a Service Repository to manage SOA services
                kcbabo

                Okie dokie.  Gave Tomcat 6.0 a try and everything seems to be working A-OK.

                • 5. Re: Use Guvnor NG as a Service Repository to manage SOA services
                  kcbabo

                  This is really cool stuff, Jervis.  I ran through some of the initial use cases I had in mind and thought I would share some feedback.

                   

                  It appears as though each "Service" is a package in Guvnor.  Is that correct?  My guess is that the level of granularity for artifacts in the repository will be above the service level in many cases.  For example, take a business workflow which involves five different services.  It would make sense to me for a user to package up all the related artifacts inside a single package and then manage them as a group.  I can definitely do this today with Guvnor, but the name "Service" kind of threw me off.  I'm wondering if this should be renamed to something like "Service Artifacts" or something similar?

                   

                  Speaking of packages, I was able to connect through JBDS using the Guvnor perspective and WebDAV to view the service packages I created.  Very cool.  It's easy to open and import files from that view.  I edited a schema and committed it back to the repo - couldn't have been easier.  This rocks.

                   

                  One thing I think will be very useful is offering the ability to create package snapshots from the service artifacts.  I see multiple uses for this, but one of the critical ones from a modularity standpoint is to be able to encapsulate shared interfaces and deploy those as a standalone module into the runtime.  It looks like this should already be possible since services are really packages in Guvnor, but I get the following stack trace when trying to download the package snapshot:

                   

                  java.lang.NullPointerException
                   java.io.OutputStream.write(OutputStream.java:58)
                   org.drools.guvnor.server.files.FileManagerService.loadBinaryPackage(FileManagerService.java:192)
                   org.drools.guvnor.server.files.FileManagerService$Proxy$_$$_WeldClientProxy.loadBinaryPackage(FileManagerService$Proxy$_$$_WeldClientProxy.java)
                   org.drools.guvnor.server.files.PackageDeploymentServlet$1.execute(PackageDeploymentServlet.java:262)
                   org.drools.guvnor.server.files.RepositoryServlet.doAuthorizedAction(RepositoryServlet.java:58)
                   org.drools.guvnor.server.files.PackageDeploymentServlet.doGet(PackageDeploymentServlet.java:141)
                   javax.servlet.http.HttpServlet.service(HttpServlet.java:625)
                   javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
                  
                  • 6. Re: Use Guvnor NG as a Service Repository to manage SOA services
                    jeffdelong

                    Package is currently a rules term and is an organization of rules that work together on the same set of facts. It a unit of compilation / deployment. In BRMS, we compile rules in the same package and deploy them (possible with other packages). With a service repository (which this is a prototype of), it seems like service would have a similar role, in that a service is a unit of independent functionality that could be compiled and deployed separately.

                     

                    Service compositions should also be describeable at the top level of the hierarchy as well. Although the packaging of multiple services into a deployment unit defeats some of the goals of SOA, which is to create independent services that can be part of multiple compositions. So why the service repository should let the user do this, the user should think carefully about whether this is a good thing to do.

                     

                    Service artifacts (or just artifacts) is pretty generic, but that is certainly another way to set up a repository, and let the user create all the relationships.

                     

                    Currently creating a deployment package is a rules specific feature. It would be great if Guvnor could package services, but it is not surprizing this does not work now, as creating a rules package is not like creating a jar or war.

                    • 7. Re: Use Guvnor NG as a Service Repository to manage SOA services
                      kcbabo

                      Guess I will reply in multiple posts, since the forum software decided I was done with the last one.  Continuing ...

                       

                      Is there any way to get syntax highlighting in the XML editor?  That would be really nice.

                       

                      I think "New --> Processes" needs to be split to be "New --> BPEL Process" and "New --> BPMN 2.0 Process".

                       

                      Speaking of jBPM and other Drools artifact types, what is the expectation around adding rules artifacts within the services perspective?  Is the idea that you would switch to a different perspective (e.g. 'author') and add the artifacts to the service package from there?

                       

                      Personally, I don't think storing the ESB descriptor in the repository is all that useful for SwitchYard.  There may be cases where this is useful for JBoss ESB, but I can tell you that it's unlikely we would use this at all for SwitchYard applications.  What you would do instead is check in a composite which contained one or more components and a descriptor inside of it.  This component would be the unit of management within the repository and it would make sense to be able to view details on the configuration, but the configuration itself would not be independently manageable within the repository.

                       

                      I wasn't quite sure what the intent was with the Java source artifact type.  Is the idea that you upload Java source and that gets compiled with the package?  I didn't see an option for uploading classes or jars which would contain public interface classes for a service.  I believe this sort of functionality is available for fact models elsewhere in Guvnor, but I'm guessing it might need special treatment for the services perspective.

                       

                      Can you refresh my memory on the purpose of the "Global Area"?  Right now, I can create artifacts inside a "Service", which is visible as a package from the outside.  I'm guessing this goes back to my earlier comment on whether we expect artifacts for each service to be inside their own package and any public stuff is exported to the global package.  I guess that could work, although I'm not sure whether people would be interested in creating a package for each service.  Maybe they would.  In any case, if we go this route, I think it would be better to have the ability to create your own public packages instead of relying on all public artifacts to go into the Global Area.  Perhaps the Global Area is a default public package, but you can remove it and add others as you see fit?

                      • 8. Re: Use Guvnor NG as a Service Repository to manage SOA services
                        kcbabo

                        Package is currently a rules term and is an organization of rules that work together on the same set of facts. It a unit of compilation / deployment. In BRMS, we compile rules in the same package and deploy them (possible with other packages). With a service repository (which this is a prototype of), it seems like service would have a similar role, in that a service is a unit of independent functionality that could be compiled and deployed separately.

                         

                        Sure.  It seems like this is mainly a question of the relationship between services and deployment units.  You can have a deployable unit which consists of a single service or multiple services.  I can definitely see a layout where you have individual services in the repository and then bring elements of those together inside another package.  I use the term package because it appears as though Guvnor is treating every service as an individual package internally.

                        Currently creating a deployment package is a rules specific feature. It would be great if Guvnor could package services, but it is not surprizing this does not work now, as creating a rules package is not like creating a jar or war.

                         

                        What I was hoping for at the moment is the ability to just grab a zip of all the artifacts in the package.  Eventually, I would expect there to be more involved - e.g. producing a deployable application out of Guvnor.

                        • 9. Re: Use Guvnor NG as a Service Repository to manage SOA services
                          jeffdelong

                          Splitting BPEL and BPMN process would make sense, since BPMN processes have their own editor, and BPEL processes don't.

                           

                          It's not clear you would want to add rule and bpmn2 artifacts to your service directly. More likely you would create these in rule packages, and in your service create a ChangeSet.xml file that referenced the rule package (or rule packages) that the service required (this assumes the rules and bpm components in switchyard can use the KnowledgeAgent).

                           

                          Sure, the jboss-esb.xml file is only relevant for JBoss ESB. As you state, I would expect with Switchyard to check in the composite (switchyard.xml).

                           

                          The intent for Java source would be if we wanted the Service Repository to be able to create deployment archives (i.e., your very last comment in your last post). SInce the deployment archives would contain class files, we would need a way to get them into the repository.

                           

                          The purpose of the Global Area with rules was to have a place that all packages could reference. The original need was around uploaded model files. It would be quite common for many different packages to want to use some or all of the same Java fact model. Without the Global Area, you would have to upload the model jar multiple times, once into each rule package. If you make a change to the Java classes in model jar, you would then have to re-upload it into every package. If you had lots of packages, this could get tedious. In a service repository you might have a similar requirement.

                           

                          I think the use of a "package" = "service" is a result of using a rule repository for services. I would hope / expect this term to go away when using Guvnor to manage services, and this current cut is  an intermediate step to an eventual sevice repository. What is important is the idea that there is some organizational unit (or multiple organizational units) for users to organize their artifacts, such as "services", or "service compositions", or "business processes", or perhaps some user-defined term.

                          • 10. Re: Use Guvnor NG as a Service Repository to manage SOA services
                            jervisliu

                            We are currently working on a Guvnor NG 0.1 release. What is Guvnor NG: A generic service repository or service governance tool. Can be extended and customized, eg Guvnor NG for Drools and Guvnor NG for SOA etc.

                             

                            The goal of Guvnor NG 0.1 release is to split Guvnor to Guvnor Core, Guvnor Drools and Guvnor SOA. Guvnor Core module is a stripped down core, which contains codes that are generic to a generic service repository. Then we have Guvnor for Drools and Guvnor for SOA, they inherit Guvnor Core and produce a compiled version of Guvnor with their components. Once this is done, you wont see perspective for Drools (author perspective as it is called currently in Guvnor) and perspective for SOA anymore. Instead we have two different products: Guvnor NG for Drools and Guvnor NG for SOA.

                             

                            In Guvnor NG core, we have two core concepts, "Module" and "Asset". So what is a module and an asset?

                             

                            Module: 

                            Module is a root concept has a hierarchical Folder structure (well, this may not be ture. We may not want to create any folders under the module node due to performance concerns). Module has a runtime type, esb, ws, drools etc. That type associates a builder with it. It says how do I take this module and all it's dependencies and build a jar or a war or what ever is the resulting deployable artifact.

                             

                            The depdency mechanism behaviour is dependant on the module type. In Drools it just combines everything at build time and can be used to describe sets of knowledge either via inheritence or composition or both. Other's may have a different dependnecy type.

                             

                            Asset:

                            Asset is atomic, an atomic asset is a low level rule, xsd etc. Asset can not depend on other assets. Module can contain assets. Module can depend on assets.

                             

                             

                            The term "Package" wont be used anymore in Guvnor NG core. Drools Package and SOA Service are extended from "Module". So in Guvnor NG for SOA, a module is a service. In Guvnor NG for Drools, a module is a package.

                             

                            (some related discussions can be found here: http://community.jboss.org/wiki/GuvnorRepositoryStructure).

                            • 11. Re: Use Guvnor NG as a Service Repository to manage SOA services
                              jervisliu

                              Is there any way to get syntax highlighting in the XML editor?  That would be really nice.

                              Its definitly doable. Though I did some researches before, there is no open source XML editors with syntax highlighting available in GWT. We just have to create our own.

                               

                              I think "New --> Processes" needs to be split to be "New --> BPEL Process" and "New --> BPMN 2.0 Process".

                              Done: https://github.com/droolsjbpm/guvnor/commit/08ac5ee493faf54e1415722d24cf203433c40f22

                               

                              Ok, What I really want to show here is how easy it is to customize Guvnor NG.  In my commit above, as the bpmn2 editor is already available in Guvnor, all I need to do is to add bpmn2 editor to SOA perspective. If the bpmn2 editor doesnt exist yet, what I need to do is write my own bpmn2 editor, plug it into Guvnor NG, then configure asseteditors.xml (https://github.com/droolsjbpm/guvnor/blob/master/guvnor-webapp/src/main/resources/asseteditors.xml) to make this new editor type available.

                               

                              This means we can continue to discuss whether or not we are going to need ESB descriptor in Guvnor NG for SOA. But why not we let the users to decide? We provide an out-of-box default configuration which we think is a good default for most SOA services. Because Guvnor NG for SOA is configurable and customizable, one user can grab an installation of Guvnor NG for SOA, configure it to support jboss-esb.xml. Another user can remove the support of  jboss-esb.xml completely then add the support for switchyard.xml.

                              • 12. Re: Use Guvnor NG as a Service Repository to manage SOA services
                                jervisliu

                                Currently creating a deployment package is a rules specific feature. It would be great if Guvnor could package services, but it is not surprizing this does not work now, as creating a rules package is not like creating a jar or war.

                                 

                                What I was hoping for at the moment is the ability to just grab a zip of all the artifacts in the package.  Eventually, I would expect there to be more involved - e.g. producing a deployable application out of Guvnor.

                                This is the job of Module builder (see http://community.jboss.org/wiki/GuvnorRepositoryStructure)

                                 

                                Module Builder: 
                                Module builder is a plugable mechanism that knows how to build a module for a specific domain (Drools/Jboss ESB etc). The builder knows how to validate, how to combine and assembly assets, how to generate the deployment unit (jar/war etc) for the target domain.

                                 

                                In Guvnor NG for Drools, we do have a PackageBuilder which knows how to assembly various rule assets, compile them, then produce a Drools package binary. Similar thing can be done if we write a SOAServiceModuleBuilder.

                                • 13. Re: Use Guvnor NG as a Service Repository to manage SOA services
                                  kcbabo

                                  Splitting BPEL and BPMN process would make sense, since BPMN processes have their own editor, and BPEL processes don't.

                                   

                                  It's not clear you would want to add rule and bpmn2 artifacts to your service directly. More likely you would create these in rule packages, and in your service create a ChangeSet.xml file that referenced the rule package (or rule packages) that the service required (this assumes the rules and bpm components in switchyard can use the KnowledgeAgent).

                                   

                                  I think both options will definitely be used.  Going the changeset route allows the rules or bpmn2 artifacts to be managed independently from the service component in Guvnor.  Including the bpmn2 artifact directly in the service component (as we do today in SwitchYard) allows you to manage and deploy the bpmn2 and SwitchYard details in a single unit (vs. the rule agent pulling the bpmn2 artifact down from Guvnor at runtime).  I imagine that best practices will emerge as we use this more and the support within Guvnor evolves.

                                  Sure, the jboss-esb.xml file is only relevant for JBoss ESB. As you state, I would expect with Switchyard to check in the composite (switchyard.xml).

                                   

                                  In my mind, this really depends on what we're able to do within Guvnor and what our goals for a repository are.  My initial goal was to simply have a way to share artifacts between services.  From that standpoint, what's there today is very close to complete. :-)  I don't see a composite as something that's shared between applications (i.e. you would check it out independently and use it over and over again), but a way to describe what's in an application.  So if we get to the stage where you can assemble an application in Guvnor, then the composite would be something that would be managed as part of that process.  I would love to see this type of capability, where you can pick up individual service components and package them up in Guvnor into something that's deployable as a composite application.

                                  The intent for Java source would be if we wanted the Service Repository to be able to create deployment archives (i.e., your very last comment in your last post). SInce the deployment archives would contain class files, we would need a way to get them into the repository.

                                   

                                  OK, so just to confirm : I'm uploading class files or JARs here and not Java source?

                                  The purpose of the Global Area with rules was to have a place that all packages could reference. The original need was around uploaded model files. It would be quite common for many different packages to want to use some or all of the same Java fact model. Without the Global Area, you would have to upload the model jar multiple times, once into each rule package. If you make a change to the Java classes in model jar, you would then have to re-upload it into every package. If you had lots of packages, this could get tedious. In a service repository you might have a similar requirement.

                                  Absolutely.  I definitely see the same requirement.  I guess my only question is whether we need a single 'global' area or if we can have multiple top-level shared areas.  Not sure if this gets messy, but I think a single global area has it's own set of issues.  For example, what is the criteria for name uniqueness in the global area?  If two groups use the same repository and they each have a schema named person.xsd that's different, can I have two different person.xsd instances in the global area that are managed separately?

                                  I think the use of a "package" = "service" is a result of using a rule repository for services. I would hope / expect this term to go away when using Guvnor to manage services, and this current cut is  an intermediate step to an eventual sevice repository. What is important is the idea that there is some organizational unit (or multiple organizational units) for users to organize their artifacts, such as "services", or "service compositions", or "business processes", or perhaps some user-defined term.

                                   

                                  Sounds good.  Not sure if I made this clear earlier, but I think what's been done with Guvnor so far is very impressive.  I realize it's a work in progress and these are early days, but I'm all excited now and can't hold back on the feedback.

                                  • 14. Re: Use Guvnor NG as a Service Repository to manage SOA services
                                    kcbabo

                                    Thanks for the background, Jervis.  This helps quite a bit.

                                    Jervis Liu wrote:

                                     

                                    We are currently working on a Guvnor NG 0.1 release. What is Guvnor NG: A generic service repository or service governance tool. Can be extended and customized, eg Guvnor NG for Drools and Guvnor NG for SOA etc.

                                     

                                    The goal of Guvnor NG 0.1 release is to split Guvnor to Guvnor Core, Guvnor Drools and Guvnor SOA. Guvnor Core module is a stripped down core, which contains codes that are generic to a generic service repository. Then we have Guvnor for Drools and Guvnor for SOA, they inherit Guvnor Core and produce a compiled version of Guvnor with their components. Once this is done, you wont see perspective for Drools (author perspective as it is called currently in Guvnor) and perspective for SOA anymore. Instead we have two different products: Guvnor NG for Drools and Guvnor NG for SOA.

                                    1 2 Previous Next