his wiki will walk through scenarios that are supposed to be supported by SOA Repository to validate whether or not the backend SOA Repository API meets the requirement. The mocked screens below are NOT suggested design for the UI, they are only used to give you an idea of what the backend API is capable of.
TASK 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
A HTTP GET request to URI http://soarepo.jboss.org/repo/workspaces returns a list of work spaces in AtomPub format
TO BE DISCUSSED:
We need to discuss whether or not we need the notion of workspace.
TASK 2: Work With Workspace
The SOA Repository consists of three views: The workspace view, the Administration view and the Accout management view.
Artifacts stored in a SOA Repository workspace are organized under different categories. We may support following categories (initially): JBOSS ESB, Drools, JBPM, Web services, Smooks, Document.
Work With Workspace:
1. Click the Quickstart_helloworld under “JBOSS ESB” category to view artifact Quickstart_helloworld.
TO BE DISCUSSED:
1. Some ppl may want to organise their artifacts per business cases or locales, in this case, customizable views is the answer: think of symbolic links in unix that allow you to form a view on a set of artifacts across various directories.
2. Each known service category type will have a corresponding editor panel. For example, ESB editor panel, WSDL editor panel.
3. A corresponding JCR schema may look like below:
-- Airline Booking
-jcr:content: this node has following properties:lastModified, desc, metadata related properties, content(empty), srcLink. srcLink includes: /rootnode/services/ESBBinaries/airlinebooking.esb, /rootnode/services/WSDL/Public.wsdl, /rootnode/services/Drools/rules.properties (refer to rule1 and rule2), /rootnode/services/Document/FlightMessage.xsd, /rootnode/services/Document/PassengerListMessage.xsd, /rootnode/services/JBPM/Notification.bpmn, /rootnode/services/Document/ServiceDocument.doc
-- Jervis1 (which contains Public.wsdl)
-jcr:content: this node only has one property:CONTENT_PROPERTY_BINARY_NAME
-jcr:content: this node has following properties: metadata_type, description,
-jcr:content: this node has following properties: isInitialPhase, description,nextPhase
This is different from the schema that is used by current Drools Gunvor:
4. If we follow the file browser like approach, we need to make sure it is easy to extend by design. So for example, out-of-box SOA Repo may only support ESB, Drools, WSDL types. By providing a proper extension mechanism, users can add their own type say, BPEL very easily. Ideally the user will develop certain implementions which will include 1. the GWT editor for viewing and editing BPEL service artifact 2. JCR schema for storing BPEL artifact 3. Necessary JAVA classes that implement certain interfaces (such as java classes to access BPEL through AtomPub), then they bundle everything together in a jar file, drop the jar onto the classpath of SOA Repo. A new service category type called "bpel" will appear in the GUI automatically.
TASK 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:
public Response addArtifactAsEntryMediaType(InputStream is, @Context UriInfo uParam)
Also see test testAddAndUpdateESBJar() from: http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-atom/src/test/java/org/drools/atom/ClientServerAtomRulesRepositoryTest.java
TO BE DISCUSSED:
1. There are two ways to add a JBOSS ESB artifact into the repository. One is as showed above, by uploading a binary bundle. The problem with this approach is that all the components such as WSDL, Drools rule files, smooks etc are hard copies, which means these components are not managed by SOA Repository. Another way is having a ESB assembly editor, so that we can build a new ESB by draging and droping various service components (artifacts) from the SOA Repository to assembly an ESB service. Once the assembly is done, we can hava a button to generate a deployment bundle (.esb file).
TASK 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.
public Entry getArtifactAsEntry(@PathParam("artifactName") String artifactName,
@Context UriInfo uParam)
public Response updateArtifactAsEntry(Entry e, @Context UriInfo uParam)
public InputStream getArtifactAsEntryMediaType(@PathParam("esbName") String esbName, @Context UriInfo uParam)
Also see test testAddAndUpdateESBJar(), testAddAndUpdateArtifact(), from: http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-atom/src/test/java/org/drools/atom/ClientServerAtomRulesRepositoryTest.java
TO BE DISCUSSED:
1. If the .esb contains sub-components like WSDL, Drools, Smooks etc, we will have extra sections on ESB editor panel to display related information. But these information will be readonly, as you can not change the binary .esb file anyway.
2. If ESB is not stored as a binary file, instead it is created by the esb assembly editor, then we will be able to reuse service artifacts across services. So for example when you click the public.wsdl under "Aireline booking" service, the focus will move to the public.wsdl under WSDL category and a WSDL editor panel will be displayed.
TASK 5: Work With Drools Artifact
TASK 6: Work With Life Cycle
You can define your own life cycle type from the administration menu.
public Feed getMetadataTypesAsFeed(@Context UriInfo uParam)
public Response addMetaDataTypeAsEntry(Entry e, @Context UriInfo uParam)
public Response deleteMetaDataType(@PathParam("metadataname") String metaDataName)
Also see test testGetMetaDataTypes(), testAddAndDeleteMetaDataTypes() from: http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-atom/src/test/java/org/drools/atom/ClientServerAtomRulesRepositoryTest.java
TASK 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 format of policies vary a lot. how can we have a policy editor to suit all?
* shall we have a category called policies?