Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "GOCDB/Release4/Development"

From EGIWiki
Jump to navigation Jump to search
Line 9: Line 9:
* Also priortised in following doc: https://documents.egi.eu/secure/ShowDocument?docid=1997
* Also priortised in following doc: https://documents.egi.eu/secure/ShowDocument?docid=1997
<!--* Feedback received on the new system is given at: [[GOCDB/Release4/Feedback]]-->
<!--* Feedback received on the new system is given at: [[GOCDB/Release4/Feedback]]-->
===Support different AAI schemes===
* Add support for Federated Identity Management (FIM) to allow authentication other than x509
* Extend the authentication system to simplify user-access: a modular architecture will be adopted to allow easy extension and integration with different AAI systems, especially for Federated Identity Management (FIM). This would also include an open-access mode allowing un-authenticated users to browse the public-facing services/resources in read-only mode (hiding selected/sensitive data).
===Audit Trail===
* History log, i.e. who did what and when such as updating data, approving roles (July 2015 - June  2016, EUDAT M4-M15)


<!--
<!--
Line 16: Line 23:
* Simiar to the GLUE2 extensibility mechanim, the core GOCDB entities (NGIs, Sites, Services, ServiceGroups, Endpoints) will be extended so that they can define an optional set of custom key-value pairs with PI query support.
* Simiar to the GLUE2 extensibility mechanim, the core GOCDB entities (NGIs, Sites, Services, ServiceGroups, Endpoints) will be extended so that they can define an optional set of custom key-value pairs with PI query support.
-->
-->
===Investigate Service Registry Requirements===
* Investigate if GOCDB could be extended for use as public-facing service registry for science-applications, and assess feasibility and benefit. This would probably need to cover: un-authenticated users, service SLAs, pay-for-use details, service access/usage policies, service-capabilities, other extra info...




Line 38: Line 49:
<!--** [[GOCDB/Release4/Development/VSites#VO_Feed_for_ATP]]-->
<!--** [[GOCDB/Release4/Development/VSites#VO_Feed_for_ATP]]-->


===Support different AAI schemes===
* Add support for Federated Identity Management (FIM) to allow authentication other than x509
* Extend the authentication system to simplify user-access: a modular architecture will be adopted to allow easy extension and integration with different AAI systems, especially for Federated Identity Management (FIM). This would also include an open-access mode allowing un-authenticated users to browse the public-facing services/resources in read-only mode (hiding selected/sensitive data).


===Audit Trail===
* History log, i.e. who did what and when such as updating data, approving roles (July 2015 - June  2016, EUDAT M4-M15)


===Enhance Data Model===
===Enhance Data Model===
Line 56: Line 62:
===Enhance UI===
===Enhance UI===
* Introduce a more capable MVC framework to improve the UI and user experience
* Introduce a more capable MVC framework to improve the UI and user experience
===Investigate Service Registry Requirements===
* Investigate if GOCDB could be extended for use as public-facing service registry for science-applications, and assess feasibility and benefit. This would probably need to cover: un-authenticated users, service SLAs, pay-for-use details, service access/usage policies, service-capabilities, other extra info...


===Investigate Abstraction of Business Rules===
===Investigate Abstraction of Business Rules===

Revision as of 18:15, 6 November 2014

Main EGI.eu operations services Support Documentation Tools Activities Performance Technology Catch-all Services Resource Allocation Security


GOC DB menu: Home Documentation Index


Current Developments

The developments we are currently working on are listed below.

Support different AAI schemes

  • Add support for Federated Identity Management (FIM) to allow authentication other than x509
  • Extend the authentication system to simplify user-access: a modular architecture will be adopted to allow easy extension and integration with different AAI systems, especially for Federated Identity Management (FIM). This would also include an open-access mode allowing un-authenticated users to browse the public-facing services/resources in read-only mode (hiding selected/sensitive data).

Audit Trail

  • History log, i.e. who did what and when such as updating data, approving roles (July 2015 - June 2016, EUDAT M4-M15)


Investigate Service Registry Requirements

  • Investigate if GOCDB could be extended for use as public-facing service registry for science-applications, and assess feasibility and benefit. This would probably need to cover: un-authenticated users, service SLAs, pay-for-use details, service access/usage policies, service-capabilities, other extra info...


Render GOCDB data in GLUE2 Format

Insert-downtime PI method


Enhance Data Model

  • Extend the data model to more effectively support clouds, virtual infrastructures new resource types, e.g. by supporting more attributes from the GLUE2 standard and the currently evolving GLUE2.1 cloud extensions.

Provide Service and ServiceEndpoint PIDs

  • e.g. leverage the EPIC PID service (www.pidconsortium.eu) to assign PIDs to Services and Endpoints
  • Creates a longtime stable and unique service-id, assigned when a new SE is created.
  • ID could be resolvable such as the EPIC/Handle PIDs are.
  • Provide at least one new specific PID field which can be entered by site (service-endpoint) managers.

Enhance UI

  • Introduce a more capable MVC framework to improve the UI and user experience

Investigate Abstraction of Business Rules

  • Investigate if the GOCDB business rules could be abstracted using a Business Rules Management Engines (BRMS), and assess feasibility and benefit: currently GOCDB enforces a number of EGI specific business rules and access policies. These could be abstracted into a separate module (or external system) to allow other resources in different projects/scopes to apply different rule-sets and policies for their resources