-
1. Re: SOA Repository (A prototype release) is available for re
Suggestions for Functionality
- Search - This is the most valuable use case for the service repository. You may want to replace the name search/full-text search with a single search box that checks both and ranks exact name matches above full-text matches. Users will likely expect an advanced search capability as well that lets them search by specific pieces of metadata.
- Services - The repository seems to treat services, documents, and configuration artifacts as first class citizens. I think that you should strongly consider organizing the repository around services that have associated artifacts and dependencies (which may be artifacts or other services). I don't know that you should even support uploading artifacts or documentation except within the context of a service.
- Configuration/Documentation - I haven't yet reviewed the entire codebase, but is there a reason that you treat documentation differently from configuration artifacts? Users will expect equivalent search support for both types of artifacts and some metadata tends to be fuzzy between documentation and configuration anyway (e.g., Erwin models that are used to generate DDL).
- SOA Network - I can't tell what this would do, but I am hoping that you can add servers here, have their services auto-discovered, tag them for their phase in the lifecycle (dev, test, uat, production, DR), and (potentially) deploy artifacts to them automatically some day.
- Administration - Metadata Types - I wouldn't worry about this part too much. Predefine some useful metadata types for v1 and postpone the complexity of user-defined metadata until a future version
- Administration - Lifecycles - This is a neat concept, but is less critical than getting service upload/organization/artifact upload/artifact search working.
- Hierarchy (Missing) - Speaking personally, I'd love it if the repository provided a way of organizing services into an arbitrary hierarchy (e.g., division -> department -> project -> service). This may be a v2 feature.
Suggestions for the Technical Approach
- GWT - I love the use of GWT. Absolutely fantastic. I can easily see how this could be as slick as the Guvnor BRMS piece when its done.
- JCR - I think JCR is the right approach, but you may want change your node types now to line up a little better with the JSR-283 node types. I've attached some re-worked CND files with comments. JackRabbit supports the -283 node types now and -283 will likely be finalized before the end of the year (it's in final draft now).
- ATOM/Pub - Seems to be a nice feature to have. I've spoken to some Directors of IT who have the JON deployment feed sent to their pagers so that they can tell when things are deployed.
And most importantly, please keep up the great work! -
2. Re: SOA Repository (A prototype release) is available for re
- Search - This is the most valuable use case for the service repository. You may want to replace the name search/full-text search with a single search box that checks both and ranks exact name matches above full-text matches.
This makes sense. I have created a jira for this: https://jira.jboss.org/jira/browse/GUVNORSOA-1. Full-text search can be much slower than a normal name search. If this is the case, we may add a "Enable full-text search" checkbox so that full-text search can become optional.
Users will likely expect an advanced search capability as well that lets them search by specific pieces of metadata.
https://jira.jboss.org/jira/browse/GUVNOR-187
- Services - The repository seems to treat services, documents, and configuration artifacts as first class citizens. I think that you should strongly consider organizing the repository around services that have associated artifacts and dependencies (which may be artifacts or other services).
Can you be more specific please? You can comment in this thread: http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155196
I don't know that you should even support uploading artifacts or documentation except within the context of a service.
So we need to discuss use cases on how ppl uses SOA Repository. One use case I have is users start to use SOA Repository by adding some individual components (artifacts) such as WSDL, documentation, configuration files etc. Then they assemble things together to create a service using the dependency link.
- Configuration/Documentation - I haven't yet reviewed the entire codebase, but is there a reason that you treat documentation differently from configuration artifacts? Users will expect equivalent search support for both types of artifacts and some metadata tends to be fuzzy between documentation and configuration anyway (e.g., Erwin models that are used to generate DDL).
Configuration and documentation are treated exaclty same in terms of how we can store them in JCR (well, the meta data auto-discovery part can be slightly different). I just thought having a documentation area makes it easier for users to organize their artifacts.
- SOA Network - I can't tell what this would do, but I am hoping that you can add servers here, have their services auto-discovered, tag them for their phase in the lifecycle (dev, test, uat, production, DR), and (potentially) deploy artifacts to them automatically some day.
- Administration - Metadata Types - I wouldn't worry about this part too much. Predefine some useful metadata types for v1 and postpone the complexity of user-defined metadata until a future version
- Administration - Lifecycles - This is a neat concept, but is less critical than getting service upload/organization/artifact upload/artifact search working.
- Hierarchy (Missing) - Speaking personally, I'd love it if the repository provided a way of organizing services into an arbitrary hierarchy (e.g., division -> department -> project -> service). This may be a v2 feature.
Looks like this is the feature we need very much (though its an advanced feature). If we have this feature, we wont need to worry about wether or not we want to have a "Documentation" section, as everything can be customed.
If we have this feature, Drools Guvnor(BRMS) can be migrated to use SOA Guvnor code base much more easily. Drools Guvnor is organizing its artifacts based on packages and categories.
Suggestions for the Technical Approach
- GWT - I love the use of GWT. Absolutely fantastic. I can easily see how this could be as slick as the Guvnor BRMS piece when its done.
- JCR - I think JCR is the right approach, but you may want change your node types now to line up a little better with the JSR-283 node types. I've attached some re-worked CND files with comments. JackRabbit supports the -283 node types now and -283 will likely be finalized before the end of the year (it's in final draft now).
https://jira.jboss.org/jira/browse/GUVNORSOA-2
- ATOM/Pub - Seems to be a nice feature to have. I've spoken to some Directors of IT who have the JON deployment feed sent to their pagers so that they can tell when things are deployed. -
3. Re: SOA Repository (A prototype release) is available for re
"bcarothers" wrote:
- SOA Network - I can't tell what this would do, but I am hoping that you can add servers here, have their services auto-discovered, tag them for their phase in the lifecycle (dev, test, uat, production, DR), and (potentially) deploy artifacts to them automatically some day.
I knew JON/Jopr can provide these functions : server auto-discovered, deploy these artifacts to a server. Can we reuse or integrate with Jon/Jopr? What the "reuse" here means simplifying and modifying the JON/Jopr server code and putting the server and service auto-discovered,deployment functions in the SOA Repository GWT console . And the another option "integrate" with Jon/Jopr is writing a Jon/Jopr SOA Repository plugin to connect to SOA repository , deploy and update the deployment lifecyle status for these artifacts in SOA Repository.
Compare to reusing and integration, I think the "integration" will be a little bit easy. But It really and heavily depends on Jon/Jopr to implement the service deployment. Can the SOA Repository console just provide the function to monitor (Read)the deployment service lifecylce phase status and let JON/Jopr do the deploy and update lifecyle status job? -
4. Re: SOA Repository (A prototype release) is available for re
Hello Jervisliu!
It's wonderful that you are working on the SOA governance tool. It is missing in our SOA infrastructure and we need it desperately. But I am totally confused about the cooperation between different JBoss projects.
In http://www.redbooks.ibm.com/redpieces/pdfs/redp4495.pdf following areas for SOA governance are defined:
* Service definition
* Service migration
* Service message model
* Service ownership
* Service testing
* Service registration
* Service versioning
* Service ownership
* Service funding
* Service monitoring
* Service auditing
* Service diagnostics
* Service identification
* Service modeling
* Service publishing
* Service discovery
* Service development
* Service consumption
* Service provisioning
* Access to services
* Deployment of services and composite applications
* Security for services
Other sources provide similar lists. As SOA is a very overloaded term spanning business, modeling, design, implementation, management and monitoring layers, we must append to this list handling of all possible types of assets used by services.
From your post http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155201 I see, that you have assumed certain priorities to provide some of the needed features. But notwithstanding the current situation other tasks will have to be supported (sooner or later) too. So what we need now is to have a sound architecture making future extensions easy. And I thought we have a splendid base for it. In drools-guvnor we have the concept of an asset. Unfortunately the list of assets is fixed. But the code for it in org.drools.guvnor.client.ruleeditor.EditorLauncher is just begging to make it configurable. What is needed is just to provide a feature of asset definition and a possibility to define plugins for asset editor, asset viewer or invoking external tools for asset processing. And a sample how to use asset widgets is available at:
http://blog.athico.com/2008/07/integrating-rolodex-to-guvnor-for-image.html. In addition in the post http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150144 I read that Mike Brock is working on the Guvnor plugability. So you should get such pluggable architecture from him. But from your code it doesn't seem to be the case. So what is the situation? Without such more flexible approach we will quickly run into troubles.
The most versatile approach would be to use the ontology approach. SOA governance tool will have to maintain also the ontology assets anyway. Using it we could define assets ontology and derive from it asset configurations for Guvnor (OWL->SPARQL->XSLT->AssetConfig).
Another subject is DNA. It is sequencing and storing assets in a repository. And we would like also to show these assets in the SOA governance tool. Do you cooperate with DNA team to use what they have produced?
Wieslaw -
5. Re: SOA Repository (A prototype release) is available for re
From your post http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155201 I see, that you have assumed certain priorities to provide some of the needed features. But notwithstanding the current situation other tasks will have to be supported (sooner or later) too. So what we need now is to have a sound architecture making future extensions easy. And I thought we have a splendid base for it. In drools-guvnor we have the concept of an asset. Unfortunately the list of assets is fixed. But the code for it in org.drools.guvnor.client.ruleeditor.EditorLauncher is just begging to make it configurable. What is needed is just to provide a feature of asset definition and a possibility to define plugins for asset editor, asset viewer or invoking external tools for asset processing. And a sample how to use asset widgets is available at:
http://blog.athico.com/2008/07/integrating-rolodex-to-guvnor-for-image.html. In addition in the post http://www.jboss.org/index.html?module=bb&op=viewtopic&t=150144 I read that Mike Brock is working on the Guvnor plugability. So you should get such pluggable architecture from him. But from your code it doesn't seem to be the case. So what is the situation? Without such more flexible approach we will quickly run into troubles.
Hi Wieslaw, sorry for the late response. I agree with you totally that we need a plugable architecture so that SOA Repo can always be extended to support new artifact types. Ideally we would like to be able to add new extensions by just droping a jar into SOA Repo's classpath. As far as the current code base is concerned, yes, you were right, I wrote these codes without putting plugability into consideration. Well, I am kind of following the XP approach - "Leave optimization till last" ;-) We will see if we can push the plugability as one of the must-have features for the version one release of SOA Repo.
Another subject is DNA. It is sequencing and storing assets in a repository. And we would like also to show these assets in the SOA governance tool. Do you cooperate with DNA team to use what they have produced?
Have not talked to DNA team yet but I will check this out.
Cheers,
Jervis