JBoss Overlord: S-RAMP Milestone 2 (screencast)

Version 1

    Hey everyone.  Today we release Milestone 2 of the JBoss Overlord S-RAMP project.  This include the core repostory and a simple web based UI to browse it.  To go along with this release, I put together a screencast for your viewing pleasure.  Also, see the transcript of the screencast below, in case you prefer reading.

     

    Screencast:  https://vimeo.com/50627742

     

    Transcript

     

    Greeting

    Welcome to the JBoss Overlord S-RAMP Milestone 2 webcast.

     

     

    S-RAMP is an emerging OASIS standard for a Service Oriented Architecture repository (and accompanying protocol for accessing that repository).


     

    JBoss Overlord has chosen S-RAMP as the core repository around which SOA Governance functionality is being built.


     

    Milestone 2 of the JBoss Overlord S-RAMP project supports some of the core S-RAMP repository functionality as well as integration with the Maven build automation framework.


     

    This webcast will show off some of these features, demonstrating them using a variant of the JBoss Switchyard multiApp demo.


     

    About the Demo

    Switchyard comes with a quickstart demo called multiApp, which is designed to show how an application might be divided up into multiple components.  One of the components in the demo is the ‘artifacts’ JAR, which contains some Java code along with a WSDL and an XML Schema.


     

    This webcast demonstrates how to use Maven to deploy the ‘artifacts’ JAR into the S-RAMP repository.  Once that JAR is deployed, it can be used as a dependency in other projects.


     

    Do The Demo

    Now - on to the demo!  We’ll be using the following technologies for this webcast:

     

    • JBoss 7.1.1 Final on Java 6
    • Maven 3, specifically 3.0.4
    • Eclipse Juno
    • S-RAMP Milestone 2
    • S-RAMP User Interface Milestone 2

     

    For the sake of a shorter webcast, we’ve already installed everything, so let’s take a look at what we have.

     

     

    First we need to start up JBoss 7, which already has the two S-RAMP project WARs deployed.

     

     

    Using a web browser, we can navigate to the S-RAMP User Interface (which we have deployed as s-ramp-ui).  Once there we can click on Browse Artifacts and observe that there are no artifacts currently deployed to the repository.

     

     

    Next, let’s take a look at the structure of our demo and what we need to change to get the ‘artifacts’ JAR deployed into the S-RAMP repository.

     

     

    First, notice that the ‘artifacts’ project is a simple Java project that also includes a WSDL and an XML Schema.  We need to tell Maven how to deploy this project into the S-RAMP repository.  This is done by modifying the project’s POM to add a “distributionManagement” section, with an sramp:// protocol URL.

     

     

    Of course, by default Maven doesn’t understand what to do with an sramp:// formatted URL, so we need to tell it about the S-RAMP Maven extension.  This is done by adding an “extension” section to the project’s POM.

     

     

    Now we can go ahead and use Maven to deploy the ‘artifacts’ JAR.  We do this by simply running a standard maven deploy build.

     

     

    Once that build succeeds, we can reload the User Interface and see that some artifacts have been added and are now browsable.

     

     

    There are some things to notice here.  First, note that six artifacts have been added to the repository:  the project JAR, the project’s “classes” JAR, the project POM, and three additional SOA artifacts (a WSDL, an XML Schema, and an XML file).  You may be wondering why these three additional SOA artifacts are present.  The reason is that our maven integration layer will automatically expand and deploy any interesting artifacts that it finds in JARs, WARs, and EARs.  By default, that includes XML files, WSDLs, XML Schemas, and Policy files.

     

    Note that when you view the details of the “artifacts” JAR you will see a number of maven-specific properties, including the groupId, artifactId, and version (along with the MD5 and SHA1 hashes).  These properties are also added automatically by the Maven integration layer.

     

     

    Now that the “artifacts” JAR has been deployed to the S-RAMP repository, and we’ve seen that we can browse for it in the S-RAMP user interface, let’s see how other Maven projects can use it as a dependency.


     

    The multiApp demo features three Maven projects, each of which depends on the “artifacts” project that we just deployed.  The dependency is specified, as normal, in all three projects’ POMs.  The question is:  how do we make Maven aware of the S-RAMP repository?  That’s obviously important because it’s where we just deployed the “artifacts” JAR.

     

    To do that, we add a new repository to the ‘repositories’ section of the multiApp parent POM.  We can do this in the parent and it will be shared by all three child projects.

     

     

    Now let’s go ahead and do a Maven build and we’ll see that the “artifacts” JAR will get pulled down from the S-RAMP repository and the build will succeed.  Note that we must first delete that JAR from our local Maven .m2 cache.  Otherwise Maven will use the JAR it finds in the cache, and this won’t much of a demo!

     

     

    The build completed successfully.  At this point we could deploy the results to SwitchYard and it would all work as intended.


     

    Conclusion

    Hopefully this webcast has provided a reasonable preview of what’s happening in the S-RAMP project.


     

    There is a Maven integration example similar to this one that comes with the S-RAMP distribution.  Have a look and let us know what you think!


     

    Thanks for watching, and for more information we encourage you to visit us at jboss.org/overlord.