Skip to content

V1 raw notes

Jump to bottom Edit New page
Marwane Kalam-Alami edited this page Jun 22, 2012 · 5 revisions 
<<< Back to [[EasySOA 1.0 specs]]

the different levels (separation of concern) & how to link them :

  • (design) business : BusinessDesignReqDoc (?) ; output of conversation with end user ; will help make appear (business) services ; can be formalized using JWT
  • (design) archi : Systems (components / process...) (linking to BusinessDesignReqDoc), containing Softwares (dev / depl) and services, can be specified by ArchiReqDoc informally or formally ex. in SCA ; output of conversation with architect ; helps see what devs (impls / depls) are required for business reqs ; formalized business req can be refined so subparts can be mapped to archi dev atoms (impl / depl) ; NB. Software (instance and not where it's deployed) = how it maps to actual applications
  • (design) infra : SLRReq ALSO HOSTINGREQDOC ? (helps see what servers are required)
  • (disco'd actual) impl doc'd (auto & manual) : apidoc server ; disco'd itfs link to design (archi) services, idem for serviceimpls (and endpointConsumptions) to Softwares
  • (platform / infra / operation : how to run & monitor it ; ex. gicm : IT project doc solution goes in software "boxes" containing manuals TODO & "hardware" physical servers)

how (doc subset) features use the model

webdisco in mysoa/env with additional System(s) chosen online (ex. BusinessApplicationX corresponding to one (web) UI) :

  • créé un endpoint d'id tech = env(prod or not)/url, dans env & lié dans les Sytems, wsdl stocké sur l'Endpoint ainsi que ce qui en est extrait (besoins de validation ex. serviceName), orig web page url, and extracted info useful for LATER validation / mapping to Systems (ex. title can become tag used for explicit mapping to app System)

code disco in mysoawebdisco with additional system chosen in maven plugin conf (ex. SoftwareApplicationY corresponding to one SCM repo or top-level maven id, or MyPrototypes) :

  • LATER both jaxws itf & impl link to scmview / sonar
  • interface annotée jaxws crée un ServiceImpl d'id tech deployable(maven plugin : mysoa/maven group+id+version)/package.Class), "test" if src/test (rather than main), and extracted info useful for etc. (ex. maven repo) => if no prod/main impl, either external (provided by other organization or not yet done (by me) => a service can have several interfaces, one general and other derived ones only applicable in one world (ex. jaxws in java world) NOT TO TRANSLATE BETWEEN THEM MAGICALLY but to be a ble to use the best one when validating in a given world ex. java
  • impl annotée jaxws crée un serviceimpl d'id tech deployable(maven plugin : mysoa/maven group+id+version)/package.Class), "test" if src/test (rather than main), and extracted info useful for etc. (ex. maven repo) => if prod/main, the repo's organization is the provider

autodoc :

  • disco in code (jaxws) or runtime (nuxeo), linked to impls / depl (like apidoc server)

manual doc :

  • business / use case / (process) doc => on "business / use case / process" Systems that are explicitly linked (or from jwt) to (services or even endpoints or impls or envs)
  • tech user doc (ex. how to call service, samples) : attached to mainly impls (TODO Software ?? NO)
  • archi doc : on this archi's System
  • infra tech doc (ex. sla) : attached to env ?
  • end user doc (appli doc) : attached to Apps Systems with actual app web UI url, explicitly linked etc.

manual requirements doc :

  • business / use case / process (fct) : TODO from "different levels"
  • tech specs
  • infra specs

Vues

business (process) archi impl env / executable / execution

Questions

  • 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 ?
  • Versioning : lorsqu'un document est mis à jour, besoin de 'snapshoter' tous les Systèmes qui le contiennent (cf. discussion MKA/Tiry 14 mai)
  • Fonctionnalités "RequirementsTarget", "ValidationTarget" 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)

document tree layout suggestions :

mysoa
    services/
    impls/
    envs/
        endpoints/

or:

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 both! 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 ?)

