Skip to content

Easysoa integration architecture development platform

mdutoo edited this page Jan 7, 2013 · 13 revisions

For now, it's mainly FraSCAti Studio that is used as a blueprint of development platform integration.

EasySOA with development platform (FraSCAti Studio, resp. Talend) - features

NB. old study : https://github.com/easysoa/EasySOA/issues/100

What FraSCAti Studio sees in EasySOA Registry - alternatives :

  • lookup everywhere (i.e. FS is in a project always depending on all others in a given entreprise-wide environment ex. staging) :
  • in all published (sub-)project versions OR in their latest version OR in a configured entreprise-wide environment ("Light") OR also according to further criteria on project or service ("visible to Light" on IS...).
  • Harder to contribute app back to a given project : OPT must copy app in it and redo matching, or externally link app to it (like Nuxeo docItems) TODO but using which UI ?? TODO same for records ?! TODO not versioned along with project (but no versioning in FraSCAti Studio or Deployer for now anyway)
  • lookup in (sub-)project (id provided at OPT ex. in app name at creation from EasySOA UI) that it is in.

Specifications :

  • SimpleServiceRegistryService.query(WSDL)Interfaces(...) : select * from InformationService where (name like '%search%' or desc like '%search%') [and projectId=appGivenProjectId || projectId in (allProjectIdsReferredByFraSCAtiStudioProject)] and platform_service_standard='SOAP[1.1]' [and ws_binding_transport(_type)='http://schemas.xmlsoap.org/soap/http'] [and platform='fraSCAtiStudioPlatformId']
  • UNION SOAP Endpoints WSDLs, OPT UNION (re)source WSDLs
  • returns : (sub)projectId, (nuxeo id,) name(title), description, soaname, objectType=InformationService(Endpoint), wsdlDownloadUrl=attachedFileUrl
  • OPT EasySOA id stored as component (service ??) name in composite (so it is available at SCA discovery time), OPT EasySOA id is a "pretty" versioned id
  • to download WSDL : in a first time use hardcoded BasicAuth (Administrator:Administrator) in FraSCAti client (or CXF HTTPClient)
  • SimpleServiceRegistryService.query(SOAP)Endpoints(...) : select * from Endpoint where ...
  • returns : (sub)projectId, (nuxeo id,) name(title), description, soaname, objectType=Endpoint, endpointUrl [, wsdlUrl=deduced, wsdlDownloadUrl=attachedFileUrl]
  • endpointUrl is enough to identify it in EasySOA. OPT store EasySOA id anyway in binding name in composite.
  • OPT for JAXRS interfaces (as JavaServiceImplementations) & Endpoints
  • helper : (Light)RegistryService.getAllProjectIdsPublishedIn(Light)Environment(ex. "staging")
  • 20121203 added queryServicesWithEndpoints : returns services of the given subProject that match the search, for each along with the array of all its endpoints. This is a convenience method to avoid to do a lot of queries. It is especially useful to external platforms that want to synchronize all endpoints.

UPDATE 20121207 see source of

FStudio register app - DevAppRegistryService (or mere Discovery ?) :

  • in FraSCAti Studio-dedicated "Light" project depending on all others, or in given project (id provided ex. in app name at creation OPT from EasySOA UI),
  • (find or) create Component of platform FStudio and FStudioAppDeliverable (OPT IntegratedLightPlatformDeliverable) OR only top-level deliverable / "application", with infos about platform & app (user as author or IF NOT LOGGED as "source", name, description). OPT sub hierarchy could be created, either dedicated to Template (ex. HTTPProxy) or using SCA discovery
  • (find or) create Java or OPT Javascript Impls / endpoints OPT and consumptions. By FraSCAti discovery at startup in FraSCAti Cloud Deployer (OR introspection) configured with said Component / Deliverable (AT WORSE in ThreadLocal context), atomic or grouped.
  • link to or create thanks to said Component / Deliverable if enough, else by matching dashboard
  • OPT case of using element first found in EasySOA :
  • when calling endpoints (SCA References), url is enough to resolve in said Component / Deliverable context
  • when implementing uploaded IS WSDL, store service id (or projectId + soaname ??) in db TODO WHERE EASY FOR SCA DISCO

