Lionel Seinturier
email: seinturi@lifl.fr

Nicolas Pessemier
email: pessemie@lifl.fr

Laurence Duchien
email: duchien@lifl.fr

Thierry Coupaye
email: thierry.coupaye@francetelecom.fr

A Component Model Engineered with Components and Aspects

This paper presents AOKell, a framework for engineering component-based systems. This framework implements the Fractal model, a hierarchical and dynamic component model. The novelty of this paper lies in the presentation of AOKell, an implementation of the Fractal model with aspects. Two dimensions can be isolated with Fractal: the functional dimension, which is concerned with the definition of application components, and the control dimension, which is concerned with the technical services (e.g. lifecycle, binding, persistence, etc.) that manage components. The originality of AOKell is, first, to provide an aspect-oriented approach to integrate these two dimensions, and second, to apply a component-based approach for engineering the control dimension. Hence, AOKell is a reflective component framework where application components are managed by other, so-called, control components and where aspects glue together application components and control components.

Introduction

Software components are more and more used in various application domains. This trend is supported by the fact that many component models are available, coming either from the industry such as Sun EJB [START_REF] Bodoff | The J2EE Tutorial[END_REF], Microsoft .NET/COM+, OMG CCM [START_REF] Siegel | CORBA 3 Fundamentals and Programming[END_REF], OSGi [START_REF]OSGi Technical Whitepaper[END_REF], or from research teams (e.g. ArchJava [START_REF] Aldrich | ArchJava: Connecting software architecture to implementation[END_REF], Fractal [START_REF] Bruneton | An open component model and its support in Java[END_REF], FuseJ [START_REF] Suvée | FuseJ: An architectural description language for unifying aspects and components[END_REF], K-Component [START_REF] Dowling | The K-Component architecture meta-model for selfadaptative software[END_REF], OpenCOM [START_REF] Clarke | An efficient component model for the construction of adaptive middleware[END_REF]).

In our opinion, the domain of component-based software engineering is characterized by two main requirements: the need for components goes beyond the boundaries of programming languages, and components need to be used in various execution contexts, such as embedded applications with strong constraints in terms of memory footprint and execution costs, information systems hosted on application servers, or grid computing. In this paper, we argue that the challenge for component models is to be able to handle these requirements. So far, existing component frameworks are mostly seen as closed, black box entities which provide artefacts to design and program applications with components. The components are handled by the framework, which provides a set of services to manage these application components. Yet, this set of services is most of the time closed. This is the case for example, with the EJB [START_REF] Bodoff | The J2EE Tutorial[END_REF] component model, where new services cannot be added to the container.

In this paper we propose AOKell, which is an open implementation in Java of the Fractal component model. By implementation, we mean a software infrastructure for defining and executing components. The implementation is open in the sense that the services provided by the AOKell framework are fully accessible and programmable. By giving programmers a way to engineer these services, AOKell eases the task of adapting component-based applications to different execution contexts. This approach also fosters the development of various forms of control for components such as the ones needed to program self healing components, self-testing components, or components that carry their proofs or their specifications. Two main software techniques are used to engineer these services: components and aspects. Both the applications and the services provided to the applications are designed and implemented with components. Aspects glue together these two dimensions. This paper presents the design and the implementation of AOKell in Java with the AspectJ [START_REF] Kiczales | Getting started with AspectJ[END_REF] aspect-oriented language. Although we do not report on it in this paper, AOKell has also been ported to the .NET platform [START_REF] Escoffier | FractNet: An implementation of the Fractal component model for[END_REF].

The paper is organized as follows. Section 2.1 presents the background of this work: the Fractal component model and aspect-oriented programming. Section 3 is the core of the paper and presents the design of the AOKell framework. We show how aspects are used in AOKell (section 3.1) and we present the model for customizing the control dimension (section 3.2). Section 4 reports some performance measurements. Section 5 compares AOKell to similar existing projects. Section 6 concludes this paper and presents our future work directions.

Background

The Fractal Component Model

The Fractal component model [START_REF] Bruneton | An open component model and its support in Java[END_REF] is a general model for developing componentbased systems. The model is sufficiently open to accommodate the needs of various application domains. For example, the model has been used to implement applications for grid computing [START_REF] Baude | From distributed objects to hierarchical grid components[END_REF], operating systems [START_REF] Fassino | Think: A software framework for component-based operating system kernels[END_REF], the GoTM transaction monitor [START_REF] Rouvoy | Abstraction of transaction demarcation in componentoriented platforms[END_REF], a version of the JORAM [START_REF]JORAM: Java open reliable asynchronous messaging[END_REF] JMS [START_REF]Java Message Service Specification Final Release 1[END_REF] server and the Speedo [START_REF] Alia | A middleware framework for the persistence and querying of java objects[END_REF] JDO [START_REF]Java Data Objects[END_REF] persistence framework.

AOKell, the framework presented in this paper, is an implementation of the Fractal component model for the Java programming language. Implementations exist in other programming languages: FracTalk in Smalltalk, Plasma in C++, Think [START_REF] Fassino | Think: A software framework for component-based operating system kernels[END_REF] in C, FractNet [START_REF] Escoffier | FractNet: An implementation of the Fractal component model for[END_REF] for the .NET platform. Two additional implementations in Java exist: Julia, which is the reference implementation, and ProActive, which is an implementation for grid computing. Information about these implementations can be found on the Fractal web site1 . As this will be explained in section 3, the added value of AOKell compared to these implementations is to be based on some concepts of aspect-oriented programming and to introduce the notion of a control component.

Fractal is a hierarchical and dynamic component model. The model is hierarchical in the sense that a component can be composite or primitive. A composite component contains other primitive or composite components. A primitive component is the smallest unit of code packaged as a component. The model is dynamic in the sense that the software architecture of a Fractal application can be manipulated at runtime: components can be created, containment hierarchies can be modified, and bindings (which are communication paths between components) can be set and unset. Components can be shared which means that a component can be included in several non nested composite components. This feature allows designing as components shared resources such as pools (for threads, network sockets, etc.).

Two dimensions can be isolated in the Fractal component model: the functional dimension and the control dimension.

Functional Dimension. The functional dimension is concerned with programming the core functionalities of the application. Besides the notion of a component, which can be primitive or composite, two main artefacts are provided to engineer the functional dimension: interface and binding.

An interface is an access point to a component and supports a finite set of operations. An interface can be of two kinds: server and client. Server interfaces correspond to the services provided by the components, whereas client interfaces correspond to the ones required by the components.

A binding is a communication path between two components, more precisely between a client interface and a server interface. Bindings can be dynamically set and unset to adapt, at runtime, the architecture of the application. The default semantics for the communication in a binding is that of a local method call. However, Fractal components can accommodate various other communication modes such as remote method call, asynchronous message passing, publish/subscribe.

Several other artefacts are provided such as the notion of a template. A template is an existing component assembly that can be cloned. Templates are a powerful means of instantiating, in just one step, complex software architectures containing several components and bindings.

The Fractal component model is associated with an API. The implementations of the model may conform to one of the levels defined in the Fractal Specifications [START_REF] Bruneton | The Fractal Component Model[END_REF], i.e. implementing the whole API is not mandatory. One of the tools worth noticing is Fractal ADL which is an architecture description language (ADL). Assemblies of components can be defined with this XML-based language, which is a front-end for the Fractal API. All architecture descriptions written with Fractal ADL are translated, either statically or dynamically, into series of calls to the API. These calls install the assemblies described with Fractal ADL.

The next piece of XML code illustrates the syntax of Fractal ADL. This sample defines one composite component (HelloWorld) and two primitive ones: client (line 3) and server (line 8). HelloWorld provides the run interface (line 2). This interface is bound (line 12) to the run interface provided by client.

The server component provides a s interface (line 9), which is bound (line 13) to the s interface requested (line 5) by client. This dimension provides the services to handle components. The range of services incorporated into the control dimension can vary from basic services such as managing component names, to lifecycle services, or to more complex services such as persistence or transaction services. The control dimension plays a role rather similar to the one played by containers in component models such as EJB [START_REF] Bodoff | The J2EE Tutorial[END_REF], except that this control dimension is open and fully programmable with Fractal. Two main artefacts are provided to engineer the control dimension: membrane and controller.

Each functional component is associated with a membrane. A membrane is composed of a set of smaller units, called controllers. A controller implements a particular control function and is associated to an interface. Controllers may either provide new functionalities to components, such as the ability to set or unset binding, or control existing functionalities, such as intercepting requests or blocking calls on a stopped component.

The Fractal Specifications [START_REF] Bruneton | The Fractal Component Model[END_REF] defines seven control interfaces. However this set is not closed and programmers can still develop their own control interfaces. Furthermore, although the signatures of these interfaces are defined in the specifications, their semantics is only weakly specified. The idea is to accommodate various implementations tailored to developers needs.

Among the seven predefined Fractal control interfaces, three are defined for managing component attributes, component bindings (with methods for setting, unsetting, retrieving and listing bindings), and component lifecycles (starting and stopping a component). Two additional control interfaces are available for managing containment hierarchies: the content control interface manages (adding, removing, listing) sub-components contained in a composite, and the super control interface manages the super components attached to a component. The factory control interface is available for cloning a template. Finally, the component control interface is available for retrieving the basic information about a component such as the list of interfaces. This interface is similar to the IUnknown interface of the COM component model.

Aspect-Oriented Programming

Aspect-Oriented Programming (AOP) [START_REF] Kiczales | Aspect-oriented programming[END_REF] is a software engineering technique for modularizing applications with many concerns. The general idea of AOP is that, whatever the domain, applications tend to be decomposed according to a dominant concern. The concerns which do not fit into this decomposition cannot be cleanly modularized.

