Version 26

    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

     

    Overview:

    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.

    selectworkspace.JPG

     

    3.  Log in with user name and password

     

    Supporting API:

    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

     

    Overview:

    The SOA Repository consists of three views: The workspace view, the Administration view and the Accout management view.

    workspace1.JPG

     

    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.

     

    Supporting API:

     

    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:

    -rootnode

       -services
           -JBOSS ESB
               -- 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
            -Web services
               -- Jervis1 (which contains Public.wsdl)
            -Drools

               -- rule1
               -- rule2
            -JBPM

               -- Notification.bpmn
            -BPEL
            -Documents
               -- ServiceDocument.doc
            -Schemas
               -- FlightMessage.xsd
               -- PassengerListMessage.xsd
            -ESB binaries
               -- airlinebooking.esb

                        -jcr:content: this node only has one property:CONTENT_PROPERTY_BINARY_NAME

       -schemas

                -metadata_names
                            -metadata_type_string
                                             -jcr:content: this node has following properties: metadata_type, description,
                            -metadata_type_multi_value_string                         
                            -metadata_type_life_cycle
                            -metadata_type_link
                -life_cycles
                            -default_life_cycle
                                                     -created
                                                                -jcr:content: this node has following properties: isInitialPhase, description,nextPhase
                                                     -developed
                                                     -tested
                                                     -production
                                                     -retired

     

    This is different from the schema that is used by current Drools Gunvor:

    rootnode-
              -RULES_REPOSITORY_NAME
                                        -RULE_PACKAGE_AREA
                                                                      -packageA
                                                                                     -ASSET_FOLDER_NAME
                                                                                                          -assetA
                                                                                                          -assetB
                                                                      -packageB
                                                                                     -ASSET_FOLDER_NAME
                                        -STATE_AREA
                                        -PACKAGE_SNAPSHOT_AREA

     

    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
    Overview:

    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:
    addesb.JPG
    Supporting API:

     

     

    @POST

    @Path("/esbs")

    @Consumes("application/esb")

    @Produces({"application/atom+xml"})

    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

     

    Overview:

    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.

    workspace1.JPG

     

    Supporting API:

    @GET

    @Path("/artifacts/{artifactName}")

    @Produces({"application/atom+xml"})

    public Entry getArtifactAsEntry(@PathParam("artifactName") String artifactName,

    @Context UriInfo uParam)

     

    @PUT

    @Path("/artifacts")

    @Consumes("application/atom+xml")

    @Produces({"application/atom+xml"})

    public Response updateArtifactAsEntry(Entry e, @Context UriInfo uParam)

     

    @GET

    @Path("/esbs/{esbName}")

    @Produces({"application/esb"})

    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

     

    TBD

     

     

    TASK 6: Work With Life Cycle

     

    Overview:

    You can define your own life cycle type from the administration menu.

    lifecycle.JPG

    Supporting API:

     

    @GET

    @Path("/metadatatypes")

    @Produces({"application/atom+xml" })

    public Feed getMetadataTypesAsFeed(@Context UriInfo uParam)

     

     

    @POST

    @Path("/metadatatypes")

    @Consumes("application/atom+xml")

    @Produces({"application/atom+xml"})

    public Response addMetaDataTypeAsEntry(Entry e, @Context UriInfo uParam)

     

     

    @DELETE

    @Path("/metadatatypes/{metadataname}/")

    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

     

    Overview:

    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.

     

    metadata.JPG

     

    TO-DO:

     

    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?

     

    2. Search/Query