Skip to content

V1 Model implementation discussion

Jump to bottom Edit New page
mdutoo edited this page Jul 10, 2012 · 9 revisions 
<<< Back to [[EasySOA 1.0 specs]]

Summary

  1. Model implementation alternatives
  2. Documents linking
  3. Document tree layouts
  4. Additional questions to Nuxeo
  5. 2012.06.28: Answers from OW/Nuxeo meeting

Model implementation alternatives

Documents linking

  • Question de l'implémentation des liens entre documents, notamment de l'appartenance d'un même document à plusieurs Systèmes. Faire plutôt des proxys "hard links" (comment faire ?) ou plutôt des relations ? voire une navigation virtuelles pour chaque hiérarchie de Systèmes ? And how does it behave when snapshotting (versions) ?

Document tree layouts

Two main alternatives for the actual document storage, which matches two ways to handle the 2 dimensions of the SOA: the level of detail (aggregation) & the document phase (design/impl/depl).

* SystemRoot
  * System
* Service
  * ServiceImplementation
    * Endpoint
* Deliverable
  * DeployedDeliverable
* Software
* Environment

or:

* SystemRoot
  * System
* Service & Software
* Deliverable
  * ServiceImplementation
* Environment
  * DeployedDeliverable
    * Endpoint

More detailed possibilities:

mysoa
    business/ (services / expected / requirements & rules)
        interfaces ?!
        rules ??!
        system_app1 (or rules are here rather than below ?)
            service1/itf_wsdl,requireonemainimplandtests,int_ci_allnights_unitokandallknownimplsandendpointsnotified,staging_allweeks_sampleassertionsok,prod_sla95uptime
            service2/itf_jaxws
            service3/itf_wsdl
        system_process1
            ref1 service1, system_app1
        system_frontal1
            service1
            ref1_cluster service1
            ref2_cluster service1 (also points to system_app1/service1, but if browsing impls (or runtime or endpoints) will point to the one which is mapped to construction2)
            ref3_failover service1 (if browsing runtime (or endpoints), will point to the one which is mapped to construction 3)
            construction1 (mapped to impl1_head) system_app1
            construction2 (mapped to impl1_branch) system_app1
            construction3 (mapped to impl1_head) system_app1 NOUVELLE INSTANCE (construction)
    java
        code_mavendisco/ (code itf & impl)
            mymaven_head
                system_group1
                    artifact1 (same as below ?)
                        impl1_head (mapped to system_app1 and system_frontall/construction1 and system_frontall/construction3)
                            service1impl (mapped to service 1 and system_frontall/ref1 and system_frontall/ref3)
            mymaven_branch
                system_group1
                    artifact1 (same as below ?)
                        impl1_branch (mapped to system_app1 and system_frontall/construction2)
                            service1impl (mapped to service 1 and system_frontall/ref2)
        runtime_components_classpathdisco/ (artifact jars)
        runtime_services_webdisco/ (endpoint urls & live itfs)
    nuxeo
        runtime_nuxeoosgi/ (& construction ?)
    talend
        ide_jobs
        ide_services
        runtime_platform (services & components using JMX)
        runtime_monitoring (?)
    fstudio
        ide_apps (design)
        ide_proxy (design e by e)
        ide_services
        runtime_components (runtime)
    scarbo2
        design_jwt
        construction_jwt (dev)
        runtime_jwt
    easifab
        design_bpmn
        construction_sca (dev)
        runtime_monitoring (talend ?)

or:

mysoa/
    services/
        myservice linked to bps, impls, mainitf, deriveditfs ; NO services have no (business) meaning (besides tech) outside of bps
    business/ (design requirements)
        myFormalBp.jwt linked to services consumed (endpoints) & exposed (design itfs) & later impls / depls
        myInformalBp.doc manually linked to services consumed (endpoints) & exposed (design itfs) & later impls / depls
    source/
        myScm
            "myimpl.java" with aspects serviceimpl, serviceitfs with their jaxws linked by validation to services ; OR subsummed in depls at most as original info that created service links
    depls/
        myMavenRepo
            "mydepl-1.0.jar" linked to serviceimpls
            "mybonitawf-1.0.bar"
    platforms/
        myNuxeoPlatform
            "mybundle-1.0.jar" actually very much the same as depls (is in the model but can be reified or not) ; OR linked to depl OR on depl itself OR in env
    env/
        platforms ?
        endpoints linked to services & impls ; with seen or expected endpoint ??
    samples/
        myRecordFsRepo
            "myexchangerecord1" linked to service(s) (& env ?)

SOA Share & reuse - rights

see also https://github.com/easysoa/EasySOA/wiki/User-story-:-share-&-reuse

Problem: how to share documents / propagate validation rules / notifications to all children documents? (e.g. a document attached to a Service must be made available to all Endpoints of the service)

In order to support the ability for a provider to share some of his data with his customers, there are two main options:

  • Either provide different rights to each Organization
  • Or use live proxies (or maybe publishing) to provide the same information in another document space for the customer.

Versioning

Lorsqu'un document est mis à jour, besoin de 'snapshoter' tous les Systèmes qui le contiennent (cf. discussion MKA/Tiry 14 mai)

Additional questions to Nuxeo

  • Fonctionnalités "SOANode", "AbstractFunctionality" du modèle peut-être implémentables sous forme de Facets ?
  • noeuds : virtuels (métas sur objets atomiques ex. maven id du depl sur impl) ou réels (ou les deux) ?
  • which folder-like elements' metadata to copy on their contained elements to ease finding them ? (ex. copy ASoftware.id on services / endpoints it exposes to ease finding "services exposed by Software / for BusinessRequirement" rather than through nxql JOINs)

2012.06.28: Answers from OW/Nuxeo meeting

Document links

  • Live proxies are usually a better alternative to Relations:
    • Free integration within the JSF document hierarchy
    • Compatible with the rights engine
      • The same document can be seen in a certain place but not another
    • (?) Better compatibility with the CMIS specification
    • Both allow basically to navigate within a graph (except relations allow for naming the relations & has a specific query API)
    • NB. while live proxies target the current version of a document, "regular" proxies target fixed versions (and are therefore used in publishing)
  • Documents (= Live proxies) are usually better than "virtual nodes" stored as metadata on the parent(s) document(s)
    • Again, proxies are compatible with the rights engine
    • Storing information as metadata might be more complex to set up - and query - for 1..n and especially n..n relations

Regarding the document lifecycle, by default a document is not deleted when all proxies are removed, but this can be done thanks to a simple listener. The VersioningRemovalPolicy allows for a fine management of the removal behavior.

Document hierarchies

No preffered hierarchy, still has to be decided. Navigation from a document to another can be either way easily done, either by fetching children/parent documents, or, in the case of proxies, by using the CoreSession API.

Regarding the UI

Better not make a specific UI from scratch when it comes to complex features such as document edition (= forms generation), etc. But something specific might be interesting to provide a more adapted/nicer UI for the SOA browsing, especially if built as an alternative data presentation for a REST API.

Also, the JSF UI can be linked from a JAX-RS UI by unique URLs.

Add a custom footer
Add a custom sidebar
Clone this wiki locally