This issue is illustrated with the well-known example of the Tomcat servlet server where some concerns such as XML parsing are cleanly modularized, whereas others, such as user session management, are implemented in many different classes. This leads to code that is said to be scattered (the implementation of a concern is scattered around several different locations), and tangled (a same piece of code mixes different concerns). AOP aims at providing solutions for untangling and unscattering applications. The notion of an aspect is available to modularize such concerns, which are said to be crosscutting. Several languages and frameworks such as AspectJ [START_REF] Kiczales | Getting started with AspectJ[END_REF], JBoss AOP [START_REF] Burke | It's the aspects[END_REF], AspectWerkz [START_REF] Bonér | AspectWerkz 2: An extensible aspect container[END_REF], JAC [START_REF] Pawlak | JAC: An aspect-based distributed dynamic framework[END_REF] or JAsCo [START_REF] Suvée | JAsCo: An aspect-oriented approach tailored for component based software development[END_REF] are available for programming aspect-oriented applications.

The AspectJ language has been chosen to develop the aspects needed by AOKell. This choice has been motivated by the fact that AspectJ is a stable and mature project, well integrated with widely used IDEs such as Eclipse. Also the fact that AspectJ currently provides features for compile-time and load-time weaving, allows covering a wide range of needs.

The AOKell Framework

AOKell is our implementation of the Fractal component model for the Java language. The functional dimension of a component-based application with AOKell strictly conforms to the Fractal model. By this way, AOKell can execute any Fractal system. AOKell differs from other existing implementations of the Fractal model by relying on aspects and components for engineering the control dimension, i.e. the services provided to functional components. By providing these two advanced software engineering techniques, we hope to promote flexibility and to allow adapting component-based applications to execution contexts with various and changing constraints.

Section 3.1 describe the structure of a component with AOKell and explain the role devoted to aspects. Next, section 3.2 presents the concepts which have been set up for "componentizing" the membranes.

Integrating the Control Dimension with Aspects

This section describes how aspects are used in AOKell to integrate control services into components. Section 3.2 will elaborate on the way these control functions are designed and implemented.

Component models such as EJB or CCM provide an architecture where components are hosted by containers that provide technical services. For example, the EJB specifications [START_REF]Enterprise Java Beans[END_REF] define services for managing security, transaction, persistence and lifecycle. Most of the time, this set of services is closed and hardcoded in the container. One exception is the JBoss J2EE application server [START_REF] Fleury | The JBoss extensible server[END_REF] where services can be wrapped and accessed with aspects defined with the JBoss AOP framework [START_REF] Burke | It's the aspects[END_REF].

The general idea illustrated with the case of the JBoss server is that aspects, while providing a way for modularizing crosscutting concerns, allow smoothly integrating a concern into applications. This leads to a common practise of AOP: the aspect modularizes a given concern, and either implements it directly, or delegates it to an external module. The separation of concern is almost optimal in the sense that the aspect is only concerned with the logic for integrating the concern into the application.

This pattern is used with AOKell to integrate the control logic into components. More precisely, each control function (a so-called controller in Fractal terms) is associated with an aspect which is responsible for integrating this logic into components. This solution is illustrated in figure 1. The integration performed by aspects relies on two mechanisms: feature injection and behavior extension. The first mechanism is known, in AspectJ, under the term inter-type declaration (ITD). With ITD, aspects can declare members (methods and/or fields) to be injected into the classes, in our case into component implementations. All existing control interfaces are injected with this ITD mechanism.

The second mechanism is known, in AspectJ, under the term code advising. Aspects define so-called pointcuts and advice code. Pointcuts pick out a set of join points, which corresponds to the points of the program execution where the aspect needs to be executed. The advice code is a piece of code which will be executed at these points. Code advising is used in AOKell to intercept operation calls and executions. For example, when controlling a component, the lifecycle controller may reject operation executions while the component has not been started. This feature is implemented by defining, in the aspect associated to the lifecycle controller, pointcuts and pieces of advice code.

Componentized Membranes

The previous section showed how aspects are used with AOKell to integrate the control logic into components. This section elaborates on the way this control logic is designed and implemented.

We have seen that the control logic is defined in the Fractal component model with a membrane composed of controllers, each one being specialized with a particular control mechanism (binding management, lifecycle, etc.). Far from being autonomous, these controllers need to collaborate to achieve the global control function assigned to the membrane. For example, when starting a composite component, the content of this composite needs to be traversed to recursively start sub-components2 . This implies that the lifecycle controller depends on the content controller. Several other similar dependencies exist between controllers. For clarity sake, we omit details for all these dependencies, which come from the semantics assigned to controllers. Readers can find them in [START_REF] Seinturier | AOKell: An aspect-oriented implementation of the Fractal specifications[END_REF].

However, the fact that these dependencies between controllers are hidden and not clearly expressed prevent developers from reusing controllers independantly. Our idea is to apply to the design of the control layer the same principles which were applied to the application layer: engineer the control with components. By "contractually specifying the interfaces" [START_REF] Szyperski | Component Software -Beyond Object-Oriented Programming[END_REF] of these control components, we hope to foster their reuse, to clarify the architecture of the membrane, and to ease the development of new ones. By supplying a component-based approach for engineering the control layer, we also hope to obtain gains in terms of flexibility: it will be easier to develop new control layers and thus to adapt applications to execution contexts with different characteristics in term of resource management (memory, threads, etc.).

As a consequence, AOKell is a framework where the concepts of a component, of an interface and of a binding are used to engineer the functional dimension and the control dimension as well. A control membrane with AOKell is a composite component providing the control interfaces associated to that membrane. This composite contains sub-components. Each sub-component implements the control functionality associated to a controller. As explained in the previous section, this component is associated to an aspect that integrates this control logic into application level components. Furthermore, these sub-components are bound together according to their dependencies. Figure 2 summarizes these elements. For clarity sake, the control membrane for the third component has been omitted. The most widely used control membrane in Fractal applications is the one associated with primitive components. The architecture of this membrane is illustrated in figure 3. This membrane provides five controllers, for managing the lifecycle (LC), the bindings (BC), the component name (NC), the super components (SC) and a controller (Comp) implementing the general Component interface, which is available for all Fractal components. As a matter of convention, provided interfaces are drawn on the left side of the components, and required interfaces are on their right side. Bindings represent communication paths between the controllers.

The architecture presented in figure 3 illustrates that the control function for primitive components is not simply realized by five isolated controllers, but is the result of the collaboration of these five controllers. Compared to a purely objectoriented approach, a component-based solution for the implementation of control New control membranes can be developed by extending existing ones, or simply by developing a whole new architecture. The benefits of engineering the control dimension with components have been experimented by implementing the Dream framework [START_REF] Leclercq | DREAM: a component framework for the construction of resource-aware, configurable middleware[END_REF]. Dream is a framework for developing middleware platforms with Fractal. The purpose is to ease the development of middleware by providing a library of component with advanced control functionalities. For example, Dream provides a membrane to define active components, i.e. components with threads or pools of threads to handle their requests. Based on these membranes, a version of the JORAM [START_REF]JORAM: Java open reliable asynchronous messaging[END_REF] JMS [START_REF]Java Message Service Specification Final Release 1[END_REF] server has been developed with Dream. Basically, implementing the Dream framework with AOKell consists in implementing a component-based version of the controllers and of defining the architecture of the membranes.

Performance Evaluation

This section evaluates the cost of running a component based application with AOKell. We are mainly interested in measuring the cost induced by the component framework and the componentization of membranes. To do so, we compare an application developed with AOKell with the same one developed with a pure object-oriented approach.

AOKell is written in Java and uses AspectJ 1.2.1. The AOKell source code size is 12,604 lines with 104 classes and 13 aspects3 . Other technical details can be found in [START_REF] Seinturier | AOKell: An aspect-oriented implementation of the Fractal specifications[END_REF]. AOKell has also been ported to the .NET platform [START_REF] Escoffier | FractNet: An implementation of the Fractal component model for[END_REF]. For this porting, AspectJ has been replaced by AspectDNG [29].

The tests are conducted with a simple application containing two components: a client component and a server component. The server component provides an interface with eight methods. Each method owns a different signature, either without parameters, or with primitive parameters, or with object references parameters, and/or with return types.

The measures are done on a 2Ghz Pentium 4 PC running Windows XP Pro and Sun JDK 1.5.0. A warm-up phase is performed before taking measures to avoid bootstrapping and class loading costs induced by the JVM. The test consists of series of calls emitted from the client component to the server component. In table 1, the figures correspond to the times taken by 8,000,000 calls (1,000,000 per method defined in the interface provided by the server component). The given figures correspond to the average value of 4 runs.

Table 1 presents the result obtained for this microbenchmark with five different techniques.

-Fractal/Julia: this is a component-based Fractal implementation of the microbenchmark. This version is linked with the Julia (version 2.1.1) reference implementation of the Fractal Specifications. -Fractal/AOKell: this Fractal version of the microbenchmark is linked with the AOKell implementation presented in this paper. These two last versions allow comparing a purely object-oriented implementation of the control dimension (Fractal/Julia) with an implementation where the control dimension is componentized (Fractal/AOKell). -Java: this is a pure object-oriented Java implementation. No components are involved. The client and the server are Java objects. This implementation gives a reference to evaluate the cost of running a componentized application. -AspectJ: this version is implemented with AspectJ version 1.2.1. No components are involved. The client and the server are Java objects. The server object is advised by an empty around advice. This version gives a clue on the cost of intercepting a method with AspectJ. -JBoss AOP: this version is implemented with the JBoss AOP [START_REF] Burke | It's the aspects[END_REF] (version 1.1.1) framework for dynamic AOP. No components are involved. The client and the server are Java objects. The server object is advised by an empty around advice. This version gives a clue on the cost of intercepting a method with JBoss AOP.

We saw in section 3.1 that controllers may, via aspects, either inject new features or modify the behavior of components by intercepting existing features. The microbenchmark reported in table 1 provides a measure of the interception cost of both Fractal versions.