Talend register app - DevAppRegistryService (or mere Discovery ?) :

  • in given project (id provided along with EasySOA url & login at first login in EasySOA, OPT by browsing),
  • (find or) create Component of platform FStudio OR only top-level deliverable / "application".
  • (find or) create TalendJobDeliverable (or MavenDeliverable are / could be known on Talend Studio side ?? TODO Q ccarbone) (OPT OSGi deliverable ??)
  • (in a first time, Talend Impls endpoints (& impls) won't be created)
  • OPT case of using element first found in EasySOA (implementing IS WSDL or calling Endpoint url) : store found service info (including id) in Talend Studio service metas, provide it at register
  • OPT case of other elements (i.e. designing or implementing services in Talend) : TODO Talend IS & impl discovery
  • LATER OPT Talend ESB availability probe could have a discovery mode (merely by providing rather endpoint url to EndpointStateService ??)

FStudio create on-demand proxy - GeneratedAppService

TODO INRIA implement https://github.com/easysoa/EasySOA/blob/master/easysoa-proxy/easysoa-proxy-core/easysoa-proxy-core-httpdiscoveryproxy/src/main/java/org/easysoa/proxy/management/FraSCAtiStudioGeneratedAppService.java

It is used in an architecture that allows to bypass it if not available, using always the EasySOA embeddy proxy instead :

  • (WS/)HTTPProxy(s)ManagementService.getHttpProxy(HttpProxyConfiguration extends EasySOAGeneratedAppConfiguration) returns ProxyInfo. Its is implemented on embedded proxy or FStudio side. HttpProxyConfiguration must contain params for EasySOAGeneratedApp.getId() and Template, which it extracts. It then calls :
  • (Embedded/PerUser/AndComponent)EasySOAGeneratedAppIdFactoryStrategy.getId(user, projectId, componentIds [, other SoaNode ids ex. service, impl TODO components also ?]) returns easysoaGeneratedAppId
  • getAvailablePort(conditions ex. > 20000) TODO Q pmerle implement by storing ports in FStudio db (already there ?) or by introspection (or AT WORST mere json) ??
  • (Single/Instanciating)EasySOAGeneratedApp(s)Registry.get(id, Template (httpProxy), templateParams which are easysoaGeneratedApp param PLUS port etc.)
  • finally, calls HttpProxyConfigurationService.update((proxyid,) HttpProxyConfiguration) which dispatches to Handlers

FraSCAtiStudioEasySOAGeneratedApp(s)RegistryService extends InstanciatingEasySOAGeneratedApp(s)Registry

  • its get(id, Template (httpProxy), templateParams including easysoaGeneratedApp params PLUS fixed port etc.) returns EasySOAGeneratedAppInfo, and calls :
  • it calls (FraSCAtiStudio)GeneratedAppService.generateAndDeploy(id, Template (httpProxy), templateParams) returns service (or id ?), .delete(id) (also removes from availablePorts), TODO pmerle impl on top of ServiceManagerImpl.createApplication() and DeployProcessor.deploy()

EasySOAGeneratedAppInfo :

  • easySOAGeneratedAppId ; only ??
  • (full EasySOAGeneratedAppConfiguration)

Using EasySOAGeneratedApp :

  • NB. features (ex. proxy embedded record UI, proxy record stores, get or update conf, or even app UI in FStudio) can be accessed knowing only id
  • TODO OW EasySOAGeneratedApps (ex. HTTPProxy) must expose a management UI at /ui/management, at least showing (HttpProxy and EasySOAGeneratedApp) configuration (which tells how to use it : host / port ..., can also be accessed by HttpProxyConfigurationService.get(proxyid))

EasySOA with development platform (FraSCAti Studio, resp. Talend) - auth

about auth :

  • OAuth 2-legged : like server to server auth, with shared secret, see http://communitygrids.blogspot.fr/2009/01/simple-oauth-client-and-server-examples.html
  • OAuth 3-legged : too complicated if such server to server auth is enough
  • FStudio : login by web Basic auth, puts User in session (see http://websvn.ow2.org/filedetails.php?repname=frascati&path=%2Ftrunk%2Ffrascati%2Ffrascati-studio%2Fsrc%2Fmain%2Fresources%2FeasySoa%2FaccountCreation&peg=5233 ), no security interceptors and User merely passed to business services ; service : client of social (to publish listing) using Scribe, no server (potentially FraSCAti)
  • Nuxeo : Basic, Form, JSR168 (using secret-based token, see PortalSSOAuthInterceptor), Anonymous, OAuth (2-legged POST only for forms, for UI only for Shindig etc.). Other trusting authenticators (ex. on host or token-based or SSL in FraSCAti) have to be written by calling Framework.loginAs(origPrincipal.getName()) or NuxeoAuthenticationFilter.loginAs(username) (see LoginAs operation)
  • FraSCAti : client : Basic (only for configured "system" user), TLS/SSL ; server : TLS/SSL. CXF (& SCA) offer things for user-level auth but it requires integrating FraSCAti with it. See https://github.com/easysoa/EasySOA/issues/27
  • Talend client : TODO Q ccarbone ? At login : use anything (Basic, OAuth) ; for service calls : one SSL certificate per Talend client is out of the question, OAuth 3-legged OK, any trusting auth (token-based, OAuth, SSL) OK, at worse "system"-level.

Nuxeo calls FStudio

(for createProxy ; OPT copyApp before link ?)

login : system or user ?

  • system : is enough if user provided by service in business data
  • or user :
  • would require F / CXF trusting interceptor (TLS/SSL, or write Host/TokenTrustingInterceptor) because can't pass password or show social network ui
  • OPT FS as 3-legged OAuthProvider out of the question, and each user approving Nuxeo in its social network would be too cumbersome, LATER study FS as 2-legged OAuthProvider

=> solution :

FS (resp. Talend) calls Nuxeo Service/DevApp RegistryService

from respectively UI, Intent TODO INRIA

  • login : system or user ? user is better because provides a lot of features in Nuxeo, if FraSCAti client doesn't provide auth login can be done by writing -Host/Token)TrustingAuthenticator in Nuxeo
  • which auth ? not 2-legged OAuth because NuxeoOAuthFilter allows POST only in 3-legged ; otherwise by writing (Host/Secret)TrustingAuthenticator ; in Talend maybe Basic using Eclipse-stored passwords TODO Q ccarbone ?
  • which client ? Jersey, OPT FraSCAti

=> solution :

  • if 3-legged OAuth available (see below : TODO INRIA NuxeoOAuthImpl) use it ot make calls, using Scribe (as already in FacebookCatalogServices) or Jersey, using infos from db as in FacebookCatalogServices
  • else use FraSCAti client and write (Host/Token)TrustingAuthenticator that extracts user login from business data and logs in Nuxeo (see loginAs)
  • OPT or FraSCAti OAuth TODO INRIA write FraSCAti Intent and outbound CXF Interceptor using OAuthClientUtils as in http://cxf.apache.org/docs/jax-rs-oauth.html#JAX-RSOAuth-Clientsidesupport

same users

In EasySOA distribution, ER / Nuxeo (users) (have to) exists before FS (users).

alternatives :

  • A. OAuth : FS logins in "social" way against Nuxeo (requires writing NuxeoOAuthImpl) and creates the user account if it does not exist yet
  • B. Basic : FS logins in Basic (NB. trusting not possible at login !) using Apache HTTPClient (FraSCAti Basic auth is only system-level) and creates the user account if it does not exist yet (requires writing it)
  • C. FS imports existing ones (NB. mass linking not possible) and Nuxeo notifies FS when creating a user (not pretty)

=> solution :

  • A. TODO INRIA NuxeoOAuthImpl (like FacebookOAuthImpl...)
  • AT WORSE B. TODO INRIA write Basic login to Nuxeo and account creation
  • OPT LATER2 FS Imports existing ones

Nuxeo link to FStudio

Nuxeo link to FS (UI, newFromTemplateUsingWizard ; copyAppAndLink ?) => how not to login in FS ?

=> solution :

  • for now will require another login
  • OPT TODO OW, INRIA : in Nuxeo write links with secret-based tokens (as in PortalSSOAuthInterceptor), in FraSCAti write Intent & CXF Interceptor checking it (or in business code or Intent using @Header JAXRS parameter)
  • OPT LATER2 study SSO at CXF level using SAML http://cxf.apache.org/docs/saml-web-sso.html
  • OPT Nuxeo link to web explorer
  • OPT LATER2 FS link to Nuxeo

Solution summary

  • creation at first login
  • for login & creation : OAuth 3-legged if possible to complete for Nuxeo, else Basic (using custom client)
  • AT FIRST for services no auth (but still provide user in business data), until they work
  • when Nuxeo calls FraSCAti services in Studio : TLS/SSL
  • when calling Nuxeo services :
  • if client is FraSCAti, provide user in business data and write custom trusting interceptor on Nuxeo side to log user in. NB. TLS/SSL (configured in a global Intent) can be used for trust (or at worse by Administrator login) but user still has to be logged in in Nuxeo.
  • OPT migrating to FraSCAti server on Nuxeo side requires writing custom trusting Intent to log user in
  • Otherwise OAuth (but harder to migrate to FraSCAti server in Nuxeo), or in Talend maybe Basic using Eclipse-stored passwords TODO Q ccarbone ?
Clone this wiki locally