8 Replies Latest reply: Jul 11, 2012 3:31 PM by Randall Hauch RSS

S-RAMP/SOA UI Requirements

Eric Wittmann Novice

Overview

As part of the work we're doing with the S-RAMP repository implementation, we want to create a user interface.  The scope and audience for this user interface is important, so I'm looking for thoughts that can be ultimately formed into a high level set of requirements.

 

Scope

One obvious decision we need to make:  what is the scope of the UI? 

 

This work is being done within the umbrella of SOA Governance, so it seems likely that the UI should focus primarily or even exclusively on Governance related activities.  Of course, Governance means different things to different people.  We need to navigate that landscape to arrive at a set of features that are cohesive, make sense, and provide value to the audience.

 

Audience

Another decision we need to make:  who are the primary users of the UI?

 

This decision is similar but slightly different than the Scope decision above.  Perhaps we can choose the audience for the tool, which might narrow or focus the scope discussion.

 

Initial Thoughts

I like to think about User Interfaces starting at a high level "activities" perspective.  Consider Eclipse, for example.  The Eclipse IDE has the concept of Perspectives, which group sets of features into a high level logical structure.  Examples include Java Development, Debugging, Team Synchronizing, etc.  These Perspectives identify the high level activities being performed, and also group together the features and UI views needed to perform them.

 

Following are some initial ideas for high level activities that might be useful in a S-RAMP/SOA UI.  This should serve as a starting point for a discussion about what other high level behavior the UI should provide.  Additionally, we can dive a bit deeper into each and list out the specific features needed.

 

High Level Activities

Repository Browsing

I think the most obvious requirement is the ability to browse the S-RAMP repository.  This includes simple navigation through the artifacts in the repository, along with more advanced searching/filtering.  I can imagine an initial implementation that works like http://search.maven.org/.

Features

 

Artifact Analysis

A feature of SOA Governance that would be immediately useful to users is analysis of their artifacts.  We can do a variety of analysis, including:

  • Artifact validity (syntax, semantics, best practices, etc)
  • Dependency analysis
  • Trending (what artifacts are changing most frequently)

 

Repository Management

If the Repository Browsing activity above is focused primarily on finding artifacts, there should also be a part of the UI that is responsible for adding and updating artifacts.

  • Add (upload) new artifacts to the repository
  • Update repository artifacts
  • Delete repository artifacts

 

SOA Modelling