Control without interception.

When compared to the Java implementation, the AOKell version is 21% costlier. The main reason is that the binding between the client and the server component is dynamic: before each call, the reference to the target server component must be resolved. This ensures that at any time the architecture is modified, the communication path between components will be updated accordingly. We believe that this penalty is acceptable compared to the benefits of having a component architecture dynamically updatable.

The figures given in table 1 show that AOKell performs better than Julia. We believe that this is due to the way controllers are implemented in Julia: a mixin mechanism is provided to modularize the different concerns addressed by each controller. When mixed together, these different pieces of code are assembled in a class which contains more indirections than the AOKell version where controllers have been implemented directly. Compared to Julia controllers, AOKell controllers are then less modular in terms of separation of concerns, but they are implemented as components (Julia controllers are objects) and they perform slightly better.

Control with interception. The interception costs reported in the second column of table 1 is due to the Fractal lifecycle controller. The purpose of this controller is to ensure that a call cannot be issued on a stopped component. This mechanism is implemented in Julia by engineering the bytecode of components with the ASM library [START_REF] Bruneton | ASM: A code manipulation tool to implement adaptable systems[END_REF], and in AOKell with AspectJ. When the interception mechanism is activated, the figures in table 1 shows that, compared to Julia, the overhead of running AOKell is 8.5%. This is mainly due to the use of AspectJ compared to that of ASM. In our opinion, this penalty is acceptable compared to the benefits of a high level language such as AspectJ compared to a bytecode engineering library such as ASM.

Related Work

This section compares AOKell to related projects.

OpenCOM. v1 [START_REF] Clarke | An efficient component model for the construction of adaptive middleware[END_REF] and v2 [START_REF] Coulson | A component model for building systems software[END_REF] is a component model with support for runtime dynamic reconfiguration. OpenCOM supports different kinds of deployment environments (e.g. operating systems, PDAs, embedded devices, network processors) and allows the particularities of those environments to be selectively hidden from or made visible to the OpenCOM programmer. At the application level, OpenCOM components provide interfaces and receptacles (required interfaces). Interceptor components can be associated with interfaces. The architecture of an OpenCOM application is introspectable and can be dynamically modified. Since v2, Open-COM provides the four following notions: capsule, caplet, loader, and binder. A capsule is a unit of scope that contains and manages the application components. A caplet is a sub-scope within a capsule that contains a subset of the application components. Binders and loaders are first-class entities that provide various ways of binding and loading components. Caplets, loaders and binders are implemented as components, and several implementations may be provided.

Compared to Fractal, capsules and caplets are similar to composite components. Binders and loaders are similar to Fractal controllers. By customizing the implementation of caplets, loaders and binders, programmers have the ability to adapt applications to different deployment environments. The approach is similar in AOKell where controllers are programmed as components. However, we can put forth three differences with OpenCOM. First, AOKell controllers are not restricted to a particular set of functionalities and can implement any kind of services. Second, controllers are components too, but we have gone a step further by introducing the notion of a component architecture at the control level. Finally, the integration of the control dimension and of the functional dimension is achieved with aspects.

Asbaco. [START_REF] Mencl | Microcomponent-based component controllers: A foundation for component aspects[END_REF], like AOKell, is a proposal for extending the membrane of the Fractal components. The authors introduce the term microcomponent to designate a component that implements a control functionality. Like AOKell, Asbaco microcomponents are associated with the same notions as regular components: they may own client and server interfaces, and bindings can be created between components. However, the API for manipulating bindings between microcomponents is different from the one available for regular components. With AOKell, this API is the same at both levels which leads to a model which is more symmetric. With Asbaco, integrating controllers and regular components is performed with a load-time mixin technique based on the ASM bytecode engineering library [START_REF] Bruneton | ASM: A code manipulation tool to implement adaptable systems[END_REF]. With AOKell, this integration is performed with AspectJ [START_REF] Kiczales | Getting started with AspectJ[END_REF]. We believe that the use of AspectJ leads to programs that are easier to write, understand and debug. Although we are currently using the compile-time weaving facility provided by AOKell, we plan to investigate the use of both the compiletime and the load-time features to make the weaving of the control dimension more dynamic.

FuseJ. [START_REF] Suvée | FuseJ: An architectural description language for unifying aspects and components[END_REF], and JAsCo [START_REF] Suvée | JAsCo: An aspect-oriented approach tailored for component based software development[END_REF], which is the previous project by the same team, is an architectural description language (ADL) that aims at unifying aspects and components. The FuseJ ADL introduces the notions of a gate and of a connector. A gate, much like an interface in Fractal, is a component communication point. Output and input gates may be defined. Gates are bound to methods provided or required by components. Connectors are responsible for declaratively specifying the architecture of the application. Two kinds of interactions may be specified by connectors: component-based and aspect-oriented. The former case is similar to a binding in Fractal and binds a required gate with a provided one. The latter allows defining an around advice.

Fractal/AOKell and FuseJ differ in the way aspects are used: with AOKell, aspects are only used as a technique for integrating the control and functional dimensions of the component model. The goal of FuseJ is to make aspects first class entities in the component-based programming model. In that sense, FuseJ is similar to another of our project, called FAC [START_REF] Pessemier | A model for developing component-based and aspect-oriented systems[END_REF], which has been build on top of AOKell.

Conclusion

This paper presented AOKell, which is a framework for developing componentbased applications. AOKell is an implementation of the Fractal Specifications [START_REF] Bruneton | The Fractal Component Model[END_REF] [START_REF] Bruneton | An open component model and its support in Java[END_REF]. AOKell is implemented in Java with the AspectJ [START_REF] Kiczales | Getting started with AspectJ[END_REF] aspect-oriented language. AOKell has been ported to the .NET platform [START_REF] Escoffier | FractNet: An implementation of the Fractal component model for[END_REF].

Fractal/AOKell provides a component model with two dimensions: the functional and the control dimension. The functional dimension is concerned with the development of application-level functionalities, while the control dimension is concerned with the supervision and the technical services required by the application. While this dichotomy can be found in other component models, e.g. EJB [START_REF] Bodoff | The J2EE Tutorial[END_REF] with the notion of a component and of a container, the originality of AOKell is to open the control dimension and to make it programmable. Furthermore, AOKell provides the same concepts for engineering both dimensions. The notions of a component, of a provided or required interface, and of a binding, are used both to engineer the functional dimension and the control dimension.

AOKell is reflective in the sense that the notion of a component is used both at the functional level and at the control level which can be seen as a kind of meta-level. With AOKell, components are controlled by other, so-called control components. One of the benefits of this approach is to provide a highly dynamic model. By modifying the components assemblies at the control level, programmers can modify the control of their application components. AOKell also enables the precise engineering of the control level. This allows adapting components to execution environments with various needs in term of control, and to foster the development of various forms of control such as the ones needed to program self healing components, self-testing components, or components carrying their proofs or their specifications.

With AOKell, application-level components are controlled by so-called membranes, which are assemblies of control components. Each control component provides a particular control function and may require the services provided by other control components. By componentizing membranes, we foster the reuse, the evolvability and the maintenance of control policies. We then facilitate the development of various control policies, and we obtain a general component model, which can be adapted to application domains with various needs in terms of resources (memory, thread, etc.) and of technical services.

The second originality of AOKell is to use an aspect-oriented approach [START_REF] Kiczales | Aspect-oriented programming[END_REF] to integrate the control and the functional dimension of our component model. Each control component is associated with an AspectJ [START_REF] Kiczales | Getting started with AspectJ[END_REF] aspect, which is responsible for introducing and supervising the functional component in order to meet the requirement of the control component. In terms of software engineering, this aspect orientation gives a highly expressive solution that facilitates the development and the debugging of the control logic.

As a matter of perspective, we plan to investigate the dynamicity of the relation between a component-based application and its componentized membrane. So far, we have been using the compile-time weaving facility of AspectJ for integration. A load-time weaving mode is also available with AspectJ. Furthermore, other dynamic frameworks are available such as AspectWerkz [START_REF] Bonér | AspectWerkz 2: An extensible aspect container[END_REF], JAC [START_REF] Pawlak | JAC: An aspect-based distributed dynamic framework[END_REF] or JAsCo [START_REF] Suvée | JAsCo: An aspect-oriented approach tailored for component based software development[END_REF] for runtime weaving. By investigating these solutions, we will be able to provide a fully dynamic model where any modification in the assembly of control components, including features related to interception, will be dynamically applied to the application components without recompilation.

I

  . Gorton et al. (Eds.): CBSE 2006, LNCS 4063, pp. 139-153, 2006. c Springer-Verlag Berlin Heidelberg 2006

Fig. 1 .

 1 Fig. 1. Structure of a component with AOKell

Fig. 2 .

 2 Fig. 2. AOKell component layers

Fig. 3 .

 3 Fig. 3. Primitive membrane: control level for primitive components

  The control dimension of the Fractal component model is concerned with the supervision and the management of functional components.

	1 <definition name="HelloWorld">
	2	<interface name="run" signature="Runnable" role="server"/>
	3	<component name="client">
	4	<interface name="run" signature="Runnable" role="server"/>
	5	<interface name="s" signature="IService" role="client"/>
	6	<content desc="ClientImpl"/>
	7	</component>
	8	<component name="server">
	9	<interface name="s" signature="IService" role="server"/>
	10	<content desc="ServerImpl"/>
	11	</component>
	12	<binding client="this.run" server="client.run"/>
	13	<binding client="client.s" server="server.s"/>
	14 </definition>
	Control Dimension.

Table 1 .

 1 Cost of invoking and executing an operation (x 8,000,000)

		Operation execution time
		without interception	with interception
	Pure Java 1.5.0	178ms
	AspectJ 1.2.1		209ms
	Fractal/Julia 2.1.1	237ms	515ms
	Fractal/AOKell 1.1	215ms	559ms
	JBoss AOP 1.1.1		1046ms

