Skip to content

User story : SOA discovery & audit

Marwane Kalam-Alami edited this page May 16, 2012 · 3 revisions
<<< Back to [[Final soa model design]]

Summary

Introduction

  • Role involved: SOA Analyst/Architect
  • Goals:
    • Get a full picture of my SOA (XXX1: What exactly?)
    • Be able to share it to others in commonly used formats (XXX2: What exactly?)
  • Features
    • SOA Cartography based on the discovery of
      • Design documents
      • Web services artifacts
      • Exposed web services
    • Export of all gathered information (XXX2)

Note: A### use case

User story

Cartography

As a SOA Analyst/Architect, I just installed EasySOA, and want to use it to get a map of my SOA.

  1. GIVEN that I have just installed EasySOA,
  • WHEN I use it for the first time,
  • THEN I am invited by EasySOA to use discovery tools to gather information.
  1. GIVEN that I want EasySOA to explore a Git repository where my artifacts are stored,
  • WHEN I start the discovery by sources analysis tool
  • AND I provide a public SCM URL (or restricted-access URL + credentials),
  • THEN all artifacts (and web services?) are discovered by EasySOA.
  1. GIVEN that I have an SCA composite to provide,
  • WHEN I start the discovery by import tool
  • AND I fill the form to choose one or more files to import (+ a few options),
  • THEN they are parsed and stored accordingly.
  1. GIVEN that I know a web page where I can find a list of web services,
  • WHEN I start the discovery by browsing tool (XXX3)
  • AND I browse to the WS list page,
  • THEN all web services are recognized and stored in EasySOA.

Note: Discovery by monitoring is not relevant here, as there would not be much requests to catch. But using it would be possible if we provide technology-specific, invasive probes that would listen on each app to monitor.

(XXX4: Is this enough to build a complete enough map?)

Exploration/correction

AS the SOA Analyst/Architect who run the previous discoveries:

  1. GIVEN than I made EasySOA discover services/deployables/design documents
  • AND I want to check if everything is fine,
  • WHEN I explore the service registry,
  • THEN I can view the newly discovered SOA.
  1. GIVEN that I noticed some web services/deployables shouldn't be there
  • WHEN I mark them as unwanted information,
  • THEN they are deleted
  • AND won't reappear during next discovery sessions.

Export

AS the SOA Analyst/Architect who ran the previous discoveries:

  1. GIVEN that my SOA cartography is satisfying
  • AND I want to export a package of all WSDLs
  • WHEN I run the WSDL export on the whole SOA
  • THEN I get a ZIP containing every single WSDL found

(XXX2)

Cartography (bis)

  1. GIVEN that I have used a discovery tool in the past
  • AND I think the EasySOA map of my SOA is outdated,
  • WHEN I want to audit my SOA again,
  • THEN I can reuse the configurations I previously entered
  • OR I can plan an scheduled discovery (?).

UI requirements

Discovery

  • Wizard that invites users to help EasySOA gathering information, according to:
    • The context/their capabilities ("Do I know where the applications sources are stored?", "Can I access a list of my app's web services through my browser?", etc.)
    • Their goals (find WSDLs, proxy a specific service, etc.)
  • Discovery tools UIs
    • Discovery by browsing (either: dedicated UI, or bookmarklet UI + 'how-to page')
    • By data import (import form)
    • By SCM exploration (configuration form)
    • But also...
    • By Maven repository exploration (configuration page)
    • By runtime analysis (form to provide the right tool depending on the service stacks -> classpath analysis, services introspection, etc.)

Registry

  • SOA browsing
    • Any hierarch(ies) allowing to browse all services/deployables/design documents

Export

  • WSDL export button? Full-featured form? (XXX2)

Model requirements

We need to be able to store:

  • Web services (URLs, WSDLs, files)
  • Discovery presets (SCM URL, Maven repository, DBB bookmarks)

We might also need to store: (XXX1)

  • SCA composites used for import (and link them to the related Web services?)
  • Deployables (sources location)

Model interactions

Cartography

  1. (Nothing during 'welcome screen')
  2. When using then discovery by sources analysis tool, it creates:
  • A set of Deliverables with some properties (name, SCM URL, Maven ID, etc.).
  • If web services are found, the matching ServicesImplementations are created and linked to the relevant Deliverables. These ServicesImplementations store various parsed metadata (name, path, Java class, etc.)
  1. When using the SCA import, it:
  • Stores the .composite in Nuxeo as a SCACompositeDoc (which is a specific RequirementsDocument type)
  • and links it to a new System named after the SCA component ;
  • Creates all relevant Services & ServiceReferences, and adds them to the newly created System. Uses correlation to match the Services with the ServiceImplementations previously created. As .composites might store plain URLs for services, relevant Endpoints are created to resolve the ServiceReferences.
  1. When using discovery by browsing, it:
  • Creates Endpoints and integrates them to the rest of the model
  • Attaches scraped documentation to relevant documents (Endpoints/ServiceImpls/etc., according to user wish)

Exploration/correction

  1. According to what I want to browse, ManagedSystems are created to build various views, for instance:
  • Endpoints stored by server
  • ServiceImplementations stored Following a similar hierarchy as the source code repository
  • Services by (SCA) component
  1. In order to mark some document as unwanted: any RequirementsTarget (except Systems) can be marked as masked, so that they are still there but masked to all users.

Export

  1. (Nothing, model is only explored and read for WSDL export)

Cartography (bis)

  1. Each discovery tools stores its previous configurations, eventually with links to the Service Registry model (e.g. SCA import: the SCA import tool should be able to retrieve any SCACompositeDocs)

Missing information

  • XXX1: Do we need to provide the information we gather in a synthetic format? (= reports, graphical network maps, etc.) Or only get a centralized access to most information? (= service registry)
  • XXX2: What kind of export features do we need exactly? WSDL zips? Zips with everything? PNG export of the SOA? Or any of these, through an export form? If so, what kind of information filters should we provide? (e.g. by Provider, by Environment, pick Design docs only, etc.)
  • XXX3: Discovery by browsing feasability? All approaches to implement it have major to blocking issues ; mainly:
    • Webapp = required proxy doesn't work with HTTP, is annoying to setup and could be hard to set up on certain environments because of company policies
    • Bookmarklet = Only supports GET requests
  • XXX4: Are the non-invasive discovery tools powerful/transversal enough to build a coherent may of the SOA? For instance:
    • OK: Assuming discovery by browsing can be used, exporting all WSDLs should not be an issue
    • KO: Matching Web service vs. Artifact (unless the source code exploration tool can handle it)

Draft: A### - SOA audit

As a subcontracted SOA analyst / architect,

  • I want to mine the information system of the entreprise that pays me to discover services (their artifacts, how they are designed & work), so that I can get a full picture of its SOA
  • I want to export it, so that I can provide in a single go the whole picture I made of the SOA to the company that pays me

(discovery then export ; in 0.3, see wiki doc)

Clone this wiki locally