1 2 Previous Next 18 Replies Latest reply on Oct 19, 2011 2:42 AM by jervisliu Go to original post
      • 15. Re: Use Guvnor NG as a Service Repository to manage SOA services
        kcbabo

        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.

         

        I'm all for users deciding which way works best for them, but I think there are some higher level questions to ask as well.  I believe that we should have a conceptual framework in place for how users make the most of this repository functionality, from design, to service definition, to assembly, to deployment, to runtime management.  I'm not saying all that support has to be in from day 1, but it does have an impact on what type of artifact types are supported.  In my mind, we shouldn't just treat the repository as a version control system.  Plenty of those already.  Each artifact you place in the repository should have a purpose that extends beyond simply having a versionable copy of a file.

         

        Using the example of an application descriptor.  At what stage is this used?  Does the user/developer check this out into their Eclipse workspace and add it to a project?  Does Guvnor support building an application directly as part of the packaging process?  I'm not asking you to answer these questions, just pointing out an example of additional considerations beyond storing the file in the repository.

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

          I agree. The use of "Statuses" to defined a service development life-cycle is an example of a conceptural framework for how to use the repository. Defining "modules" to be "services" and/or "business processes" and/or "service compositions" is also part of this conceptual framework. As you say, there are plenty of generic version control systems. We want to have a generic underlying capability, but we want an out-of-the-box experience that is satisfying to business analysts and service developers (much like Drools Guvnor is today for business analysts and rule authors).

           

          Sharing information (files) between services is just one goal of a Servic Repository. Managing the llifecycle governance of services is equally important. Having a single "discoverable" source of service definition is important if services are to be reusable. Being able to understand a services interface / contract/ SLAs, etc. i

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

             

            I agree. The use of "Statuses" to defined a service development life-cycle is an example of a conceptural framework for how to use the repository. Defining "modules" to be "services" and/or "business processes" and/or "service compositions" is also part of this conceptual framework. As you say, there are plenty of generic version control systems. We want to have a generic underlying capability, but we want an out-of-the-box experience that is satisfying to business analysts and service developers (much like Drools Guvnor is today for business analysts and rule authors).

            I agree too. So what we need to figure out here is a default configuration of Guvnor NG for SOA which provides a good out-of-box experiences for most SOA developers.

             

            At the same time, this out-of-box default configuration should provide a guideline or best practices to guide users on using Guvnor for SOA to govern their services.

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

              Sharing information (files) between services is just one goal of a Servic Repository.

               

              Managing the llifecycle governance of services is equally important.

               

              Better lifecycyle manangement, this is definitely one topic we need to discuss. For the time being, if you'v had any concrete requirement, you can add them to https://issues.jboss.org/browse/GUVNOR-1710.

               

               

              Having a single "discoverable" source of service definition is important if services are to be reusable. Being able to understand a services interface / contract/ SLAs, etc. i

              This could be the feature you are talking about? https://issues.jboss.org/browse/GUVNOR-1170. With the ability of custom metadata management, users can search/tag/manage service artifacts based on user defined metadata or metadata extraced from service contract/SLAs. Guvnor can extract metadata automatically when adding new artifacts to its repository.

              1 2 Previous Next