http://fractal.objectweb.org

Note that this is not a formal obligation. One may design a control function where the starting is not recursive.

AOKell can be downloaded from http://fractal.objectweb.org

Acknowledgments

This work is partially funded by France Telecom under the external research contract #46131097.

We thank Romain Rouvoy for many discussions about AOKell and for numerous bug reports, Philippe Merle and Renaud Pawlak for their valuable comments about this article.


Fabio Tanturri

PFAFFIAN REPRESENTATIONS OF CUBIC SURFACES

Keywords: 2010 Mathematics Subject Classification. Primary: 14Q10; Secondary: 14J99 Pfaffian representations, cubic surfaces, ACM sheaves, determinantal varieties

Let K be a field of characteristic zero. We describe an algorithm which requires a homogeneous polynomial F of degree three in K[x 0 , x 1 , x 2 , x 3 ] and a zero a of F in P 3 K and ensures a linear Pfaffian representation of V(F ) with entries in K[x 0 , x 1 , x 2 , x 3 ], under mild assumptions on F and a. We use this result to give an explicit construction of (and to prove the existence of) a linear Pfaffian representation of V(F ), with entries in K [x 0 , x 1 , x 2 , x 3 ], being K an algebraic extension of K of degree at most six. An explicit example of such a construction is given.

Introduction

Let K be a field of characteristic zero and let X be the hypersurface in P n K defined by a polynomial F ∈ K[x 0 , x 1 , . . . , x n ]. One may ask whether the polynomial F k is the determinant of a matrix M with entries in K[x 0 , x 1 , . . . , x n ], for some integer k.

For k = 1, such a matrix M is said to be a determinantal representation of X. If the entries are linear forms, then the determinantal representation is said to be linear. Linear determinantal representations of curves and surfaces of small degree are a classical subject and date back to the middle of nineteenth century; see for example [START_REF] Beauville | Determinantal hypersurfaces[END_REF], [START_REF] Dolgachev | Classical algebraic geometry: a modern view[END_REF] for a historical account.

A relevant class of matrices with determinant F 2 are Pfaffian representations, that is, skew-symmetric matrices whose Pfaffian is F , up to constants. Let us recall the following definition. Definition 1.0.1 (Pfaffian). Let T = (t ij ) be a skew-symmetric matrix of even size 2n with entries in a ring R. Then its determinant is the square of an element in R, called the Pfaffian of T . If we denote by T ij the square matrix of order (2n -2) obtained by deleting from T the i-th and j-th rows and columns, the Pfaffian is defined recursively as [START_REF] Abhyankar | Cubic surfaces with a double line[END_REF] Pf(T ) = j<2n (-1) j t 2n,j Pf(T 2n,j )

if n ≥ 2 t 12 if n = 1.
Pfaffian representations are a generalization of determinantal representations, since from a determinantal representation M we get a Pfaffian representation 0 M -M 0 .

The references about Pfaffian representations are very recent, even though some general results were probably well-known to the experts before. In [START_REF] Beauville | Determinantal hypersurfaces[END_REF], Beauville collects many results about determinantal and Pfaffian representations, giving criteria for the existence of linear Pfaffian representations of plane curves, surfaces, threefolds and fourfolds. The fact that a generic cubic threefold can be written as a linear Pfaffian had been proved by Adler [2, Apx.V], with K = K. With the same method used by Adler, in [START_REF] Iliev | Quartic 3-fold: Pfaffians, vector bundles, and half-canonical curves[END_REF] it is proved that a general quartic threefold admits a linear Pfaffian representation. A non-computer-assisted proof of this fact can be found in [START_REF] Brambilla | Moduli spaces of rank-2 ACM bundles on prime Fano threefolds[END_REF]. Again in the case K = K, linear Pfaffian representations of plane curves and their elementary transformations are the subject of [START_REF] Buckley | Plane curves as Pfaffians[END_REF] and [START_REF] Buckley | Elementary transformations of Pfaffian representations of plane curves[END_REF]; in [START_REF] Faenzi | Vector bundles and low codimensional subvarieties: state of the art and recent developments[END_REF] and [START_REF] Chiantini | On general surfaces defined by an almost linear Pfaffian[END_REF], respectively almost quadratic and almost linear Pfaffian representations of surfaces are considered. In [START_REF] Coskun | Pfaffian quartic surfaces and representations of clifford algebras[END_REF] it is proved that every smooth quartic surface admits a linear Pfaffian representation, a result which strengthens the Beauville-Schreyer's one in [START_REF] Beauville | Determinantal hypersurfaces[END_REF].

In this paper we will use the following two definitions.

Definition 1.0.2. Let F ∈ K[x 0 , x 1 , . . . , x n ] define the hypersurface X and let K be a field containing K. A linear Pfaffian K -representation of X is a skew-symmetric matrix whose Pfaffian is F , up to constants, and whose entries are linear forms in K [x 0 , x 1 , . . . , x n ].

Definition 1.0.3 (K-point). If a point a ∈ P n K admits a representative a ∈ A n+1 K , then it will be called a K-point.

By convention, hypersurfaces will be considered in P n K, being K the algebraic closure of K. In this way, X is non-empty even if its defining polynomial

F ∈ K[x 0 , x 1 , . . . , x n ] has no zero in A n+1 K , that is, if X has no K-points.
According to these notations, in [START_REF] Beauville | Determinantal hypersurfaces[END_REF] Beauville provided a proof of the following theorem: Theorem 1.0.4. Let S be a surface of degree d in P 3 K, without singular K-points. The following conditions are equivalent:

(1) S admits a linear Pfaffian K-representation;

(2) S ∩ P 3 K contains a finite, reduced, arithmetically Gorenstein subscheme Z of index 2d -5, not contained in any surface of degree d -2. Moreover, the degree of Z is 1 6 d(d -1)(2d -1). Here a finite, reduced subscheme Z of degree c in P n K , with ideal I Z ⊂ K[x 0 , x 1 , . . . , x n ], is said to be arithmetically Gorenstein (AG for short) if K[x 0 , x 1 , . . . , x n ]/I is a Gorenstein ring. For such a scheme, its index is the (unique) integer N such that

(2) dim (R/I Z ) p + dim (R/I Z ) N -p = c for all p ∈ Z.
The proof of Theorem 1.0.4 is based on considering the rank-two vector bundle coker(M ) and its scheme Z associated via the Hartshorne-Serre correspondence. As remarked by Beauville, another way to prove the existence of a Pfaffian representation is via the Buchsbaum-Eisenbud Structure Theorem in [START_REF] Buchsbaum | Gorenstein ideals of height 3[END_REF], which we state after the following definition. (1) Let n ≥ 3 be an odd integer, and let M be a free module of rank n over a Noetherian local ring R with maximal ideal J. Let f : M / / M * be an alternating map of rank n -1 whose image is contained in J • M * and let I = Pf n-1 (f ) be the ideal generated by the (n -1) × (n -1) Pfaffians of the matrix representing f . If depth(I, R) = 3, then I is Gorenstein, and the minimal number of generators of I is n. (2) Every Gorenstein ideal I of R with depth(I, R) = 3 arises as in 1.. Indeed, identifying R with K[x 0 , x 1 , x 2 , x 3 ], an AG subscheme Z as those arising in Theorem 1.0.4 satisfies the hypotheses of (2) in Theorem 1.0.6: Z has a Gorenstein homogenous ideal I Z by definition and by a theorem of Serre [START_REF] Bass | On the ubiquity of Gorenstein rings[END_REF]. The fact that depth(I Z , R) = 3 follows from (3) and hd(R/I Z ) = 3, which is true since the homogeneous coordinate ring of a finite set of points is Cohen-Macaulay and from the Auslander-Buchsbaum formula [15, ex. 18.15, ex. 19.8].

Given Z as in Theorem 1.0.4, one can apply Theorem 1.0.6: I Z is generated by the (2d -2) × (2d -2) principal Pfaffians extracted from a skew-symmetric (2d -1) × (2d -1) matrix T with linear forms as entries. Then the surface admits a Pfaffian K-representation

(4) T -C t C 0 ,
where C is a suitable 1 × (2d -1) matrix with linear forms as entries, which can be found by formula [START_REF] Abhyankar | Cubic surfaces with a double line[END_REF] (see also subsection 2.2).

In this paper we focus on case d = 3. If K = K, then by [START_REF] Davis | Gorenstein algebras and the Cayley-Bacharach theorem[END_REF] a set of five points in P 3 K is an AG scheme if and only if they are in general position, i.e. no four of them are on a plane. This fact, together with Theorem 1.0.6, implies Corollary 1.0.7. If K = K, every smooth cubic surface in P 3 K admits a linear Pfaffian representation [START_REF] Beauville | Determinantal hypersurfaces[END_REF]. This result has been generalized in [START_REF] Fania | On the Hilbert scheme of Palatini threefolds[END_REF] as follows.

Proposition 1.0.8. If K = K, every cubic surface in P 3 K admits a linear Pfaffian representation.

We study how to construct explicitly a linear Pfaffian K-representation, where K is not necessarily algebraically closed, starting from the least amount of initial data possible. We will show that, in general, it is sufficient to know a K-point on S. Our contribution is the following: we prove Theorem 1.0.9. Let S be a cubic surface, neither reducible nor a cone, whose equation is

F ∈ K[x 0 , x 1 , x 2 , x 3 ] 3 . Given a K-point a 1 , which is not a T-point -in the sense of Definition 3.1.1 -it is possible to construct explicitly a linear Pfaffian K-representation of S.
The same method can be used to prove a weaker result, if a 1 is not given: Proposition 1.0.10. Let S be a cubic surface, neither reducible nor a cone, whose equation is F ∈ K[x 0 , x 1 , x 2 , x 3 ] 3 . Then it is possible to construct explicitly a Pfaffian K -representation of S, where K is an algebraic extension of degree [K : K] ≤ 3. Moreover, if K ⊆ R, then also K can be chosen so.

