By implementating the Grid Component Model (GCM) which has been originally defined in the CoreGRID NoE project, GridCOMP aims to provide a programming framework which ensures interoperability and efficiency with the Grid. Currently, the GCM interoperability is tested together with ETSI during the GRID Plugtests®, and standardized within the ETSI Technical Committee on Grid Computing. The next step is the full integration of GCM components into SOA, towards SLA and QoS enforcement.

Nowadays, in the domain of distributed software and middleware there are two different views: architecture based view which mainly relies to component model, and service oriented view. In the first one, software is described at design time with an architecture description language (ADL). Some models also allow changes in the initial architecture by featuring reconfiguration at runtime. The CCM and SCA component models as well as the Fractal and GCM support architecture based organisation. In the Service Oriented Architecture (SOA) view, software is seen as a set of independent services; location of these services may not be know at design time, they are only described. These services, accessible through Web Services, are light coupled in opposition to the first view where component could be strongly coupled; it is not the case with GCM components.

These two points of view have different advantages and also similarities such as the notions of software block (component or service); thus we think that there is a need for a programming framework bridging the gap between component technologies and SOA in order to achieve code and service composition for flexibility and agility. The SCA initiative have already begin to address this issue at design and deployment time; but the purpose is to integrate component ideas into Service Oriented Architectures in order to feature the power of full-fledged components with, for instance, the capacity to impose -when needed- the interoperable and flexible deployment of components upon execution. It is clear that academia and industry are still lacking mechanisms to support adaptation and reconfiguration of components during execution, based on the dynamic event occurring in real-time; for instance machine failure or overload. Moreover, we are still missing the mechanisms to take into account application level requirements, such as Service Level Agreements, in order to improve contracted Quality of Services.

Another issue is the difficulties to identify the basic requirements for a given component in order to select dynamically the right set of machines on which they can be executed. This is a strong limitation that prevents components to be used in service oriented architecture. Such functionality will require a unified model to describe application needs, which shall be valid for most of the Grid application. This brings us to another issue that we have to treat at the same time: standardization. There is a need to have standardized component model, application description, and application level requirements in order to really promote block of software at the level of reusable components.

Overall, we believe we have to achieve in a standardized way the full integration of components into Service Oriented Architecture, with the capacity to monitor and dynamically maintain the Quality of Services at execution.