7 Replies Latest reply: Jul 6, 2009 12:16 AM by Jervis Liu RSS

Governance process support in Service Repository

Jeff DeLong Master

I started this thread to discuss the requirements to support a standard and / or user defined governance process within service repository. For example, we have defined such a process within GPS, consisting of the following phases:

Business Analysis
Service-Oriented Analysis
Service-Oriented Design
Service Development
Service Testing
Service Deployment

This would be an example of an out-of-the-box governance process. Each phase in the process would have a set of criteria that needed to be satisfied, which might include the creation of various artifacts.

  • 1. Re: Governance process support in Service Repository
    Gary Brown Master

    I have been looking at the various documents related to Guvnor (and more specifically SOA-Guvnor) and would also be interested in exploring some real world use cases.

    I have seen discussion of a 'lifecycle' property (included in the soa-guvnor demo), that could potentially be used to define the various phases you mention, and also that a workflow could be used to control the authorisation/governance procedure for moving between the phases - so to ensure that all the artifacts have been defined and are valid.

    However if the lifecycle is defined in a JCR property associated with the artifact, or a grouping artifact, is it possible to make this a read only property? So that the user would request that the artifact (or group of artifacts) move to the next phase (through some external command), but are not actually allowed to change the lifecycle property themselves? i.e. this needs to be done through an administrative workflow.

    From the JCR spec, it appears that this can only be done if the user has no permission to set properties - so this would mean they could not change any property values - would this be a problem?

    My other question is on how the lifecycle concept will work when dealing with versions of a system. By version I don't mean the JCR versioning concept, that maintains a version history of changes per artifact, but more the user defined version that will be applied to the system and individual services being deployed.

    It may be the case that different versions of a service are at different points in the lifecycle - i.e. version 1.1 is in production, version 1.2 is in QA while version 1,3 is in development.

    How would the repository be organised to take into account these three versions? Would workspaces be used?

    What implication does this have on defining dependencies between services - if the dependency is between 'service' grouping artifacts, based on id, then if I understand JCR correctly, it is possible to use the common id for the 'service' grouping artifact across workspaces???

    It would be useful having some usecases that describe how an organisation would develop and deploy one or more systems, with shared services, where those services are going through their independent lifecycles, but define dependencies that need to be understood/managed/validated.

    Sorry for the long reply.

  • 2. Re: Governance process support in Service Repository
    Jervis Liu Apprentice

     

    "objectiser" wrote:
    I have been looking at the various documents related to Guvnor (and more specifically SOA-Guvnor) and would also be interested in exploring some real world use cases.

    I have seen discussion of a 'lifecycle' property (included in the soa-guvnor demo), that could potentially be used to define the various phases you mention, and also that a workflow could be used to control the authorisation/governance procedure for moving between the phases - so to ensure that all the artifacts have been defined and are valid.

    However if the lifecycle is defined in a JCR property associated with the artifact, or a grouping artifact, is it possible to make this a read only property? So that the user would request that the artifact (or group of artifacts) move to the next phase (through some external command), but are not actually allowed to change the lifecycle property themselves? i.e. this needs to be done through an administrative workflow.

    From the JCR spec, it appears that this can only be done if the user has no permission to set properties - so this would mean they could not change any property values - would this be a problem?


    This area can be handled by role-based-authorization, similar to what Drools-Guvnor has done [1]. As we've had JBOSS Identity framework, its likely that the implementation of SOA Repository role-based-authorization will be based on JBOSS Identity framework. If the role-based-authorization is implemented properly, it shall have no problem to grant authorization on the method and object level, i.e., who can use what method to access what object. For example, we can say only admin user can update(Write) service AirlineBookingService. Only users from deparment A can read service AirlineBookingService but not write or delete. But I am not sure if the role-based-authorization implementation is sophisticated enought to grant authorization on a level lower than object, i.e., who can access what properties of an object. Well, if it cant, there is a workaround: we can create specific method called updateLifecycle(String artifactPath, Lifecycle lc). This method can be anotated to only allow certain type of users to invoke.

    [1]. https://jira.jboss.org/jira/browse/JBRULES-1018

    "objectiser" wrote:

    My other question is on how the lifecycle concept will work when dealing with versions of a system. By version I don't mean the JCR versioning concept, that maintains a version history of changes per artifact, but more the user defined version that will be applied to the system and individual services being deployed.

    It may be the case that different versions of a service are at different points in the lifecycle - i.e. version 1.1 is in production, version 1.2 is in QA while version 1,3 is in development.

    How would the repository be organised to take into account these three versions? Would workspaces be used?

    The service editor for service or artifact has a section called History. This section show all history versions of that service/artifact as below:

    Version Link CheckInComment ChangeLog
    1.3 http://localhost/repo/esb/myservice?version=1.3 changed port name ...

    click the link will bring up another service editor which is for that specific version (it will be read only though).

    "objectiser" wrote:

    What implication does this have on defining dependencies between services - if the dependency is between 'service' grouping artifacts, based on id, then if I understand JCR correctly, it is possible to use the common id for the 'service' grouping artifact across workspaces???

    The current code base is using artifact path to uniquely identifyan artifact within JCR repo, i.e., sth like /repo/services/esb/test.esb. Our implementation will make sure the artifact path is unique.

    "objectiser" wrote:

    It would be useful having some usecases that describe how an organisation would develop and deploy one or more systems, with shared services, where those services are going through their independent lifecycles, but define dependencies that need to be understood/managed/validated.

    Sorry for the long reply.



  • 3. Re: Governance process support in Service Repository
    Gary Brown Master

    I don't think the history approach would solve this usecase - as if a service in test could no longer be edited (i.e. it is read only), then it could not be moved in to production.

    So it looks like it would be necessary to move a service through its complete lifecycle before being able to return it to 'development' phase for further work. But this introduces the problem, if you are querying the repository for services in production, then a service that has had its lifecycle moved back to 'development' would not be picked up.

    Or is this where the SOA Network could be used? So if a server has been defined in the SOA Network, and perhaps for a Service to enter production, it needs to be associated with a server, and its the association with a server that indicates it is "deployed". The link between the server and the service could be specific to a version, so even though the service is then updated to return it to 'development' phase, the server would be unaffected.

    The same approach could be used when entering a 'test' phase - the service could be associated with a test server.

    Which introduces another question - based on previous posts, it appears deploy/undeploy is not going to be a function of the repository, even though publishing a WSDL to UDDI may be - this seems to be a bit of a conflict, as publishing a WSDL URL to UDDI would seem to be dependent on the service also being deployed.

    I like the idea of parts of the SOA Network being associated with different phases of the lifecycle, as it would help to automate the process from the user's perspective - rather than them having to know which parts of the SOA Network were ok to use for services in different phases - otherwise there is room for mistakes.

  • 4. Re: Governance process support in Service Repository
    Jeff DeLong Master

     

    Which introduces another question - based on previous posts, it appears deploy/undeploy is not going to be a function of the repository, even though publishing a WSDL to UDDI may be - this seems to be a bit of a conflict, as publishing a WSDL URL to UDDI would seem to be dependent on the service also being deployed.


    True, but publishing a wsdl location to a registry is a standardized and fairly easy thing to do though software, whereas creating a deployable service is not standardized (e.g. a JBossESB services is not packaged the same as a JBossWS Web service), and requires compiling source code, etc. So while this might be a nice to have feature, it might be difficult to implement short term.



  • 5. Re: Governance process support in Service Repository
    Gary Brown Master

    Although as discussed in a recent post, it might be possible to build the deployment unit in an IDE, and then upload that to the repository.

    So possibly (in the case of JBossESB), the condition for moving from development to test, is that a .esb has been uploaded. When it moves into test, the ,esb could be auto deployed to the associated test server(s) in the SOA Network (associated with the test phase), along with the WSDL being published. Same for production phase.

    However it is not ideal - because how do we know that the .esb incorporates the same artifacts associated as dependencies on the service in the repository.

    The other approach is that the SOA Repository shouldn't support any deployment capabilities - even publishing WSDL to UDDI. Maybe an external solution should do these tasks, being triggered by the change in lifecycle of the service.

    In which case, is there a purpose for the SOA Network?

    How do other repository products deal with these issues?

  • 6. Re: Governance process support in Service Repository
    Jeff DeLong Master

    The more tasks we can automate the better for the user. So publishing the WSDL location but not deploying the service implementation is still better than not doing either.

    We have to remember that not all services in the repository are .esb archives. They could also be wars deployed into JBosssWS, or even services developed and deployed in a Microsoft .NET environment.

    At least one of the repository products out there publishes the WSDL location but does not attempt to package of deploy service implementation units.

  • 7. Re: Governance process support in Service Repository
    Jervis Liu Apprentice


    "objectiser" wrote:

    How do other repository products deal with these issues?


    Most repository products out there have some sort of intergations with their own runtime servers so that they can do a deploymen/undeployment during runtime from repository.