On one hand, these results strengthen one implication of Theorem 1.0.4 and give a bound for the degree of algebraic extension required to produce a linear Pfaffian representation. On the other hand, they are constructive: it is possible to implement an algorithm which produces a linear Pfaffian representation, provided the requested inputs. After discussing the cases of reducible surfaces and cones, we are able to prove Theorem 1.0.11, which strengthens Proposition 1.0.8. Theorem 1.0.11. Every cubic surface in P 3 K, with equation F ∈ K[x 0 , x 1 , x 2 , x 3 ] 3 , admits a Pfaffian K -representation, K being an algebraic extension of K of degree [K : K] ≤ 6. Moreover, it is possible to explicitly realize such a representation. This paper is structured as follows: in section 2, we retrace the proof of Theorem 1.0.6 and we use it to construct a skew-symmetric matrix T as in [START_REF] Buckley | Elementary transformations of Pfaffian representations of plane curves[END_REF], whose Pfaffians generate the ideal of the four fundamental points and the unit point in P 3 . This enables us to produce Algorithm 2.2.1, whose inputs are five points in general position on a surface S and whose output is a linear Pfaffian representation of S. In section 3, we make use of the tangent plane process, a classical argument (see, for example, [START_REF] Segre | On the rational solutions of homogeneous cubic equations in four variables[END_REF]); starting from a K-point a 1 on an irreducible surface which is not a cone, we show that it is always possible to find four other points on the surface such that all the five points are in general position, provided that a 1 satisfies a mild condition.

In section 4 we summarize the previous results in Theorem 1.0.9 and Proposition 1.0.10. Then we discuss the case of reducible surfaces and the case of cones, so to prove Theorem 1.0.11. An example of the construction of a Pfaffian representation is finally given.

From five points to a Pfaffian representation

In this section, we make explicit the construction of the proof of Theorem 1.0.6, in the particular case of the ideal I of the four fundamental points and the unit point [START_REF] Brambilla | Moduli spaces of rank-2 ACM bundles on prime Fano threefolds[END_REF] [1 : 0 : 0 : 0], [0 : 1 : 0 : 0], [0 : 0 : 1 : 0], [0 : 0 : 0 : 1], [1 : 1 : 1 : 1] in P 3 Q . This produces the skew-symmetric matrix T in (8), whose Pfaffians generate I; we will make use of T to implement Algorithm 2.2.1, which produces a linear Pfaffian K-representation of a cubic surface S starting from five K-points in general position on S. From now on, we will consider only linear Pfaffian representations.

2.1. An explicit construction. For the sake of completeness, we recall briefly the constructions made in [START_REF] Buchsbaum | Gorenstein ideals of height 3[END_REF] in the proof of Theorem 1.0.6.

Let R be the ring of polynomials K[x 0 , x 1 , x 2 , x 3 ] and let I be a Gorenstein ideal with depth(I, R) = 3. From a minimal free resolution of

I (6) F : 0 / / F 3 d3 / / F 2 d2 / / F 1 d1 / / F 0 / / R/I / / 0 ,
where

F 0 ∼ = R ∼ = F 3
, it is possible to make a change of basis in F 1 such that the map F 2 / / F 1 is alternating. This can be found by equipping this resolution with a graded commutative algebra, the symmetric square of F

s 2 (F ) = (F ⊗ F )/M ,
where M is the graded submodule of F ⊗ F generated by the elements of the set

f ⊗ g -(-1) (deg f )(deg g) g ⊗ f | f, g homogeneous elements of F .
By convention, an element f has degree i if and only if it belongs to F i ; the degree of (f ⊗ g) is simply deg(f ) + deg(g). The differential is inherited from F as follows:

d(f ⊗ g) = d f ⊗ g + (-1) deg f f ⊗ d g.
The symmetric square s 2 (F ) is a complex of projective R-modules, canonically isomorphic to F in degree 0 and 1. Therefore, there exists a map of complexes Φ : s 2 (F ) / / F which lifts up these two isomorphisms and it can be chosen so that the restrictions of Φ to

F 0 ⊗ F k are the isomorphisms F 0 ⊗ F k ∼ = F k . The multiplication in s 2 (F ) is given by f • g = Φ(f ⊗ g), where f ⊗ g is the class of f ⊗ g modulo M . Since F 3 ∼ = R, this multiplication induces a map F k ⊗ F 3-k / / R
, which turns to be a perfect pairing.

This can be viewed as an isomorphism between F 1 and F 2 * , which makes the composition

F 2 / / F 1 / / F * 2 an alternating map.
Let us consider the special case where I is the ideal of the points [START_REF] Brambilla | Moduli spaces of rank-2 ACM bundles on prime Fano threefolds[END_REF]. We have the free resolution [START_REF] Brundu | Parametrization of the orbits of cubic surfaces[END_REF], with

F 1 ∼ = R 5 ∼ = F 2 . We have to develop Φ 3 : s 2 (F ) 3 / / F 3 in the diagram (7)
. . .

/ / s 2 (F ) 3 Φ3 d 3 / / s 2 (F ) 2 Φ2 d 2 / / s 2 (F ) 1 Φ1 d 1 / / s 2 (F ) 0 Φ0 π / / R/I / / 0 0 / / F 3 d3 / / F 2 d2 / / F 1 d1 / / F 0 π / / R/I / / 0 We choose the ordered basis of s 2 (F ) 2 ∼ = (F 0 ⊗ F 2 ) ⊕ (∧ 2 F 1 ) to be formed by the classes modulo M of 1 ⊗ f 2 1 , 1 ⊗ f 2 2 , . . . , 1 ⊗ f 2 5 , f 1 1 ⊗ f 1 2 , f 1 1 ⊗ f 1 3 , . . . , f 1 4 ⊗ f 1 5 , where the f 1 i s are a basis of F 1 and the f 2 j s are a basis of F 2 . A similar convention is fixed for s 2 (F ) 3 ∼ = (F 0 ⊗ F 3 ) ⊕ (F 1 ⊗ F 2 ).
After a computation with [CoCoA], we consider the maps of diagram ( 7) to be

d 3 =       x 0 x 1 -x 1 x 3 x 1 x 2 -x 2 x 3 -x 0 x 2 + x 1 x 2 -x 1 x 3 + x 2 x 3 x 0 x 3 -x 1 x 3       , d 1 t = d 1 t =       x 1 x 3 -x 2 x 3 x 0 x 3 -x 2 x 3 x 1 x 2 -x 2 x 3 x 0 x 2 -x 2 x 3 x 0 x 1 -x 2 x 3       , d 2 =       -x 2 x 0 0 0 x 2 x 2 -x 1 x 1 0 0 x 3 -x 3 x 3 x 0 -x 3 0 -x 3 x 3 0 -x 1 + x 3 x 1 0 0 -x 3 0 -x 2       .
The isomorphisms Φ 0 and Φ 1 are represented by identity matrices. With straightforward computations we get the matrices d 2 and d 3 . By trials, we can lift up Φ 1 by finding matrices Φ 2 and Φ 3 such that the diagrams

s 2 (F ) 2 Φ1•d 2 Φ2
| | y y y y y y y y y

F 2 d2 / / Im(d 2 ) / / 0 s 2 (F ) 3 Φ2•d 3 Φ3
| | y y y y y y y y y

F 3 d3 / / Im(d 3 ) / / 0 commute. A possible choice for Φ 2 is       I 5 -x 3 x 1 0 0 x 3 x 3 -x 0 x 3 0 -x 1 0 -x 3 0 -x 2 -x 1 0 -x 2 0 0 0 x 2 0 -x 2 -x 2 -x 1 -x 2 -x 2 -x 0 0 x 2 x 2 0 0 0 0 x 3 x 3 x 3 -x 2 -x 1 0 0 x 3 x 3 x 3 x 3 x 3 x 3 0 -x 1 -x 0       .
This choice is indeed the unique with linear forms as entries in the right block, since the syzygies are of degree two. The map Φ 3 turns to be

I 1 0 0 0 -1 0 0 0 0 -1 1 0 1 0 0 0 0 1 -1 0 0 1 0 0 -1 0 .
The isomorphism resulting from Φ 3 is

F 1           0 0 0 0 1 0 0 1 1 0 0 0 0 -1 0 -1 -1 0 0 -1 0 1 0 0 0           / / F 2 *
and, with respect to this change of basis, the map d 2 turns to be alternating, represented by the skew-symmetric matrix

(8) T =       0 0 -x 3 0 -x 2 0 0 x 3 x 0 -x 1 x 1 x 3 -x 3 0 x 1 -x 3 -x 1 0 -x 0 + x 1 -x 1 + x 3 0 0 x 2 -x 1 x 1 0 0       .
It is easy to verify that the 4 × 4 principal Pfaffians of T -listed in (9) -are exactly the five generators of I, that is, the entries of d 1 .

2.2.

From five points to a Pfaffian representation: an algorithm. The procedure just shown can be applied as long as we have the ideal of a set X of five points in general position on a cubic surface S. Due to the classical fact that two sets of five points in general position in P 3 are projectively equivalent, instead of repeating the previous construction it is also possible to realize a Pfaffian representation in the following way. By solving a linear system, we can find the matrix A of the projectivity which maps X to the five points [START_REF] Brambilla | Moduli spaces of rank-2 ACM bundles on prime Fano threefolds[END_REF]. Replacing x 0 , x 1 , x 2 , x 3 in (8) with the columns of the matrix x 0 x 1 x 2 x 3 • A t , we get a matrix T whose Pfaffians P i generate the ideal of X.

