This document outlines a potential design of what Gunvor - SOA Repository may look like.
Please refer to http://www.jboss.org/community/docs/DOC-9834
2. JCR Schema
-- content: empty
-- content_binary: the AirlineReservationService.esb jar file is stored here in binary format
-- DefaultLifeCycle: created
-- dependency (multi-value-property)
--/ROOT/REPOSITORY_AREA/Drools/rules.properties (refer to rule1 and rule2)
-- other metadata related properties
-- isGlobal: set this property to false if this file does not need to be viewed outside AirlineReservationService
--other metadata related properties: such as serviceCategory name, mep etc
NOTE: AirlineReservationService is a leaf node. Under the AirlineReservationService node, its dependencies are stored using metadata_type_dependency property, which are references to other artifact nodes.
This is different from the schema that is used by Drools Gunvor:
3. Typical Use Cases:
3.1: Connect to a Repository
The SOA Repository is a web based application, can be accessed through browsers.
Connect to a repository:
1. Open a browser, point it to the URL of SOA repository. For example, http://soarepo.jboss.org/repo
2. Select a workspace: A list of available workspaces is displayed. Select one workspace. A workspace is an independent domain in the repository. For example, changing the content in workspace A wont have any effect on workspace B.
3. Log in with user name and password
3.2: Work With Workspace
The SOA Repository consists of three views: The workspace view, the Administration view and the Account management view.
Artifacts stored in a SOA Repository workspace are organized under different categories. We may support following categories (initially): JBOSS ESB (binary format only), Drools rules, WSDL, Schema, Document.
NOTE: The diagram showed above is actually same with the diagram below (except: 1. all artifacts are under the "global" container by default. 2. As everything are under the global container, to make things look more organized, we put things under different categories, i.e., JBOSS ESB, Drools, WSDL, Schema etc)
Type = Service
Service Type: Orchestrated, Entity, Task, Utility
Service Category: user defined
Additional Archive Artififacts
Additional Non-archive Artifacts
service candidate model
Type = Business Process
Endpoint Behavioral Descriptions
Type = JMS Destinations
Type = Policy
3.3: Create a JBOSS ESB Artifact
A JBOSS ESB artifact is a .esb bundle file associated with several metadata. When adding a JBOSS ESB artifact, you will be asked for the location of ESB file (zip file) and the version label. During the uploading process, the jboss-esb.xml file is extracted from the zip file, a set of metadata is generated and stored automatically according to the information from jboss-esb.xml, such as service category name, actions etc.
Create a JBOSS ESB Artifact:
3.4: View and Edit a JBOSS ESB Artifact
We have a ESB editor to view and edit JBOSS ESB artifact (.esb file).
View and Edit a JBOSS ESB Artifact
1. View the esb file: click the view button, you can download the esb file and save it as a local copy.
2. Manage the life cycle: You can choose a different life cycle type. You can also move the lifecycle phase forward or backward.
3. JBOSS ESB Configuration file: When a .esb bundle gets uploaded into the SOA repository, the jboss-esb.xml file will be extracted from the zip file, a set of metadata is generated and stored automatically according to the information from jboss-esb.xml.
4. Manage metadata: All metadata belongs to Quickstart_helloworld is displayed under the metadata section. User can add or remove a metadata type. Use can also edit the value of existing meta data.
5. Add a new version of .esb file: .esb bundle file is stored in SOA repository as a binary file. User can upload a new version of Quickstart_helloworld.esb file.
3.5: Work With Drools Artifact
3.6: Work With Life Cycle
You can define your own life cycle type from the administration menu.
3.7: Work With Metadata
You can define your own metadata from the administration menu. At the moment, we support four types of metadata: single-valued string, multi-valued string, life cycle, dependency.
1. Policy related:
* policy editor: the formats of policies vary a lot. how can we have a policy editor to suit all?
* shall we have a category called policies?