Difference between revisions of "Integration and Interoperability Facilities Framework: Client Libraries"

From Gcube Wiki
Jump to: navigation, search
m (→‎Client Libraries Design Model)
(→‎Design Model)
 
(13 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
= Client Libraries =
 
= Client Libraries =
−
Work withing CL layer of the Integration and Interoperability framework focuses on a subset of the client libraries found within the system, those that mediate access to some of the system services. The CL Model documents best practices and guidelines for all the cross-cutting concerns that transcend the semantics of individual target services. It distinguishes the concerns that relate to CL design from those that relate to CL management and evolves two separate models for their structuring: the Design Model and the Management Model. The final objective is to promote consistency across CLs towards the Framework integration.
 
−
== Client Libraries Design Model ==
 
−
The [https://gcube.wiki.gcube-system.org/gcube/index.php/Integration_and_Interoperability_Facilities_Framework:_Client_Libraries_Framework_Specification Design Model] for CL addresses cross-cutting design concerns within the system libraries, that include at least the following issues: scoped calls (how scope information is to be added to client calls), secure calls (how security information is to be added to client calls), endpoint management (how services ought to be referred to, discovered, and selected), addressing, discovery, replica management, caching, asynchronous operations (how asynchronous operations ought to be implemented), callbacks, futures, notifications, streamed/bulk operations (how streamed/bulk operations ought to be implemented), fault handling: how should faults be handled.
 
−
* Throughout these concerns, driving design principles are: simplicity, testability, evolvability and, where appropriate, standards compliance.
 
−
* Consistency is more readily and conveniently achieved through shared implementations of common solutions. In this sense, the work within the framework evolution will also be concerned with the delivery of new system components that support the development of CLs. It is expected that these Support Libraries will form a framework for CL development.
 
  
−
== Client Libraries Management Model ==
+
The CL layer of the Integration and Interoperability Framework focuses on the design, implementation, and management of '''client libraries''', i.e. system components that mediate access to system services from within client Java runtimes.
−
Management Model: The model for CL management will address at least the following (inter-related) issues:
+
−
* module structure: relationship between CL modules, stub modules, and service modules
+
−
* build outputs: what secondary artifacts are associated with CLs
+
−
* release cycle: how are CLs released with respect to target services
+
−
* change management: how changes in target service API should be handled
+
−
* profiling and deployment: how should CLs be profiled for dynamic deployment
+
−
* distribution: how should CLs be packaged for distribution
+
  
−
== Client Libraries Framework ==
+
In particular, the layer defines:
−
The CL Framework covers the basic functionality described in the CL Model. The Framework adheres to the principles stated by the CL Model towards the Integration and Interoperability objectives.
+
 
 +
* a [[#Design Model|design model]] that codifies approaches to design issues which are common to all client libraries;
 +
* an [[#Implementation Framework|implementation framework]] that provides the support required to implement client libraries which comply with the design model;
 +
* a [[#Management Model|management model]] that identifies technologies and best practices for client library management, including testing, building, and distribution;
 +
 
 +
== Design Model ==
 +
 
 +
The '''design model''' for client libraries identifies a core set of capabilities that all libraries are required to offer,  regardless of specific service semantics and client-side technology stacks.
 +
The model defines also common solutions to design issues that recur across their APIs, where the solutions are based on best practices and are motivated by goals of simplicity, testability, evolvability and standards compliance. Topics that fall within the scope of model include:
 +
 
 +
* the local model of service endpoints;
 +
* the discovery of service endpoints;
 +
* the fault-tolerant binding to service endpoint replicas;
 +
* the caching of service endpoints addresses across interactions;
 +
* the classification, modelling, and handling of interaction failures;
 +
* the handling of call scope and client credentials;
 +
* the design of asynchronous interactions, including interactions based on polling, notifications, and data streams;
 +
 
 +
Read more about the design model for client libraries [[Integration_and_Interoperability_Facilities_Framework:_Client_Libraries_Design_Model|here]].
 +
 
 +
== Implementation Framework ==
 +
 
 +
The design model for client libraries identifies capabilities and patterns common to all libraries. However, it does not specify how libraries provide those capabilities or implement those patterns, nor does it define the low-level details of their interfaces.
 +
 
 +
The '''client library framework''' is a set of components that support the development of client libraries that comply with the model. Through code sharing, the framework reduces development costs and ensures the consistency and correctness of library implementations.
 +
 
 +
Learn how to use the client library framework [[Integration_and_Interoperability_Facilities_Framework:_Client_Libraries_Framework|here]].
 +
 
 +
== Management Model ==
 +
 
 +
Moving beyond design and implementation issues, the '''management model''' for client libraries focuses on the overall management of client libraries as system components. In particular, the model identifies best practices and/or tools in the following areas:
 +
 
 +
* the boundary of client library components, including their relationship to service components and, where applicable, service stubs library components;
 +
* the building of client libraries, including interactive builds and continuous integration builds;
 +
* the profiling of client libraries as system components;
 +
* the packaging of client libraries for distribution purposes;
 +
* the testing of client libraries, including unit testing and integration testing;
 +
 
 +
Read more about the management model for client libraries [[Integration_and_Interoperability_Facilities_Framework:_Client_Libraries_Management_Model|here]].

Latest revision as of 23:33, 21 May 2012

Client Libraries

The CL layer of the Integration and Interoperability Framework focuses on the design, implementation, and management of client libraries, i.e. system components that mediate access to system services from within client Java runtimes.

In particular, the layer defines:

  • a design model that codifies approaches to design issues which are common to all client libraries;
  • an implementation framework that provides the support required to implement client libraries which comply with the design model;
  • a management model that identifies technologies and best practices for client library management, including testing, building, and distribution;

Design Model

The design model for client libraries identifies a core set of capabilities that all libraries are required to offer, regardless of specific service semantics and client-side technology stacks. The model defines also common solutions to design issues that recur across their APIs, where the solutions are based on best practices and are motivated by goals of simplicity, testability, evolvability and standards compliance. Topics that fall within the scope of model include:

  • the local model of service endpoints;
  • the discovery of service endpoints;
  • the fault-tolerant binding to service endpoint replicas;
  • the caching of service endpoints addresses across interactions;
  • the classification, modelling, and handling of interaction failures;
  • the handling of call scope and client credentials;
  • the design of asynchronous interactions, including interactions based on polling, notifications, and data streams;

Read more about the design model for client libraries here.

Implementation Framework

The design model for client libraries identifies capabilities and patterns common to all libraries. However, it does not specify how libraries provide those capabilities or implement those patterns, nor does it define the low-level details of their interfaces.

The client library framework is a set of components that support the development of client libraries that comply with the model. Through code sharing, the framework reduces development costs and ensures the consistency and correctness of library implementations.

Learn how to use the client library framework here.

Management Model

Moving beyond design and implementation issues, the management model for client libraries focuses on the overall management of client libraries as system components. In particular, the model identifies best practices and/or tools in the following areas:

  • the boundary of client library components, including their relationship to service components and, where applicable, service stubs library components;
  • the building of client libraries, including interactive builds and continuous integration builds;
  • the profiling of client libraries as system components;
  • the packaging of client libraries for distribution purposes;
  • the testing of client libraries, including unit testing and integration testing;

Read more about the management model for client libraries here.

Retrieved from "https://wiki.gcube-system.org/index.php?title=Integration_and_Interoperability_Facilities_Framework:_Client_Libraries&oldid=14858"