Finding a Pfaffian representation is then straightforward: if S = V(F ), then F belongs to the ideal of X. Therefore, one can find five linear forms L i such that

F = 5 i=1 (-1) i+1 L i P i . Setting C = L 1 L 2 L 3 L 4 L 5
and by (1), we get a Pfaffian representation of the form (4). We summarize the whole procedure in Algorithm 2.2.1, presented in pseudocode, where T = T(x 0 , x 1 , x 2 , x 3 ) in ( 8) is seen as a matrix depending on four variables, the Pfaffians of which are Require: F ∈ K[x 0 , x 1 , x 2 , x 3 ] 3 and a 1 , a 2 , a 3 , a 4 , a 5 K-points in general position on S = V(F ) Ensure: M , a Pfaffian K-representation of S depending on some arbitrary parameters α i,j 1: choose a representative

Pf 1 (T)(x 0 , x 1 , x 2 , x 3 ) = x 1 (x 0 -x 3 ) Pf 2 (T)(x 0 , x 1 , x 2 , x 3 ) = x 2 (x 3 -x 1 ) Pf 3 (T)(x 0 , x 1 , x 2 , x 3 ) = x 2 (x 1 -x 0 ) Pf 4 (T)(x 0 , x 1 , x 2 , x 3 ) = x 3 (x 1 -x 2 ) Pf 5 (T)(x 0 , x 1 , x 2 , x 3 ) = x 3 (x 0 -x 1 ). (9
a i = (a i 0 , a i 1 , a i 2 , a i 3 ) ∈ A 4 K of a i for every 1 ≤ i ≤ 5 2: compute the solution λ = (λ 1 , λ 2 , λ 3 , λ 4 ) of the linear system     a 1 0 a 2 0 a 3 0 a 4 0 a 1 1 a 2 1 a 3 1 a 4 1 a 1 2 a 2 2 a 3 2 a 4 2 a 1 3 a 2 3 a 3 3 a 4 3         λ 1 λ 2 λ 3 λ 4     =     a 5 0 a 5 1 a 5 2 a 5 3    
3: compute the change of basis matrix A from (λ i a i ) 1≤i≤4 to the standard basis of A 4 K , so that

λ i A     a i 0 a i 1 a i 2 a i 3     =     δ 1 i δ 2 i δ 3 i δ 4 i    
for every 1 ≤ i ≤ 4

4: for i = 1 to 4 do 5:

set z i-1 as the i-th row of the column vector

A •     x 0 x 1 x 2 x 3     6: set T(x 0 , x 1 , x 2 , x 3 ) as in (8) 7: set T = T(z 0 , z 1 , z 2 , z 3 ) 8:
for i = 1 to 5 do 9:

set P i = Pf i (T)(z 0 , z 1 , z 2 , z 3 ) as in [START_REF] Buckley | Plane curves as Pfaffians[END_REF] 10:

set L i = 3 j=0 α i,j x j 11: set G = F -5 i=1 (-1) i+1 L i P i 12: compute solutions of the linear system given by equaling the coefficients of G to zero, α i,j as unknowns 13: substitute the solutions in L i 14: set M as the matrix

        T L 1 L 2 L 3 L 4 L 5 -L 1 -L 2 -L 3 -L 4 -L 5 0         line 9
, not on the choice of F . Regardless to this projectivity, its rank is 15.

Since for any choice of F ⊃ {a 1 , a 2 , a 3 , a 4 , a 5 } a solution of this linear system does exist, the "Pfaffian representation depending on some parameters" ensured by Algorithm 2.2.1 turns to be a five-dimensional linear space of Pfaffian representations.

2.2.1.

Classes of equivalent representations. We recall that two Pfaffian K-representations M and M are said to be equivalent if and only if there exists X ∈ GL K (6) such that M = XM X t . Let coker(M ), coker(M ) be the cokernel sheaves of M, M , seen as maps O 6 P 3 (-1) / / O 6 P 3 . Then from [4, (2.3)] it follows that M, M are equivalent if and only if coker(M ) ∼ = coker(M ). In this way the study of equivalence classes of Pfaffian representations of a cubic surface S is strongly linked to the study of certain sheaves on S. Remark 2.2.4. Let Z be a fixed set of five points in general position on a surface S without singular K-points and consider the Pfaffian representations given by Algorithm 2.2.1, which are a five-dimensional linear space by Remark 2.2.3. It turns out that all these representations are equivalent. Indeed, by [4, (7.1)], up to automorphism there exists only one pair (E, s), with E rank-two vector bundle on S and s ∈ H 0 (S, E), such that Z is the zero locus of s. In addition, these classes of pairs [(E, s)] are in bijection with the equivalence classes of the pairs [(M, s)], where E = coker(M ) and s ∈ H 0 (P 3 , O 6

P 3 ) corresponds to s via the isomorphism H 0 (P 3 , O 6

P 3 ) ∼ = H 0 (S, E). It follows that all the representations produced in the algorithm belong to a unique equivalence class.

It is worth noting that, as Z varies among the possible sets of five K-points in general position on a surface S without singular K-points, Algorithm 2.2.1 is surjective onto the possible Pfaffian K-representations of S, and therefore onto their equivalence classes. Indeed, as shown in [4, (7.2)], a general global section of E = coker(M ) has five points in general position as its zero locus Z and therefore M can be produced via the algorithm with input Z.

In [START_REF] Buckley | Elementary transformations of Pfaffian representations of plane curves[END_REF], elementary transformations were used to construct non-equivalent Pfaffian representations of curves starting from a given one. This technique can be used in the case of surfaces as well.

Remark 2.2.5. The bijection between Pfaffian representations M and sheaves E = coker(M ) tells us more, when dealing with the algebraic closure K. Let S 3 / GL(6) be the set of equivalence classes of the 6×6 skew-symmetric matrices of linear forms in P 3 K; let pf : S 3 / GL(6) / / |O P 3 K (3)| be the map which associates to a class [M ] the cubic surface in P 3 K with equation Pf(M ). As noticed in [START_REF] Fania | On the Hilbert scheme of Palatini threefolds[END_REF], for the general S the fiber pf -1 (S) can be identified with an open subset of the moduli space of simple rank-two vector bundles E on S with c 1 (E) = O S (2), c 2 (E) = 5. Since the (projective) dimension of S 3 / GL(6) is 59 -35 = 24 and the dimension of |O P 3 K (3)| is 19, then for the general S we have a five-dimensional space of essentially different Pfaffian K-representations of S.

The space S 3 / GL(6) has been recently considered in [START_REF] Han | Pfaffian bundles on cubic surfaces and configurations of planes[END_REF], in relation to the space of pairs (S, Π), being Π a complete pentahedron inscribed in S.

Constructing five points on a surface

Given an equation F ∈ K[x 0 , x 1 , x 2 , x 3 ] 3 , in general it is not easy to find a zero of F in A 4 K . For example, if K = Q, the problem of the existence of rational points on cubic surfaces, reliable to diophantine equations, has been strongly faced in the last century (see, for example, [START_REF] Mordell | Diophantine equations[END_REF], [START_REF] Segre | On the rational solutions of homogeneous cubic equations in four variables[END_REF] and the more recent [START_REF] Manin | Cubic forms, volume 4 of North-Holland Mathematical Library[END_REF]). Our next aim is to weaken the required inputs of Algorithm 2.2.1.

3.1.

From one point to five points. It is well known that from a general choice of a K-point on a general cubic surface with equation in K[x 0 , x 1 , x 2 , x 3 ] 3 it is possible to find infinitely many others K-points on the surface; this can be performed by using the tangent plane process, a classical argument (for example, see [START_REF] Segre | On the rational solutions of homogeneous cubic equations in four variables[END_REF]). It starts by taking the tangent plane to the cubic surface S at a smooth point P . T P S cuts S in a curve of degree three, for which P is a singular point. A line through P , lying on the tangent plane, intersects S twice in P , while the third intersection is generically different and gives us another K-point on S.

We want to get rid of this "generality". Theorem 3.1.3 will show how, under reasonable hypotheses, the tangent plane process applied to a starting K-point can be repeated to produce four other K-points on S, such that the five points are all together in general position. This will prove, under these hypotheses, that we only need a K-point on S to construct an explicit Pfaffian K-representation. Definition 3.1.1. A point P ∈ S will be called a T-point for S if P is smooth for S and T P S ∩ S is set-theoretically union of lines.

Let us observe that the so-called Eckardt points, i.e. smooth points P with T P S ∩ S made up of three lines through P , are T-points. Moreover, a smooth points P is a T-point if and only if T P S is a tritangent plane. In general, for a T-point P one expects T P S ∩ S to be union of three distinct lines, but it is possible to have one line with multiplicity three or two lines, one of them with multiplicity two. The role of T-points will be clear in a while. Let us remark that, for a smooth point P which is not a T-point, T P S ∩ S is either an irreducible cubic curve with P as a singular point, or union of a line through P and a smooth conic passing through P .

Remark 3.1.2. Let P be a T-point for S. If T P S ∩ S is a line r with multiplicity three, or union of a line r with multiplicity two and another line, then r is union of singular points for S and T-points for S sharing the same tangent plane.

Theorem 3.1.3. Let S be an irreducible cubic surface which is not a cone, whose equation is F ∈ K[x 0 , x 1 , x 2 , x 3 ] 3 . Given a K-point a 1 on S which is not a T-point -in the sense of Definition 3.1.1 -it is possible to explicitly construct four other K-points on S such that the five points together are in general position.

The constructive proof, which requires some steps and preliminary lemmas, will be the subject of next subsection. In subsection 4.1 we will see how this construction can be adapted if some of the hypotheses are missing.

Let us consider

F = F (x 0 , x 1 , x 2 , x 3 ) ∈ K[x 0 , x 1 , x 2 , x 3 ] 3 .
Then we set, for every a = (a 0 , a 1 , a 2 , a 3 ) ∈ A 4 K:

• P 1,a (x 0 , x 1 , x 2 , x 3 ) = 3 i=0 a i ∂F ∂xi ; • P 2,a (x 0 , x 1 , x 2 , x 3 ) = 3 i=0 x i ∂F ∂xi (a).
They are the equations of the first polar and the second polar of a = [a 0 : a 1 : a 2 : a 3 ] with respect to the surface S = V(F ). If a is smooth, P 2,a defines T a S. If x = (x 0 , x 1 , x 2 , x 3 ), for every a ∈ A 4 K we have: ( 10)

F (a + tx) = F (a) + tP 2,a (x) + t 2 P 1,a (x) + t 3 F (x).
We will consider the first and the second polar V(P 1,a ) and V(P 2,a ), for a ∈ P 3 K, as hypersurfaces in P 3 K.

Lemma 3.2.1. Let a be a singular point on a cubic surface S, whose equation is

F ∈ K[x 0 , x 1 , x 2 , x 3 ] 3 .
Let us assume that S is neither reducible, nor a cone. Then there are at most six lines through a lying on S.

Proof. By [START_REF] Chiantini | On general surfaces defined by an almost linear Pfaffian[END_REF], if a point x ∈ S∩V(P 1,a ), also the whole line through a and x does. P 1,a is not the zero polynomial since S is not a cone, moreover F is irreducible: this means that the intersection S ∩ V(P 1,a ) is transversal. It is therefore a curve of degree six, union of lines through a. Lemma 3.2.2. Let S be an irreducible, cubic surface which is not a cone and let us assume a ∈ S is not a T-point.

(1) If a is smooth, then on T a S there are only finitely many T-points for S.

Moreover V(P 1,a ) ∩ T a S is union of at most two lines through a and any line through a lying on S lies also on V(P 1,a ) ∩ T a S. (2) If a is singular, then point 1. still holds if we replace T a S with a plane π through a, for all but finitely many choices of π.

Proof. We distinguish two classes of T-points: let us call A the set of T-points P for which T P S ∩ S is union of three distinct lines, A the set of T-points not in A.

Either S contains finitely many lines or infinitely many ones. In the first case, note that A is a finite set, since mutual intersections of lines on S are finite in number;

A is contained in a union of lines on S, by Remark 3.1.2.

If S contains infinitely many lines, then it is well-known (for example, [START_REF] Conforto | Le superficie razionali[END_REF]) that S is either reducible, an irreducible cone or a ruled cubic with a double line. By hypotheses the first two cases cannot occur. Moreover, a cubic surface with a double line which is not a cone is projectively equivalent to either V(

x 2 0 x 3 + x 0 x 1 x 2 + x 3 1 ) or V(x 2 0 x 2 + x 2 1
x 3 ) (see, for example, [START_REF] Abhyankar | Cubic surfaces with a double line[END_REF]). The study of these two cases leads to Table 1 andTable 2.

If S is projectively equivalent to V(x 2 0 x 3 + x 0 x 1 x 2 + x 3 1 ), then Table 1 shows that coordinates of a T a S ∩ S (if smooth)

[1 : s : t : -s 3 -st] x 0 (-2s 3 -st) + x 1 (3s 2 + t) + sx 2 + x 3 = 0 (x 0 s -x 1 )(2x 2 0 s 2 -x 0 x 1 s + tx 2 0 -x 0 x 2 -x 2 1 ) = 0 [0 : 0 : s : t] singular Table 1. points on S = V(x 2 0 x 3 + x 0 x 1 x 2 + x 3 1 ).
coordinates of a restrictions T a S ∩ S (if smooth)

[1 : t : -t 2 s : s] s = 0 = t line and irreducible conic

[1 : t : 0 : 0] t = 0 x 2 + x 3 t 2 = 0 x 3 (x 0 t ± x 1 ) = 0 [1 : 0 : 0 : s] x 2 = 0 x 2 1 x 3 = 0 [0 : 1 : t : 0] x 3 = 0 x 2 0 x 2 = 0 [0 : 0 : s : t] singular Table 2. points on S = V(x 2 0 x 2 + x 2 1 x 3 ).
there are no T-points at all. If S is projectively equivalent to V(x 2 0 x 2 + x 2 1 x 3 ), then A is contained in the line [s : t : 0 : 0] and A is contained in the union of the lines [s : 0 : 0 : t] and [0 : s : t : 0], as shown in Table 2. Now, let us assume a is smooth. Since it is not a T-point, T a S cannot contain lines made up of T-points, so every such a line intersects T a S in one and only one point. Since they are finite in number, the first statement of 1. is proved. For the second statement, let x = a be a point in P 3 K and let Y = V(P 1,a ) ∩ T a S. By [START_REF] Chiantini | On general surfaces defined by an almost linear Pfaffian[END_REF], the point x ∈ Y if and only if either F (a + tx) is the zero polynomial or the line through a and x intersects S only in a. This means that, if x ∈ Y , also the whole line through it and a is contained in Y ; the conclusion then holds if we prove that Y is a curve, that is, V(P 1,a ) T a S. In fact, a is not a T-point and so there exists a point y on S∩T a S such that the line r through y and a does not lie on S. The line r intersects S in a with multiplicity two and in y with multiplicity one: this implies y / ∈ V(P 1,a ). Part 1. of the lemma is proved.

If a is singular, then by Lemma 3.2.1 only finitely many planes through a contain a line on S through a. For any other choice π, the same argument of the smooth case holds, if we replace T a S with π. This proves part 2. of the lemma.

Proof of Theorem 3.1.3. We divide the proof into four steps.

Step 1: looking for the second point.

Either a 1 is smooth or it is singular.

If a 1 is smooth, then by hypotheses S ∩ T a 1 S is a cubic curve, neither settheoretically union of lines (a 1 is not a T-point), nor the whole tangent plane (S is irreducible). Every line on T a 1 through a 1 , but those contained in T a 1 S ∩ V(P 1,a 1 ) as in Lemma 3.2.2, has one and only one intersection with S different from a 1 . Here we do not care about any line on T a 1 S ∩ S through a 1 , since by Lemma 3.2.2 it would be contained in T a 1 S ∩ V(P 1,a 1 ) as well. Fix a line ; the so-obtained a 2 is smooth. Otherwise, would have multiplicity of intersection at least four with S, and therefore ⊂ S, which is not. Moreover, by Lemma 3.2.2, a 2 can be a T-point only for finitely many choices of , and so these choices can be avoided. By [START_REF] Chiantini | On general surfaces defined by an almost linear Pfaffian[END_REF], in coordinates we have, having chosen a representative a 1 for a 1 ,

a 2 = F (y) • a 1 -P 1,a 1 (y) • y,
for any choice of y = (y 0 , y 1 , y 2 , y 3 ) representing the class y ∈ T a 1 S. Let us observe that P 1,a 1 (y) = 0 and that a 2 has coordinates in K.

If a 1 is singular, the previous argument can be repeated by replacing the role of T a 1 S above with a plane π satisfying Lemma 3.2.2.

In both cases, we have constructed a smooth point a 2 on S, which is not a T-point.

Step 2: looking for the third point.

The tangent plane process can be repeated as in step 1 -smooth case -starting from a 2 to construct next point a 3 . Summarizing, every line on T a 2 S through a 2 with the exception of • finitely many (by Lemma 3.2.2) lines through T-points,

• at most two lines in T a 2 S ∩ V(P 1,a 2 ) as in Lemma 3.2.2 has exactly one intersection with S different from a 2 , say a 3 . It is smooth and not a T-point. To state that a 3 is in general position with a 1 and a 2 , we only need to verify that it does not lie on the line through them. This is for free, since a 3 belongs to T a 2 S but a 1 does not, otherwise ⊆ S, which is not by construction.

Step 3: looking for the fourth point.

The tangent plane process can be repeated as in step 1 -smooth case -starting from a 3 to construct next point a 4 . We need to choose it not on the plane π 123 containing a 1 , a 2 and a 3 .

The planes T a 3 S and π 123 are distinct -for example, the first one does not contain a 2 by construction -so their intersection is a line through a 3 , say .

Claim. The system (11)

   y ∈ S y ∈ T a 3 S T y S a 2
which can be translated in homogeneous equations of degree 3, 1, 2 respectively, has finitely many solutions y ∈ P 3 K.

Indeed, the system represents the intersection on the plane T a 3 S between the cubic curve C = S ∩ T a 3 S and the conic Q defined on T a 3 S by the condition T y S a 2 . By construction, a 3 is not a T-point and therefore C is either irreducible or union of a line and an irreducible conic containing a 3 ; Q does not pass through a 3 and so it cannot be contained in C. This proves the claim.

The finitely many solutions of system [START_REF] Conforto | Le superficie razionali[END_REF] correspond to finitely many lines on T a 3 S through a 3 . Since we want a 2 / ∈ T a 4 S, we will avoid them. Summarizing, every line on T a 3 S through a 3 with the exception of • finitely many lines through the solutions y of system (11),

• , • finitely many (by Lemma 3.2.2) lines through T-points, • at most two lines in T a 3 S ∩ V(P 1,a 3 ) as in Lemma 3.2.2 has exactly one intersection with S different from a 3 , say a 4 . It is smooth and not a T-point, moreover a 2 / ∈ T a 4 S.

Step 4: looking for the fifth point.

We can apply the usual tangent plane process to find a 5 in general position with a 1 , a 2 , a 3 and a 4 . Let us call π ijk the plane through different a i , a j , a k . The planes π 134 , π 234 and π 124 intersect T a 4 S into three lines through a 4 : in fact they are four different planes, since a 2 , a 3 / ∈ T a 4 S. The line π 123 ∩ T a 4 S cannot be contained in T a 4 S ∩ S, since a 4 / ∈ π 123 and by construction a 4 is not a T-point. This means that π 123 ∩ T a 4 S ∩ S contains at most three points. Summarizing, every line on T a 4 S through a 4 with the exception of • three lines lying on the planes π 134 , π 234 and π 124 ,

• at most three lines through the points in π 123 ∩ T a 4 S ∩ S,

• at most two lines in T a 4 S ∩ V(P 1,a 4 ) as in Lemma 3.2.2 has exactly one intersection with S different from a 4 , say a 5 , in general position with a 1 , a 2 , a 3 , a 4 . Remark 3.2.3. Following the proof of Theorem 3.1.3, it is possible to implement an algorithm which requires a K-point on S, not a T-point, and ensures five Kpoints in general position on S. To test if a given point is a T-point or not, it is sufficient to check the reducibility of a polynomial of degree three in three variables, a task which can be easily performed with a software computation. Remark 3.2.4. If S is a smooth cubic surface, then any T-point P has T P S ∩ S made up of three distinct lines. In such a situation, Theorem 3.1.3 can be proved with the weaker hypothesis: the starting point a 1 is not an Eckardt point. Remark 3.2.5. In the statement of Theorem 3.1.3 we require that a 1 is not a T-point. Indeed, if a 1 is Eckardt, then the tangent plane process fails at the very first step. If a 1 is a non-Eckardt T-point, then the tangent plane process could give rise to either singular or other T-points, which can make one loose control in In the first case, a Pfaffian representation is given by 0 M -M 0

, where

M =   π 1 0 0 0 π 2 0 0 0 π 3   .
In the second case, let us consider the matrix

T =   0 -x 3 -x 2 x 3 0 -x 1 x 2 x 1 0   .
If S [1 : 0 : 0 : 0], then we can find three linear forms L 1 , L 2 , L 3 such that an equation for S is 3 i=1 (-1) i+1 L i x i . A Pfaffian representation of S is then given by

P =     T L 1 L 2 L 3 -L 1 -L 2 -L 3 0    
by formula [START_REF] Abhyankar | Cubic surfaces with a double line[END_REF].

If [1 : 0 : 0 : 0] / ∈ S, then it is sufficient to apply to x 1 , x 2 , x 3 in T the projectivity which maps a given point a on S to [1 : 0 : 0 : 0], as described in subsection 2.2. Again by formula (1) one finds three linear forms and a Pfaffian representation P of S as above.

A Pfaffian representation of S is then given by   0 0 π 0 P 0 -π 0 0   . Remark 4.1.1. Let F ∈ K[x 0 , x 1 , x 2 , x 3 ] 3 be an equation for the reducible surface S. The Pfaffian representations just constructed are not K-representations, in general. This is due to the fact that the splitting field of a polynomial of degree three is generally an algebraic extension of K of degree six. However, for such reducible surfaces we can state: it is possible to construct explicitly a Pfaffian K -representation, being K an algebraic extension of K of degree at most six. 4.1.3. Cones. Let S be an irreducible cone. If we suppose non-restrictively that its vertex is [1 : 0 : 0 : 0], then S is defined by an equation F ∈ K[x 1 , x 2 , x 3 ]. Let us call C the plane cubic curve defined by F in P 3 K ∩ V(x 0 ). As previously done, we can find a K -point a on C, being K an algebraic extension of K, simply by solving a polynomial equation of degree three. The construction of K -points on a plane cubic curve is a subject widely studied in ,literature (see for example [START_REF] Silverman | Rational points on elliptic curves[END_REF]). Starting from a set X of K -points, it consists in considering tangent lines to the curve in each point of X, and secant lines through each pair of points of X; the third intersection of such lines with C is then set as a new element in X. This process fails, for particular choices of X = {a}: for example, if a is an inflection point of the curve. For a general choice of a, this process produces a lot of K -points on C, and we can manage to find five points among them such that no three are collinear. Then the following proposition applies. Proposition 4.1.2. Let S be a cone over a plane cubic curve C, with equation F ∈ K [x 0 , x 1 , x 2 , x 3 ] 3 . If there exist five K -points on C such that no three of them are on a line, then there exist five K -points in general position on S.

Proof. We can suppose the vertex is [1 : 0 : 0 : 0], so that the equation of the plane curve (and the cone) is C = C(x 1 , x 2 , x 3 ). Let a i = (a i 0 , a i 1 , a i 2 , a i 3 ) represent the five points. The vanishing of each of the 4 × 4 minors of the matrix

Definition 1 .

 1 0.5 (depth, Gorenstein ideal). Let I be an ideal in the ring R. Let M be an R-module. Then depth(I, M ) is the length of a maximal regular M -sequence contained in I. The ideal I is said to be Gorenstein if (3) depth(I, R) = hd(R/I) = k and Ext k R (R/I, R) ∼ = R/I for some k ∈ N, where hd denotes the homological dimension. Theorem 1.0.6 (Buchsbaum-Eisenbud Structure Theorem).

  denominators, we have P = (p ij ) with the following entries:p 12 = 0, p 13 = x 2 -x 3 , p 14 = 0, p 15 = 3x 2 + x 3 , p 16 = 1470x 1 + 686x 2 + 588x 3 , p 23 = -x 2 + x 3 , p 24 = 34x 0 -510x 1 -170x 2 -340x 3 , p 25 = 2x 1 + x 2 + x 3 , p 26 = 1372x 1 + 588x 3 , p 34 = 8670x 1 + 6120x 2 + 2550x 3 , p 35 = -34x 1 -17x 2 -17x 3 , p 36 = -23324x 1 -10829x 3 , p 45 = 0, p 46 = 774690x 1 -624750x 2 , p 56 = -21658x 1 + 11662x 2 + 833x 3 .

)

  Remark 2.2.2. Algorithm 2.2.1 involves only linear equations. If the five given points are K-points, as well as F ∈ K[x 0 , x 1 , x 2 , x 3 ] 3 , then the output Pfaffian representation of S = V(F ) is a K-representation too, for a suitable choice of the representatives of the points.

