Hi Jeff

Good work - I'll try to find some time to try it out myself, but just a couple of comments.

Some of the stored items are artifacts, while others are deployable units (jar, esb, etc). At the moment there does not appear to be any way of linking the source artifacts with the deployment unit - or is it possible to somehow identify dependencies?

This also leads to the question of how we would build those components, and understand which versions of the various artifacts were used to build them. If such a build system was possible, this could automatically establish the dependencies with the generated deployment unit, making it possible to understand when changes to various artifacts would impact deployed services.

Are there any ideas of how these deployment units, that are in the status 'Deployed', will relate to actual deployment in a test or production environment? And equallty how do we then define when an updated deployment unit should be deployed - i.e. is there a concept of a subsequent version of deployment unit X.esb, being in a different status (i.e. PreDeploy)?

To avoid confusion, possibly a concrete example would be useful.

1) We have 'PolicyQuoteService.esb' in status 'Deployed', currently running on the SOA platform. This is based on (for simplicity) a single jboss-esb.xml file, with no other artifacts. So there will be a dependency relationship between the .esb file and the jboss-esb.xml.

2) We then decide that we want to update the service, so some changes are made to the jboss-esb.xml file and these added to Guvnor as a new version of the file.

3) A build mechanism is then invoked that understands that the .esb file packages the jboss-esb.xml - and the result of this is a new version of PolicyQuoteService.esb, but in a status 'PreDeployed'. So one point is whether the status is associated with the file, or with the specific version of the file?

4) This deployment unit could then possibly be moved to status 'Test', where it could be deployed to a test environment automatically - along with any other deployment units that it is dependent upon - or changed to status 'Deploy' to deploy in the production environment, possibly subject to suitable authorisation.

Sorry, this reply has got rather involved, and I know that some of this would not be possible now - but just wondering whether this is a use-case we want to explore, and how much of it may be possible with Guvnor now.

Regards

Gary

Jeff,  I really like how you were able to repurpose Guvnor for SOA artifacts without modifying the code.  Neat hack!

objectiser wrote:

 

Some of the stored items are artifacts, while others are deployable units (jar, esb, etc). At the moment there does not appear to be any way of linking the source artifacts with the deployment unit - or is it possible to somehow identify dependencies?

I think that would be relatively straightforward with a ModeShape sequencer if ModeShape was used as the JCR implementation under Guvnor.  There is already a sequencer that can explode a .zip file (or a .jar or .esb, for that matter). 

This also leads to the question of how we would build those components, and understand which versions of the various artifacts were used to build them. If such a build system was possible, this could automatically establish the dependencies with the generated deployment unit, making it possible to understand when changes to various artifacts would impact deployed services.

Would the intent be to build and deploy from the repository, or to build on some other environment, upload the build artifact (e.g., ESB archive) to the repository, and then let the repository decompose the build artifact into its constituent artifacts for searching and analysis?

Are there any ideas of how these deployment units, that are in the status 'Deployed', will relate to actual deployment in a test or production environment? And equallty how do we then define when an updated deployment unit should be deployed - i.e. is there a concept of a subsequent version of deployment unit X.esb, being in a different status (i.e. PreDeploy)?

Great question.  Are people (internal to JBoss) expecting services to be published directly from the repository or through JON?  My supposition is that customers would not punch a hole through their firewall to allow a service repo to push deployment units to prod servers. 

3) A build mechanism is then invoked that understands that the .esb file packages the jboss-esb.xml - and the result of this is a new version of PolicyQuoteService.esb, but in a status 'PreDeployed'. So one point is whether the status is associated with the file, or with the specific version of the file?

I think that tracking the deployment footprint of services across environments is important and it would have to be done on a per-version basis.  For example, FooService 1.0 may be in production while FooService 1.1 is in integration testing and FooService 2.0 is being developed.

bcarothers wrote:

 

Would the intent be to build and deploy from the repository, or to build on some other environment, upload the build artifact (e.g., ESB archive) to the repository, and then let the repository decompose the build artifact into its constituent artifacts for searching and analysis?

 

Not sure - but one issue with the explode approach is whether it would successfully identify where those artifacts already exist in the repository, and setup dependencies on those existing artifacts+version.

Great question.  Are people (internal to JBoss) expecting services to be published directly from the repository or through JON?  My supposition is that customers would not punch a hole through their firewall to allow a service repo to push deployment units to prod servers. 

 

Good point - I guess we need to understand what is the relationship between Guvnor and a management system like JON needs to be. Moving a package into 'Deploy' or 'Test' state could just be used as a notification to the management system, to trigger the deployment process - whether automatically, or manually performed by an administrator.

I think that tracking the deployment footprint of services across environments is important and it would have to be done on a per-version basis.  For example, FooService 1.0 may be in production while FooService 1.1 is in integration testing and FooService 2.0 is being developed.

Yes I think so to - and one point this raises - if the Gurnor status field is going to be used for values such as 'Business Analysis', 'Service Oriented Analysis' etc - as well as potentially 'Integration Testing', 'Production' etc - then we will probably need some validation to only permit certain status values to be applied to certain artifact or package types.

objectiser wrote:

 

bcarothers wrote:

 

Would the intent be to build and deploy from the repository, or to build on some other environment, upload the build artifact (e.g., ESB archive) to the repository, and then let the repository decompose the build artifact into its constituent artifacts for searching and analysis?

 

 

Not sure - but one issue with the explode approach is whether it would successfully identify where those artifacts already exist in the repository, and setup dependencies on those existing artifacts+version.

 

I think that the repository could identify most of those dependencies.  It would also need some help from the metadata in the build artifact and, probably, some occasional manual input. 

As a concrete example, suppose that FooService.esb is uploaded to the repository and consists of a JAR that contains classes with JPA annotations, a JAR that contains classes with JSR-181 annotations (or JSR-311 or any other annotation to a loosely-coupled interface), and a jboss-esb.xml file.  I would expect some version of the following process to occur:

1. Explode - The repository could explode the archive and JARs into its internal storage

2. Analyze - The repository could then parse out the annotations from the classes.  In this example, that would imply the required database structure and enable generation of exposed WSDL for the services.  The repository could also parse the jboss-esb.xml file to determine any dependencies.  Ideally, the repository would also associate (or suggest associations for) any related design artifacts from a known document repository and tie the classes to source code in a source code repository.

3. Publish - The repository would then publish the service to its search index, allowing future services to dynamically identify dependencies on this service more easily.  (Yes, this is the hand-waving part, although I do have some ideas for how it could work).

What do you think about this process?

Good point - I guess we need to understand what is the relationship between Guvnor and a management system like JON needs to be.

IMHO, it would be nice if JON could pull deployment units from the repository and push them out to the live servers.  Customers seem to buy into that deployment model. 

Yes I think so to - and one point this raises - if the Gurnor status field is going to be used for values such as 'Business Analysis', 'Service Oriented Analysis' etc - as well as potentially 'Integration Testing', 'Production' etc - then we will probably need some validation to only permit certain status values to be applied to certain artifact or package types.

I agree.  I think Jervis's work on Guvnor-SOA has this concept of documentation artifact vs. deployable artifact.

Sorry Jeff, we were getting carried away. But having something concrete like you have produced makes it easier to brainstorm ideas

Regards

Gary