about (expectation) mappings, (disco'd) changes, validation

mappings :

"expectation" link between expected / approved design and actual discoveries, using resolved model element id or path, defines a validation rule (ex. for wsdl design : jaxws serviceimpl, endpoint, exchanges, test does all) how newly discovered things are mapped in Systems (ex. "all endpoints whose url start with http://myserver:8087 would go in MyServerSystem"), where they can be subject to automatic rules or explicit promotion to design

  1. first covering discovery 2. promoted to design (or directly design import ?) & propertize (wsdl...) 3. other discoveries (update missing, update changed, new unknown => promote or approve if required ex. http & rights, new unknown with suggestions => link)

promotion to design (including for jwt business processes ?) ; rules :

  • source itf : requires non-snapshot version

rediscovered thing changed / updated :

  • meaning rediscovered with same own / tech id ex. java class in maven project & repo, wsdl on same endpoint url + CONTEXT CONF ex. branch
  • changed against known or previous version :
    • for source itf module version (but not for SNAPSHOTs) or diff or hash or commit (including imported DTOs),
    • for source impl module version (but not for SNAPSHOTs) or diff or hash or commit (but not comprehensive unless including all deps),
    • for online wsdl diff or hash (including included xsd),
    • (??) for proxy-recorded exchange triggered by a driver because reponse assertions not valid anymore
  • automatic validation

validation against design : *

validation :

  • easysoa's goal is to manage consistency between expected and actual
  • externalisée pour l'intérieur des blackbox components : validation "deep" des modèles par EMF / OCL à distance sur Eclipse en server, ou entre interface java et implémentation java par build process

rules : *

  • all services must have (at least) one impl

validation ex code : maven plugin has conf of which (in addition to artifact id & group) System ("business" code, main vs test) it goes to, and service (itf or impl) code annotations to where it more precisely goes / maps (service vs handler, connector) (but could go in maven plugin conf also). Rules are on Systems (?? ex. at more one impl of service save for handler or test or ...), within which mappings are managed / listed. In EasySOA, artifact & serviceimpl/itf shows in a list of previous versions when changes where detected.

  • there are explicit maps (to element or system id / path), "hard" maps (i.e. between itf & impl of the same code, or between endpoint & artifact coming from an integrated runtime platform) and "suggested / to be approved / on mapping validation dashboard" maps

design =

  • what makes sense (for business) (so code classification systems would not be design but code-only ?!?)
  • & what's expected (rules & their configuration)

(doc subset) functional

web disco :

  • => creation of ENDPOINTS WITH THEIR OWN WSDL in execution context (to be chosen / chosen in session) = env, which can be promoted to a new (design) service or mapped to an existing one, idem for implem / code how to display web ? url & title, link to web / in web disco tool, small image / screenshot
  • "error : no mappings for" list of endpoints => create mapping

code disco :

  • => creation of SERVICEIMPLEMENTATIONS WITH THEIR OWN CODE ITF in executable (?) context (main, main_server1, main_server2, ((junit) test(1, 2)) which... how to display code ? class (service itf / impl) name & (annotated) signature, links to integrated svn(web), trac, sonar, eclipse, or ease integration in others (pluggable link) ("Choose a disco profile", default has all ex. jaxws/rs), we've found all that and suggest those mappings / promotes (=> what's a good ui for that ?? = list of suggested relations among modifs = mappings dashboard) ex. of suggestions : this impl is tagged "test" because in test, associated to a Service because itf (=> TODO jaxrs/ws <=> wsdl : transfo or only annots), therefore associated as one of its "tests" ; idem for "main", if 2 "main" then "conflict" unless "create new execution context" ex. prod1, prod2
    • menu versioning : "(tree) version list, go back to previous one, save / minor version..."
  • "error : no mappings for" list of impl => create mapping online or in code...

TODO Q share or not : artifact repos, code repos, (design repos) (, disco sessions / networks). If share, could find / easier disco, but also sanity check ! If not, can apply user rights !

monit disco :

  • => idem as web disco but with more exchanges, leading to examples / records / call count rather than wsdl

design / import disco :

  • => design / reqs docs & services / refs / apps

runtime (frascati, nuxeo) startup disco :

  • => as code + web (monit) disco

runtime monit disco :

  • => SLA status

interface ping : =>

where are external services from ??

  • => "import external services from external soa at" easysoaUrl soaName/service(/impls(/env(s)(/endpoint(s)))) ("as" nonDefaultRoleAtExternalSoa / profile)
  • (or "1. import (sync'd) external soa, 2. copy / paste as external service"
  • & code annotations could define the "natural" / auto external soa where services are actually defined ex. Nuxeo's
  • what if
    • implement external service ?
    • run external impl ?
    • consume external endpoint ?

env inheritance ?!? to allow ex. different test subEnvs...

test setups :

  • unit : 1 impl, several mocks & drivers (i.e. client) impls ; endpoints (i.e. value of url) in dev or ci env
  • soa : all impls, mocks & drivers of external soas impls ; endpoints in dev, ci or integration / staging env

main setups :

  • single : all impls including of external soa ; endpoints in (pre)prod env
  • else reference + derived / delta (in params i.e. urls or even impls ex. alternate be it in different moduels or branches) =>
  • hot backup / secondary : idem in prod2 env (system ?!?)
  • cluster : ha_env includes prod1 & prod2 envs plus load balancing etc. (service has endpoints lb exposed externally, and 1 & 2 within their envs / systems)

system kinds : voir # nuxeo, #100 fstudio, # wf, # smarttravel

  • design_(sub_)process(jwt), design(sub_)component(sca), design_app(_fstudio), design_layer_app/fct/tech(_casden), (design_projet)
  • impl_construction(_root = platform), impl_classification(_root = artifact repo) (voire _package), (deployable(_fstudio))
  • runtime_platform_nuxeo (env ?), runtime_platform_light(_fstudio) (env ?), (runtime_easysoa_proxy), runtime_classification(_root = cluster) (voire plus pour scalabilité)

TODO doc, discco web url WSDL (endpoint), disco code jaxrs (impl)s

TODO monitoring format : headers, (custom) properties, content like amqp's http://blog.springsource.org/2010/06/14/understanding-amqp-the-protocol-used-by-rabbitmq/

TODO easysoa runtime model extends design time model like emfgen/ecore does NOT REALLY, OK FOR DESIGN / EXPECTED BUT NOT FOUND / MONITORED

TODO wf mapping : meta pour "qui est reponsable de quelle partie du modèle"

service load balancer vs actual impl :

  • same business itf (ex. wsdl), but different requirements / SLR (which could maybe go in wsdl on some platforms, but exposed ??) though they may not be auto accessed here
  • so to help mapping : discovered impl (or endpoint...) matching this wsdl are mapped by default to actual impl bp rather than lb

same service with different...

  • bp / req : ex. load balancer vs actual impl

  • source : => branches of it

  • tests : => profiles ??

  • depl : => versions of it (possibly tagged or even branched)

  • depld : runtime

  • disco context : easysoa must ease "how to use this service" and "how to map this disco'd ones on the design (known / approved)"

  • manual : ex. web disco "in this appli (known in design)"

  • auto : ex. code / depl disco "in this (sub)workflow (known in design)" or "maven module (known / generated from design)"

TODO validators (ex. wsdl known vs just disco) != validation dashboard (shows it, but also against "reference" services that are mapped or correlated using another algo on "all services" => these should become "all context services" gotten from nxql query param'd by the context params ex. system / software id that can be copied on service)

model : map deployable executable workflow (subprocesses) to design multiplatform subprocesses ?

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