Remark 2.2.3. The matrix associated to the (non-homogeneous) linear system in line 12 of the algorithm is 20 × 20; it depends only on the projectivity applied in Algorithm 2.2.1 from five points in general position to a Pfaffian representation

Acknowledgments. The author thanks his supervisor Emilia Mezzetti for her constant support and wise pieces of advice; he also thanks Alessandro Logar for many useful conversations and Daniele Faenzi for interesting discussions. In addition, he would like to thank the referee for helpful comments.

Partially supported by the PRIN 2008 "Geometria delle varietà algebriche e dei loro spazi di moduli" and by the European Research Network "GREFI-GRIFGA".

subsequent steps. In facts, this does happen in the following example: take S = V(x 0 x 1 x 3 +x 3 2 +x 2 x 2 3 ) and a 1 = [0 : 0 : 0 : 1]. The tangent plane process gives rise to points on the line [s : t : 0 : 0], which are either singular or Eckardt points. The process then stops at the second step.

As pointed out by the referee, codimension three AG subschemes have been considered also in [START_REF] Migliore | A construction of codimension three arithmetically Gorenstein subschemes of projective space[END_REF], where they are obtained as zero loci of sections of certain rank-three sheaves. In the case of five points in general position in P 3 K, it turns out that all such sets are the zero loci of appropriate sections of the bundle Ω P 3 (3), which can be interpreted as four-tuple quadrics, that is, linear combinations (using linear forms as coefficients) of the syzygies of the map (x 0 x 1 x 2 x 3 ). The membership of such a zero locus to a surface S imposes conditions to the linear combination.