Once we are properly handling everything in the repository, it would be good to be able to model new service candidates.

  • 1. Re: S-RAMP/SOA UI Requirements
    Gary Brown Master

    In terms of activities:

     

    Artifact Analysis - although understanding dependencies is important, a more indepth form of analysis would be impact analysis, so for certain types of artifact we may want to understand the changes that have occurred between versions (possible in different lifecycle stages), to see whether they will potentially have an impact on service clients.

     

    Repository Management - an important area from a governance perspective would be understanding responsibility. When artifacts are pushed to the repository, they will initially not have any concept of ownership, so it would be good if (a) an organisational structure could easily be managed in the repo/UI and (b) artifacts could be associated with different organisations (if external) or teams (if internal) to understand who owns the artifact, and contact details etc for support or SLA issues.

     

    Another requirement in this area maybe dependency maintenance - the initial upload of a service artifact may result in dependencies being established automatically, however this may not always be the case, and definitely not when we get into SOA Modelling where service candidates and their dependencies will need to be manually created.

  • 2. Re: S-RAMP/SOA UI Requirements
    Randall Hauch Master

    Repository Browsing

    I think the most obvious requirement is the ability to browse the S-RAMP repository.  This includes simple navigation through the artifacts in the repository, along with more advanced searching/filtering.  I can imagine an initial implementation that works like http://search.maven.org/.

    Features

     

     

    I don't believe that hiearchical browsing of S-RAMP will effective. First of all, there isn't much hierarchy in an S-RAMP repository, and what hierarchy exists is largely a categorization by type: all the XSDs are under "xsd", all the WSDLs are under "wsdl". Instead, S-RAMP allows each artifact to be tagged (using an OWL-Lite ontology to define the tags).

     

    IMO, the best approach to enable users to find things within the repository is to use a filtering mechanism. Sure, there should be some filters that are predefined. Perhaps parts of the UI can even be designed to make the user think they're using a hiearchy and navigating (though I'd prefer to never give the users this artificial mental model). But perhaps the best reason is that these filters can be defined/added by extensions so that the UI can be extended for data governance, resource governance, document governance, etc., and no just for SOA Governance.

     

    I have a great example of an application that never uses navigation: iTunes. Everything you do is by filtering or searching. This kind of UI paradigm is fantstic when something doesn't belong in only one place but instead belongs in multiple places. And this is exactly what we have with S-RAMP: artifacts don't belong to a single hierarchy, but instead can belong to multiple things based upon tags.

  • 3. Re: S-RAMP/SOA UI Requirements
    Randall Hauch Master

    Repository Management

    If the Repository Browsing activity above is focused primarily on finding artifacts, there should also be a part of the UI that is responsible for adding and updating artifacts.

    • Add (upload) new artifacts to the repository
    • Update repository artifacts
    • Delete repository artifacts

    Isn't this more about managing artifacts rather than repositories? Perhaps "Artifact Management" might be a more appropriate term.

  • 4. Re: S-RAMP/SOA UI Requirements
    Eric Wittmann Novice

    I agree - the UI for "browsing" should not be hierachical based on type.  I think searching and filtering should be how data is browsed/presented.  I imagine there are a number of ways to slice and dice the artifacts depending on various criteria, like the role of the person browsing.

     

    Of course, that begs the question:  who are the users? 

     

    Are there multiple groups/types of users?  Does the UI for browsing the repository need to be different depending on the group/type the user is in?  If so, can the user be in multiple groups/types?  Can they switch their current "role" to get a different browsing style?

     

    Perhaps that's going too far - there can be a single browser based on filtering/searching that is flexible and natural enough to accomodate the needs of all groups.  But it would still be helpful if we enumerated the different types of users so we can make sure the browser is useful for them all.

  • 5. Re: S-RAMP/SOA UI Requirements
    Eric Wittmann Novice

    Randall Hauch wrote:

     

    Repository Management

    If the Repository Browsing activity above is focused primarily on finding artifacts, there should also be a part of the UI that is responsible for adding and updating artifacts.

    • Add (upload) new artifacts to the repository
    • Update repository artifacts
    • Delete repository artifacts

    Isn't this more about managing artifacts rather than repositories? Perhaps "Artifact Management" might be a more appropriate term.

    Yeah, fair enough.

     

    For the record, my plan is to convert this discussion into a wiki page/article once we have talked it through enough and we've made some initial decisions.

  • 6. Re: S-RAMP/SOA UI Requirements
    Randall Hauch Master

    Of course, that begs the question:  who are the users?

     

    Are there multiple groups/types of users?  Does the UI for browsing the repository need to be different depending on the group/type the user is in?  If so, can the user be in multiple groups/types?  Can they switch their current "role" to get a different browsing style?

     

    Perhaps that's going too far - there can be a single browser based on filtering/searching that is flexible and natural enough to accomodate the needs of all groups.  But it would still be helpful if we enumerated the different types of users so we can make sure the browser is useful for them all.

     

    I'd think that at a minimum the results will take into account the roles/privileges (so that users only see the information they're allowed to see). But I can definitely see that the UI would reflect the capability given the user's capabilities (based upon roles/groups). For example, if you don't have privilge to upload new artifacts, the UI would never present that option. Or, if a user can only govern SOA artifacts (and not data, rules, or resource artifacts) then perhaps the UI would not include such pre-defined filters (e.g., predefined 'smart search').

     

    Consider this example: let's imagine a governance repository capable of governing SOA and data-oriented artifacts. A user logs in and only has the ability to govern SOA artifacts and cannot even read the data artifacts. In this case, I'd think the UI would present a way for the user to click on "WSDLs" and "XSDs" (or perhaps just "Web Services"), but would not present any of the data-oriented filters (like "DDLs" or "Databases"). (Note, I'm expressly using in this example the term "SOA" to apply to web-services and not data services.)

     

    Does that help at all?

  • 7. Re: S-RAMP/SOA UI Requirements
    Eric Wittmann Novice

    I'd think that at a minimum the results will take into account the roles/privileges (so that users only see the information they're allowed to see). But I can definitely see that the UI would reflect the capability given the user's capabilities (based upon roles/groups). For example, if you don't have privilge to upload new artifacts, the UI would never present that option. Or, if a user can only govern SOA artifacts (and not data, rules, or resource artifacts) then perhaps the UI would not include such pre-defined filters (e.g., predefined 'smart search').

     

    Consider this example: let's imagine a governance repository capable of governing SOA and data-oriented artifacts. A user logs in and only has the ability to govern SOA artifacts and cannot even read the data artifacts. In this case, I'd think the UI would present a way for the user to click on "WSDLs" and "XSDs" (or perhaps just "Web Services"), but would not present any of the data-oriented filters (like "DDLs" or "Databases"). (Note, I'm expressly using in this example the term "SOA" to apply to web-services and not data services.)

     

    Does that help at all?

     

    Yes I think that matches up with what I was getting at - the structure of the UI is common regardless of the logged-in user's role.  However, the specific data they see and even the specific buttons they can click on are determined by their role.

     

    That seems better than trying to figure out a way to change the actual structure of the UI based on the user's role (in other words the *layout* of the UI vs. just hiding/showing data and functionality).

  • 8. Re: S-RAMP/SOA UI Requirements
    Randall Hauch Master

    Yes I think that matches up with what I was getting at - the structure of the UI is common regardless of the logged-in user's role.  However, the specific data they see and even the specific buttons they can click on are determined by their role.

     

    That seems better than trying to figure out a way to change the actual structure of the UI based on the user's role (in other words the *layout* of the UI vs. just hiding/showing data and functionality).

    I agree.