Main results and further generalizations

In this last section, we firstly make use of Theorem 3.1.3 and Algorithm 2.2.1 to prove Theorem 1.0.9; if we drop the requirement of the starting point, then a weaker result holds (Proposition 1.0.10). After discussing the cases of reducible surfaces and cones, we state Theorem 1.0.11. A concrete example is finally given.

Proof of Theorem 1.0.9. Given a 1 , one can apply Theorem 3.1.3 and construct four other K-points a 2 , a 3 , a 4 , a 5 on S such that they are all together in general position. With these initial data, Algorithm 2.2.1 ensures a Pfaffian K-representation of S.

Remark 4.0.6. Let us work on K and let S be general. In Remark 2.2.4 we saw that the Pfaffian representations produced by Algorithm 2.2.1 are all equivalent, once fixed the inputs a 1 , a 2 , a 3 , a 4 , a 5 . The constructive proof of Theorem 1.0.9 provides a new algorithm to construct many Pfaffian representations starting from just one point a 1 : we claim that neither this algorithm is surjective onto the possible Pfaffian representations of S, once fixed a 1 . Indeed, by Remark 2.2.5, the space of essentially different Pfaffian representations of S is five-dimensional. Since we can suppose S is smooth, a 1 is not singular. The procedure described in the proof of Theorem 3.1.3 consists in taking a point on a plane cubic curve in each step, and so the space of sets of five points obtained starting from a 1 is four-dimensional. The conclusion follows again by Remark 2.2.4. Remark 4.0.7. The procedure lying beneath the proof of Theorem 1.0.9 involves only linear equations and can be implemented in a deterministic algorithm.

Weakening hypotheses.

4.1.1. No starting points. One of the hypotheses of Theorem 1.0.9 was a K-point on S. If this is not given, then one can manage to find a K -point a, being K an algebraic extension of degree at most three, simply by solving a polynomial equation of degree three (given by intersecting S with two arbitrary planes). For the general choice of these two planes, a is not a T-point and so Theorem 1.0.9 applies. This proves Proposition 1.0.10.

Reducible surfaces.

Let S be a reducible cubic surface. Then S is either union of three planes with equation π 1 , π 2 , π 3 or union of a plane π and a quadratic irreducible surface S. In both cases, simple Pfaffian representations can be constructed, as we will show.