the disciplined software engineering relies on software architectures to describe systems  @xcite . for modeling a software architecture ,
the academy proposed the architecture description language ( adl ) and their toolsets  @xcite .
also , the industry has used adls to develop systems .
industry examples are ( i ) @xmath0-adl has been used to architect and refine federated knowledge management systems in engineering ingegneria informatica - italy  @xcite ; ( ii ) and aadl ( architecture analysis & design language ) is a standard language for the society of automotive engineers  @xcite . according to the state - of - the - art  @xcite ,
the following concepts are relevant to describe software architectures : components and connectors ( respectively computational and communication elements ) , architectural constraints , non functional properties , and behaviour .
software systems evolve over their life time  @xcite .
dynamic reconfiguration is when the evolution is performed at runtime with no service disruption .
the dynamic reconfiguration can be handled by architectural concepts in an adl . however among many existing adls , only few allow modeling dynamic reconfiguration .
@xmath0-adl  @xcite , acme / plastik  @xcite , c2sadl  @xcite , daop - adl  @xcite , darwin  @xcite , dynamic wright  @xcite , rapide  @xcite , weaves  @xcite , and xadl  @xcite are typical examples .
nevertheless , there is no current consensus about how adls should address reconfiguration , e.g. , what language constructs should be provided .    in this work ,
the goal is twofold : ( i ) to investigate the adls support for handling dynamic reconfiguration in the literature ; and , ( ii ) to illustrate how four well - known adls support dynamic reconfiguration : @xmath0-adl , acme , c2 sadl and dynamic wright .
we chose these four languages because they rely on different paradigms : the higher order typed @xmath0-calculus  @xcite , first order predicate logic  @xcite , compo - nent- and event - based  @xcite , and , graph grammars and communicating sequential processes ( csp )  @xcite , respectively .
they also complement each other as @xmath0-adl models the behavior of architectures , acme focuses on the structure , c2sadl make the attention for components and their concurrent events , and dynamic wright supports the definition of structure and behavior .
this work is structured as follows .
section  [ section : motivation ] motivates this work thanks to the example of a tcp / ip stack system .
three scenarios illustrate three facets of dynamic reconfiguration .
section  [ section : concepts ] presents the basics concepts of software architecture and dynamic reconfiguration .
section  [ section : related - works ] details the related works about dynamic reconfiguration at the architecture level .
section  [ section : comparison ] compares the four above - mentioned adls in the light of our example of section  [ section : motivation ] .
section  [ section : conclusion ] concludes the paper with open issues that we note in the adl support for dynamic reconfiguration .
dynamic reconfiguration aims at modifying the software systems at runtime with no service disruption .
critical systems usually want to benefit of a dynamic reconfiguration because any service disruption may have substantial consequences .
examples of critical systems are stock market quotation systems , telecommunications systems , safety systems , and air traffic control systems . however , there is no current consensus about how the software architecture should address dynamic reconfiguration at architecture level .
does regular syntax for dynamic architectures allow the same reconfigurations as specific language constructs ? should the state of components and connectors be taken into account at the architecture level ?    to support this work ,
we rely on a simplified version of the tcp / ip stack ( fig .
[ fig : tcpip - stack ] ) .
each of the four layers ( application , transport , internet , and link ) is modeled as a component ( fig .
[ fig : tcpip - system ] ) .
we consider the three following reconfigurations :    1 .
_ switch the application component .
_ assume two alternatives : mpeg - decoder and h263-decoder .
mpeg - decoder is used if _ bandwidth _ is high ( fig .
[ fig : tcpip - mpeg ] ) . otherwise h263-decoder is selected ( fig  [ fig : tcpip - h263 ] ) .
switching between mpeg and h263 starts a new stream .
therefore , no state in the decoder needs be kept .
we can therefore replace one component by another .
insertion of a new component type .
_ presume that the internet protocol version 6 ( ipv6 ) replace the version 4 ( ipv4 ) ( fig .
[ fig : tcpip - ipv6 ] ) .
the ipv6 component has backward compatibility with the ipv4 component .
so it has the ports for both ipv4 ( for compatibility reason ) and for ipv6 ( new feature ) .
therefore , the type of the component at the internet layer is changed : it has 2 additional ports .
_ update a component type . _
assume that the algorithm of error control of the transport component is improved .
when the error control algorithm is changed , the new behaviour needs to know the status of each packet ( acknowledged , sent , timeout , ... ) as well as the content of non - acknowledged packets ( in order to resend them ) .
therefore , only the behaviour part of the component should be replaced .
the state of the component should be unchanged .
these scenarios cover a wide spectrum .
they can either be programmed at design - time or be discovered at run - time .
they feature reconfiguration at both type and instance level .
they target both the structure and the behaviour of the architecture .
we investigate the adls literature in order to illustrate how reconfiguration is supported in these scenarios .    in this paper
, we focus on four adls that are representative of the main trends .
each adls complement the other . the complement at the sense for describing an initial architecture as well as dynamic reconfiguration .
we choose @xmath0-adl because it provides both description with behaviours thanks to its @xmath0-calculus roots . whilst the acme / plastik is a declarative language with focus on the architecture structure for both descriptions . while c2sadl is used to compose architectures based on component and dynamic reconfiguration based on architectural events
. finally , dynamic wright provides support for architectural description based in graph - grammars and dynamic reconfiguration specification with a variant of communicating sequential processes ( csp ) .
[ [ software - architecture - concepts ] ] software architecture concepts + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    software architectures + describe systems by specifying their elements and the interactions between them  @xcite . in this work , we use the basics concepts defined in  @xcite : a _ component _ is an unit of computation and storage ; a _ connector _ is an unit of communication ; and , a _ configuration _ is a specification of a software architecture in terms of components , connectors , and relationship between them .    ports , roles , behaviours , constraints , and non - functional properties are other concepts defined in  @xcite used to describe these architectural elements .
ports and roles are used to define the way of interaction , ports for configurations and components , and roles for connectors .
behaviours are the architectural element internal computation . and
the last two concepts , constraints and non - functional properties , are used to denote the assertions , invariants , quality of service that architectural elements are expected to meet .    also , we consider types and instances of configurations , components , and connectors for modelling a software architectures  @xcite .
the types are abstractions like classes in the object - oriented paradigm which encapsulate both the structure and the behaviours that can be performed on its structure .
these types will be used to build the instances and these instances will be used to describe software architectures .    fig .
[ code : tcpip - acme ] illustrates in acme the basics concepts with our example tcp / ip stack system ( sec .
[ section : motivation ] fig .
[ fig : tcpip - system ] ) at instance and type level .
the types are defined in the ` family ` statement block ( lines 1 - 18 ) while the instance level in ` system ` ( lines 20 - 30 ) .
.... family tcpip_mf {    . .
connector type tcpip_conn2layers {      providedrole source ;      requiredrole sink ;    } ;    component type tcpip_component {      port type datafrom extends providedport with { } ;      port type datato extends revidedport with { } ;      property type layer = enum{application , transport , internet , link }    } ;    component type tcpip_application extends tcpip_component with {      port datareceivedfromtransport : datafrom ;      port requiredservice : datato ;      property layer = " application " ;    } ;    . .
}    system decoderstream : tcpip_mf = new tcpip_mf extended with {    component application : tcpip_application ;    component transport : tcpip_transpot ;    component internet : tcpip_internet ;    component link : tcpip_link ;        connector       application2transport , transport2internet , internet2link : conn2layers ;    attchments {      application.requiredservice to application2transport.source ;      application2transport.sink to transport.service ;        transport.requiredservice to transport2internet.source ;      transport2internet.sink to internet.service ;        internet.requiredservice to internet2link.source ;      internet2link.sink to link.service ;    }    . .
} ....    [ [ dynamic - reconfiguration - concepts ] ] dynamic reconfiguration concepts + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    a dynamic reconfiguration is a set of operations to modify an existing configuration at runtime . at the software architecture level
, the operation is defined in terms of the architectural elements at type or instance level .
scenario 1 is an example of reconfiguration at the instance level ( mpeg and h263 share the same type ) ; and scenario 2 is an example of reconfiguration at the type level ( ipv6 extends the type of ipv4 ) .    also , the dynamic reconfiguration can be foreseen or unforeseen  @xcite .
the foreseen is a programmed dynamic reconfiguration specified at design time . while the unforeseen is an ad - doc defined at runtime .
example of foreseen and unforeseen is the scenario 1 and 3 , respectively . in the scenario 1 ,
the architect specify at design time that the system modify itself when the bandwidth change . whereas the behaviour improvement is built at runtime as defined in scenario 3 .
medvidovic and taylor  @xcite created a classification framework based on architectural elements and illustrated them with the following adls : acme , aesop , c2 , darwin , metah , rapide , sadl , unicon , weaves , and wright .
however , this work has no focus on the dynamic reconfiguration .
hence , its discussion about dynamic reconfigurations is limited , e.g. all adls were assessed only at the instance level , not at the type level .
kacem _ et al . _
@xcite described the capabilities of darwin , archjava , olan , rapide , wright , and acme to support dynamic reconfiguration .
they classify the adls as configuration and description language .
the configuration language supports the description of a software system and limited dynamic reconfigurations , while the description language supports the specification of modifications to be applied to an existing architecture . despite this work focus
is on dynamic reconfiguration , it also presents some limitations such as the fact that the evolution is applied only at instance level and do not take into account the behaviour of the architectural elements .
bradbury  @xcite and bradbury _ et al . _
@xcite proposed a framework to compare fourteen formal specification approaches which support dynamic software architectures . amongst the criteria , bradbury _ et al .
_ considered the basic operations , how they can be composed and whether they apply to variable sets of architectural element types .
about the basic operations ( addition and removal of components and connectors ) , bradbury et al
. showed that most approaches support them . also , they considered the criterion of operations composition ( basic , sequence , choice , and iteration ) . only 3 approaches
( community , dynamic wright , and gerel ) provide full support while the other only support basic composition .
finally , bradury _ et al .
_ mentioned that all approaches support only the types of architectural elements defined prior runtime , fixed sets of architectural elements .
while adl surveys have reached good understanding of the concepts underlying software architectures ( medvidovic and taylor  @xcite ) , this is not true regarding dynamic reconfiguration at the architecture level .
even bradbury  @xcite and bradbury _ et al . _
@xcite , probably the most complete surveys , do not consider operations such as insertion of configuration and behaviour modification .
they do not recognize _ link _ and _ unlink _ as basic operations .
however , they present the examples of these operations on some approaches , like gerel and c2sadl . considering the scenarios of section  [ section :
motivation ] , these related works address only the first scenario ( partially ) but not the two last .
consequently , it is clear that to discuss the three scenarios presented in section  [ section : motivation ] is essential to have a better understanding of the dynamic reconfiguration issues .
these scenarios consider both instance and type levels , the basic operations include configurations , components , and connectors , as well as their structures and behaviours .
in this subsection , we describe the scenarios defined in sec .
[ section : motivation ] in all four adls : @xmath0-adl ( subsection  [ sec : pi - adl ] ) , acme / plastik ( subsection  [ sec : acme ] ) , c2sadl ( subsection  [ sec : c2sadl ] ) , and dynamic wright ( subsection  [ sec : wright ] ) . for each adl
we show the purpose , the tcp / ip stack system , a solution for three scenarios , and discussion about this implementation .      [ [ purpose - of - the - adl ] ] purpose of the adl + + + + + + + + + + + + + + + + + +    @xmath0-adl is based on @xmath0-calculus and it is designed to describe the concurrent and mobile systems  @xcite . the description of architectural elements is mainly represented by ports and behaviour .
[ [ dynamic - reconfiguration - support ] ] dynamic reconfiguration support + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    this adl provides + support for foreseen and unforeseen dynamic reconfiguration .
the foreseen can be described in the behaviour of any architectural elements . while unforeseen needs some support , e.g. , in the virtual machine ( vm ) , in order to obtain a root reference to the reconfigured system . in archware , this issue is addressed by the deep intrication between the toolset ( including the visual and textual editors ) and the vm thanks to the hyper - code technology  @xcite .
[ [ initial - architecture ] ] initial architecture + + + + + + + + + + + + + + + + + + + +    the implementation of tcp / ip stack system is shown in fig .
[ code : tcpip - piadl ] .
the configuration is composed at lines 1 - 18 basically with a behaviour , statement ` behaviour ` is ... where ... ! ( lines 2 - 17 ) .
this architectural behaviour defines the instances of components ( lines 3 - 6 ) and connectors ( lines 7 - 9 ) .
the statement ` where ` in behaviour specifies the connections between components and connectors ( lines 11 - 16 ) .
the example of component ` tcpip_application ` is partially showed at lines 20 - 35 : two ports and a behaviour .
the component behaviour is implemented with two internal methods ( lines 24 - 25 ) and the definition of communication between its ports ( lines 27 - 33 ) .    .... archictecture tcpip is abstraction ( ) {    behaviour is compose {      application is tcpip_application ( )      and transport   is tcpip_transport ( )      and net         is tcpip_internet ( )      and link        is tcpip_link ( )      and app2transp is conn2layers ( )      and transp2net is conn2layers ( )      and net2link    is conn2layers ( )    } where {      appliation::request     unifies app2transp::source      and app2transp::sink    unifies transport::service      and transpost::request unifies transp2net::source      and transp2net::sink    unifies net::service      and net::request        unifies net2link::source      and net2link::sink      unifies link::service    } }    component tcpip_application is abstraction ( ) {     port service is { ... } .     port request is { ... } .     behaviour is {        processrequest is function(d : datatype):datatype { unobservable}.        processresponse is function(d : datatype):datatype { unobservable}.          choose {           via service::wait receive entrydata : datatype .           via request::call send processrequest(entrydata ) .        or           via request::response receive replydata : datatype .
via service::reply send processresponse(replydata ) .        }     } }    component tcpip_transport is abstraction ( ) { ... }    component tcpip_internet is abstraction ( ) { ... }    component tcpip_link is abstraction ( ) { ... }    connector conn2layers is abstraction ( ) {    ...    port source is { ... }    port sink is { ... }      behaviour is { ... } } ....    [ [ scenario-1 ] ] scenario 1 + + + + + + + + + +    the implementation of scenario 1 in @xmath0-adl is composed by a component that performs the dynamic reconfiguration ( fig .
[ code : scenario1-piadl ] ) .
this component has two parameters : the application component and the system component .
both are represented as a behaviour .
the application component is a mpeg - decoder or h263-decoder .
still , this component is structured with seven `` variables '' and a behaviour , lines 2 - 4 and 5 - 27 , respectively .
the variables are used for behaviours of components and connectors . to perform the modification ,
the behaviour component use the following steps : decomposition the system behaviour ( line 6 ) ; assign the behaviours to variables ( lines 8 - 14 ) ; compose a new system behaviour ( lines 16 - 26 ) with a replaced application component ( line 20 ) .
.... component reconfiguration is abstraction(application : behaviour , system : behaviour ) {     behaviours : sequence[behaviour ] .
transport : behaviour .
net : behaviour .
link : behaviour .
app2transp : behaviour .
transp2net : behaviour .
net2link : behaviour .
behaviour is {        behaviours : = decompose system .
transport : = behaviours::1::bhvr .
net : = behaviours::2::bhvr .
link : = behaviours::3::bhvr .
app2transp : = behaviours::4::bhvr .
transp2net : = behaviours::5::bhvr .
net2link : = behaviours::6::bhvr .
compose {           application and transport and net and link           and app2transp and transp2net and net2link        } where {           appliation::request     unifies app2transp::source           and app2transp::sink    unifies transport::service           and transpost::request unifies transp2net::source           and transp2net::sink    unifies net::service           and net::request        unifies net2link::source           and net2link::sink      unifies link::service        }     } } ....    [ [ scenario-2 ] ] scenario 2 + + + + + + + + + +    the implementation for the unforeseen scenario 2 is shown in fig .
[ code : scenario2-piadl ] .
this code is applied in a system at runtime to deploy the two new component `` type '' .
first , the component type is a new protocol _ ipv6 _ ( lines 1 - 3 ) , and the second is a component to perform dynamic reconfiguration ( lines 4 - 32 ) . in order to execute this dynamic reconfiguration two steps are applied : ( i ) to obtain the root behaviour of the system , and ( ii ) to invoke the computation of the reconfiguration component .
both operations are aided by toolset and hyper - code .
the code of the reconfiguration component is described using the following steps : ( i ) to decompose the behaviours of the system in components and connectors ( lines 9 ) ; ( ii ) to assign to `` variables '' the instances of components that represent application , transport , and link ( lines 11 - 13 ) ; ( iii ) to attribute connectors to `` variables '' ( lines 15 - 17 ) ; ( iv ) to compose a new system behaviour ( lines 19 - 30 ) with a new instance of the protocol ipv6 component ( line 21 ) .
as in the scenario 1 , when performing a new composition , the behaviour of the system is automatically updated .
.... component tcpip_ipv6 is abstracion ( ) {    ... } component reconfiguration is abstraction(system : behaviour ) {     behaviours : sequence[behaviour ] .
application : behaviour .
transport : behaviour .
link : behaviour .
app2transp : behaviour .
transp2net : behaviour .
net2link : behaviour .
behaviour is {        behaviours : = decompose system .
application : = behaviours::0::bhvr .
transport : = behaviours::1::bhvr .
link : = behaviours::3::bhvr .
app2transp : = behaviours::4::bhvr .
transp2net : = behaviours::5::bhvr .
net2link : = behaviours::6::bhvr .
compose {           application and transport and link           and net is tcpip_v6           and app2transp and transp2net and net2link        } where {           appliation::request     unifies app2transp::source           and app2transp::sink    unifies transport::service           and transpost::request unifies transp2net::source           and transp2net::sink    unifies net::service           and net::request        unifies net2link::source           and net2link::sink      unifies link::service        }     } } ....    [ [ scenario-3 ] ] scenario 3 + + + + + + + + + +    in the scenario 3 it is also used the process of decomposition , modification , and composition , as showed above .
we use the archware virtual machine facility to get a reference to the root of the target transport component .
after , we make a modification into the behaviour of the component . at last , the archware virtual machine synchronize the system with this modification .    [
[ summary - of - pi - adl ] ] summary of @xmath0-adl + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    with these implementations , some issues are identified on @xmath0-adl support for dynamic reconfiguration :    1 .
changing types needs external help , e.g. toolset , hyper - code and @xmath0-arl .
toolset and hyper - code are used for capturing , specifying the changes , and applying the changes . while @xmath0-arl is a language to specify refinements in the system ; 2 .
instances modifications can be specified in architectural elements or also with toolset and hyper - code help . at first , usually the dynamic reconfiguration is tangled with nominally behaviour .
however , we used other approach with a specific component to specify dynamic reconfiguration ; 3 .   for the third scenario ,
the @xmath0-adl do not provide a mechanism to design the intermediate states for updating the instances with the improvement of behaviour .
however , if we use the @xmath0-arl approach , we can have better control ; 4 .   also with @xmath0-arl is possible build constraints and non - functional properties for architectural elements .
however , it s not used to assess dynamic reconfiguration .
[ [ purpose - of - the - adl-1 ] ] purpose of the adl + + + + + + + + + + + + + + + + + +    acme / armani is a declarative language based on the first - order predicate logic  @xcite .
its initial purpose was to define a common interchange language for architecture design tools .
also , its statements are designed to describe the architectural structures at instance and type levels .
the extensions  @xcite to support dynamic reconfiguration preserves these initials purpose , and are named as acme / plastik .
thereafter , any configuration and dynamic reconfiguration specified using this extension ( acme / plastik ) are based on the structure of an architecture .
[ [ dynamic - reconfiguration - support-1 ] ] dynamic reconfiguration support + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    acme / plastik permits to describe foreseen and unforeseen dynamic reconfiguration . to unforeseen reconfiguration
it is possible to describe as a specific behaviour of a configuration with the ` on ( $ conditional\_expression$ ) do { $ operations$ } ` statement .
unforeseen reconfiguration can be expressed in a script that will be applied in the system at runtime aided by a toolset provided by the plastik framework . both , @xmath1 and script are composed with acme statements and its acme / plastik extension .
the @xmath2 is composed in the armani language  @xcite .
[ [ initial - architecture-1 ] ] initial architecture + + + + + + + + + + + + + + + + + + + +    the example of the tcp / ip stack system in acme is showed in fig .
[ code : tcpip - acme ] .
the types are specified in the ` family ` statement while the instances are in the ` system ` statement . for types , a connector ( lines 3 - 6 ) and two components
( lines 7 - 11 and 12 - 16 ) are implemented as example .
the configuration is composed by the component instances ( lines 21 - 24 ) , connector instances ( lines 26 - 27 ) , and the connections between them ( lines 28 - 37 ) .
[ [ scenario-1 - 1 ] ] scenario 1 + + + + + + + + + +    the implementation in acme / plastik of scenario 1 is showed in fig .
[ code : scenario1-acme ] .
the configuration is named with ` streamdecodersystem ` and it extends the ` tcpip_mf ` and ` plastikmf ` .
the ` tcpip_mf ` is showed in fig .  [ code : tcpip - acme ] while ` plastik_mf ` in  @xcite .
such configuration consists of : the insertion of two new components ( type and instance ) in lines 2 - 5 and line 6 ; the instantiation of components and connectors ( omitted with comment and @xmath3 in lines 7 - 8 ) ; the linking of components and connectors ( omitted with comment and @xmath3 in lines 7 - 8 ) ; and the specification of two dynamic reconfiguration situations , lines 12 - 19 and 21 - 28 .
both dynamic reconfigurations use the same similar description .
first , the conditional expressions are ` link.bandwidth = = ' low ' ` and ` link.bandwidth = = ' high ' ` .
second , the @xmath1 are described as two unlinking ( lines 13 - 14 , 22 - 23 ) and one linking ( lines 15 - 18 , 24 - 27 ) statements .
these @xmath1 specified the replacement of an instance of the component .
.... system streamdecodersystem : tcpip_mf , plastikmf {    component mpeg - decoder : tcpip_mpegdecoder = new tcpip_application extend with {      property decoder - type = " mpeg " ;      property algorithm = ... ;    }    component h263-decoder : tcpip_h263decoder = new tcpip_application extend with { ... } // other instances of component and connector    ... //
initial attachments    ... // programmed dynamic reconfiguration to low bandwidth    on ( link.bandwidth = = ' low ' ) do {      detach mpeg-decoder.requiredservice to application2transport.source ;      detach transport2application.sink to mpeg-decoder.datareceivedfromtransport ;      attachments {        h263-decoder.requiredservice to application2transport.source ;        transport2application.sink to h263-decoder.datareceivedfromtransport ;      }    } // programmed dynamic reconfiguration to high bandwidth    on ( link.bandwidth = = ' high ' )
do {      detach h263-decoder.datato to application2transport.source ;      detach transport2application.sink to h263-decoder.datareceivedfromtransport ;      attachments {        mpeg-decoder.requiredservice to application2transport.source ;        transport2application.sink to mpeg-decoder.datareceivedfromtransport ;      }    } } ....    [ [ scenario-2 - 1 ] ] scenario 2 + + + + + + + + + +    the scenario 2 , an unforeseen insertion of a new component type , is describe with an acme / plastik script in fig .  [
code : scenario2-acme ] . for this scenario ,
the script is composed by : the insertion of a type and instance of a component ( lines 1 - 3 ) , the unlinking of the old component instance ( lines 5 - 6 ) and the linking of the new component ( lines 7 - 10 ) .    .... component ipv6 : tcpip_ipv6 = new tcpip_internet extended with {    ... }    detach ipv4.requiredservice to internet2link.source ; detach link2internet.sink to ipv4.datareceivedfromlink ; attachments {    ipv6.requiredservice to internet2link.source ;    link2internet.sink to ipv6.datareceivedfromlink ; } ....    [ [ scenario-3 - 1 ] ] scenario 3 + + + + + + + + + +    the unforeseen upgrade of a behaviour in scenario 3 can be described by the script illustrated in fig .
[ code : scenario3-acme ] .
this script defines a new version of a component with an improvement on its behaviour .
the behaviour in acme / plastik is expressed as a property and it can be also described in other languages , such as external formal languages , see lines 3 - 5 in fig .
[ code : scenario3-acme ] .
.... component type tcpip_transport extends tcpip_component with {    ...    property behaviour = {       \\ description of behaviour in other languages , e.g. csp    }    ... } ....    [ [ summary - of - acmeplastik ] ] summary of acme / plastik + + + + + + + + + + + + + + + + + + + + + + +    the dynamic reconfiguration issues for acme can be summarized as follows :    1 .
dynamic reconfiguration in terms of structure is supported by acme / plastik . in terms of behaviour
, dynamic reconfiguration is described using any external language embedded inside the property element .
usually , this is used for foreseen reconfiguration .
this approach is limited in the sense that components and connectors usually needs the dynamic reconfiguration of their behaviour but as acme / plastik does not provides elements for behaviour specification , the architect has to rely on an external language .
e.g. if the ` tcpip_transport ` component needs to decide if it has a buffer or not , and if it uses a error detecting or not , and so on .
these situations have to be described using an external language ( in general formal languages such as csp ) .
2 .   acme / plastik does not provide a mechanism to control the intermediate states of a reconfiguration .
e.g. the implementation of the scenario 3 , the architect can not define the approach used to update the instances .
3 .   for unforeseen
reconfiguration acme / plastik relies on external scripts .
this approach requires an external interpreted associated to the adl to interpret the external script in order to reconfigure the system .
[ [ purpose - of - the - adl-2 ] ] purpose of the adl + + + + + + + + + + + + + + + + + +    initially , the purpose of c2 was to describe the architecture of a software based on a graphical user interface ( gui )  @xcite . therefore , the adl is based on hierarchically concurrent components .
c2 also allows the use of messages to notify the architectural elements .
c2 is subdivided in 2 languages : c2 idl ( interface description language ) for describing the components types , and c2 adl to specify the configurations .
for components it is possible to specify top and bottom ports , to declare internal methods , and to specify the behaviour of its ports .
the implementation of the internal methods is done by the developer in the source code generated by a toolset . with c2
adl it is possible to define instances of components and connectors , as well as links between them .    [
[ dynamic - reconfiguration - support-2 ] ] dynamic reconfiguration support + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    the architectural + modification language ( aml ) was created to extend c2 for supporting dynamic reconfiguration  @xcite .
aml is a declarative language that uses the structure view of an existing configuration and messages to notify this configuration about a dynamic reconfiguration .
this language provides statements to build the scripts that specify dynamic reconfiguration .
however , in these scripts it is not possible to determine the moment to apply a dynamic reconfiguration . because that , human intervention is needed via a toolset to trigger dynamic reconfiguration .
[ [ initial - architecture-2 ] ] initial architecture + + + + + + + + + + + + + + + + + + + +    the tcp / ip stack system is described in c2 idl in fig .
[ code : tcpip - c2idl ] and c2 adl in fig .
[ code : tcpip - c2adl ] .    ....     ...     component tcpip_transport is        interface //
define the component ports           top_domain is //
ports to link high level connectors              out                 ...
in                 receivedata(package : applicationpackage ) ;           bottom_domain is // ports to link low level connectors              out                 sendtointernt(package : transportpackage ) ;              in                 ...        methods //
define interfaces of internal behaviours           function pack(data : applicationpackage ) : transportpackage ) ;           ...        behaviour // describe the external behaviour            ...           received_messages receivedata ;              invoke_methods pack ;              always_genarate sendtointernet ;           ...     end tcpip_transport     ... ....    ....     architecture decoderstream is        component_intances {           mpeg instantiates tcpip_mpegdecoder ;           h263 instantiates tcpip_h263decoder ;           transport instantiates tcpip_transport ;           internet instantiates tcpip_internet ;           link instantiates tcpip_link ;        }        connectors {           application2transport ;           transport2internet ;           internet2link ;        }        topology {           connector application2transport {              top_ports { mpeg filter no_filtering ; }              bottom_ports { transport filter no_filtering ; }           }           connector transport2internet {              top_ports { transport filter no_filtering ; }              bottom_ports { internet filter no_filtering ; }           }           connector internet2link {              top_ports { internet filter no_filtering ; }              bottom_ports { link filter no_filtering ; }           }        }     end decoderstream ; ....    [ [ scenario-1 - 2 ] ] scenario 1 + + + + + + + + + +    for scenario 1 , for changing the component according to the low or high bandwidth state , it is necessary two c2sadl scripts . in fig .
[ code : scenario1-c2sadl ] is described the script for dynamic reconfiguration when bandwidth is low .
this script uses two statements , a ` unweld ` for unlinking the @xmath4 instance and ` weld ` for linking the @xmath5 instance .
other aml s statements are ` addcomponent ` , ` addconnector ` , ` removecomponent ` , and ` removeconnector ` .
all these statements are used with a defined configuration , e.g. line 2 and 3 in fig .
[ code : scenario1-c2sadl ] with the configuration named as ` decoderstream ` . despite of the fact that aml statements are based on services of the archstudio tool suite ,
there are services that are not provided by the aml language , e.g. ` start ( ) ` and ` stop ( ) ` .
.... \\ bandwidth is low decoderstream.unweld(mpeg , application2transport ) ; decoderstream.weld(h263 , application2transport ) ; ....    [ [ scenario-2 - 2 ] ] scenario 2 + + + + + + + + + +    the second scenario , the unforeseen insertion of component instance and type , is inferred as shown in fig .
[ code : scenario2-c2sadl ] .
inference because both work about aml  @xcite stated that it is possible to make insertion and deletion of types .
however , they only show examples how to build dynamic reconfiguration at the instance level .
et al . _
@xcite mention types and subtypes but at design level .
dynamic reconfiguration in fig .
[ code : scenario2-c2sadl ] specifies : the insertion of a new type of component ( lines 2 - 5 ) , the creation a new instance of component ( line 9 ) , the unlinking of the instance of ipv4 ( lines 12 - 13 ) , and the linking of the instance of ipv6 ( lines 16 - 17 ) .
the component type name is inferred by a toolset before performing dynamic reconfiguration .    .... \\ creata a new type of component component tcpip_ipv6 is subtype    all < = all tcpip_internet ( ... )    ... end tcpip_ipv6    // create a new instance of component //    the name of the type is implicitly discovered decoderstream.addcomponent(tcpip_ipv61 ) ;    // unlink the instance of component ipv4 decoderstream.unweld(trasport2internet , tcpip_ipv41 ) ; decoderstream.unweld(tcpip_ipv41 , internet2link ) ;    // link the instance of component ipv6 decoderstream.weld(trasport2internet , tcpip_ipv61 ) ; decoderstream.weld(tcpip_ipv61 , internet2link ) ; ....    [ [ scenario-3 - 2 ] ] scenario 3 + + + + + + + + + +    the third scenario is an improvement of the behaviour that can be modeled by the ` behaviour ` statement via a sequence of invocations to internal methods .
example of this change , see line 6 in fig .
[ code : scenario3-c2sadl ] , the invocation is modified to verify the received and packed data before sending a transport package to the internet layer . if the change is an improvement of an internal method , it is not possible to describe with c2sadl .    ....
component tcpip_transport is        ...        behaviour // describe the external behaviour            ...           received_messages receivedata ;              invoke_methods verifydata , pack ;              always_genarate sendtointernet ;           ...     end tcpip_transport     ... ....    [ [ summary - of - c2sadl ] ] summary of c2sadl + + + + + + + + + + + + + + + + +    after the c2sadl implementation of the three scenarios , we identified these issues :    1 .
archstudio tool provides some services for supporting dynamic reconfiguration , e.g. to start and to stop architectural elements .
however , these services are not available in aml .
thus , the dynamic reconfiguration specification in aml is limited .
2 .   foreseen dynamic reconfiguration needs human intervention because c2sadl do not provide statements for the system apply dynamic reconfiguration .
3 .   it does not support the specification of dynamic reconfiguration inside of the architectural elements . because that , the foreseen dynamic reconfiguration is implemented only at the implementation level ; 4 .
it does not provide a mechanism for controlling and monitoring the intermediate states of a dynamic reconfiguration ; 5 .
it also does not support the assessment of dynamic reconfiguration .
[ [ purpose - of - the - adl-3 ] ] purpose of the adl + + + + + + + + + + + + + + + + + +    dynamic wright has focus on the structure and behaviour of an architecture  @xcite .
dynamic wright supports the description of the architectural elements types structures and behaviours , and initial configuration .
structure , initial configuration , instances , and links are described in a declarative form , while behaviours are specified in a graph - based and a variant of the communicating sequential process ( csp ) form .    [ [ dynamic - reconfiguration - support-3 ] ] dynamic reconfiguration support + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +    dynamic wright only supports foreseen dynamic reconfiguration .
it is built as a special behaviour of the initial configuration .
it has the same base of a `` nominally '' behaviour of architectural elements .
the extension described in  @xcite proposes additional statements and control events .
the statements are ` new ` , ` remove ` , ` attach ` , and ` detach ` .
the control events are used to define the specific moment to perform a dynamic reconfiguration .
as dynamic wright does not support unforeseen reconfiguration , the scenarios 2 and 3 can not be implemented .
[ [ initial - architecture-3 ] ] initial architecture + + + + + + + + + + + + + + + + + + + +    the initial configuration of the tcp / ip stack system is illustrated in fig .
[ code : scenario1-wright ] .
the component and connector types are specified in the ` style ... endstyle ` ( lines 1 - 16 ) statements . the implementation of the ` tcpip_``mpeg - decoder ` component is described with two ports ( lines 3 - 4 ) and a behaviour ( lines 6 - 7 ) . the configuration is described with the ` configuror ... endconfiguror ` statement . the initial configuration instances and connections
are specified at lines 18 - 27 .
[ [ scenario-1 - 3 ] ] scenario 1 + + + + + + + + + +    fig .
[ code : scenario1-wright ] also illustrates the specification of scenario 1 .
it uses the ` configuror [ initial configuration ] where [ behaviours ] ` statement . _
behaviours _ are special named behaviours of the configuration for specifying dynamic reconfiguration . in this case , there are two specification : lines 29 - 36 for low bandwidth and lines 37 - 44 for high bandwidth .
the following steps were used to define the first and the second dynamic reconfiguration situations :    1 .   to define a name ( lines 29 and 37 ) .
2 .   to specify the control events that define the moment for performing the operations of dynamic reconfiguration ( lines 30 and 38 ) .
3 .   to determine the type of configuration to use ( lines 31 and 39 ) .
dynamic wright use the term ` style ` for this purpose .
4 .   to specify the operations to perform dynamic reconfiguration ( lines 32 - 35 and 40 - 43 ) . 5 .   to use the statements of the external choice ( @xmath6 ) and successfully terminate ( @xmath7 ) , lines 36 and 44 .
.... style tcpip - style     component tcpip_mpeg - decoder        port datareceivedfromtransport = ...        port requiredservice = ...            [ describe the port behaviour using a variant of csp ]        computation = ...            [ describe the component behaviour using a variant of csp ]     ...     connector conn2layers        role source = ...        role sink = ...        glue = ...            [ describe the connector behaviour using a variant of csp ]     constraints        ... endstyle configuror decoderstream    style tcpip - style      new.mpeg : tcpip_mpeg - decoder      $ \rightarrow$ new.h263 : tcpip_h263-decoder      ... [ other component instances ]      $ \rightarrow$ new.app2trans : conn2layers      $ \rightarrow$ new.trans2net : conn2layers      $ \rightarrow$ new.net2link : conn2layers      $ \rightarrow$
attach.mpeg.requiredservice.to.app2trans.source      $ \rightarrow$ attach.app2trans.sink.to.transport.service      ... [ other attachments ]    where      waitforbandwidthlow = (      link.control.bandwidthdown $ \rightarrow$ mpeg.control.off $ \rightarrow$ h263.control.on      $ \rightarrow$ style tcpip - style        detach.mpeg.requiredservice.to.app2trans.source        $ \rightarrow$ attach.h263.requiredservice.to.app2trans.source        $ \rightarrow$ detach.trans2app.sink.to.mpeg.datareceivedfromtransport        $ \rightarrow$ attach.trans2app.sink.to.h263.datareceivedfromtransport      ) $ \box$ $ \s$      waitforbandwidthhigh = (         link.control.bandwidthup $ \rightarrow$ h263.control.off $ \rightarrow$ - > mpeg.control.on         $ \rightarrow$ style tcpip - style            detach.h263.requiredservice.to.app2trans.source            $ \rightarrow$ attach.mpeg.requiredservice.to.app2trans.source            $ \rightarrow$ detach.trans2app.sink.to.h263.datareceivedfromtransport            $ \rightarrow$ attach.trans2app.sink.to.mpeg.datareceivedfromtransport       ) $ \box$ $ \s$ endconfiguror ....
[ [ summary - of - dynamic - wright ] ] summary of dynamic wright + + + + + + + + + + + + + + + + + + + + + + + + +    the following issues are identified after the implementation of the scenario 1 :    1
.   it does not provide operations to define dynamic reconfiguration for the type level of architectural elements ; 2 .
this adl provides a refined mechanism of control events to determine the moment to perform a dynamic reconfiguration .
although , it does not provide a mechanism to control and monitor the intermediate states .
e.g. if the application of the scenario 1 is a banking system , the state must be copied from the instance of the replaced component to the new component .
dynamic wright does not provide operations for this purpose .
3 .   despite of providing the specification of behaviour for components and connectors ,
it is not possible to define dynamic reconfiguration for this architectural elements ; 4 .
similarly to the other adls , dynamic wright does not provide a mechanism for the assessment of dynamic reconfiguration .
the summary of the four adls support for dynamic reconfigurations is shown in tab .
[ tab : reconfiguration ] .
@xmath0-adl and acme / plastik are the only adls that support both foreseen and unforeseen dynamic reconfigurations .
as c2sadl with the aml language do not provide a way to specify an internal initiation of dynamic reconfiguration , foreseen dynamic reconfiguration can not be automatically triggered .
dynamic wright supports only foreseen reconfiguration by defining the special behaviour of a configuration .
.foreseen and unforeseen dynamic reconfiguration support in adls . [ cols="<,<,<",options="header " , ]
none of the four adls has a mechanism for assessing the system .
@xmath0-adl can rely on @xmath0-aal for defining and analyzing the architectural constraints and non - functional properties . while acme / plastik has armani . even though it has no formal semantics , and therefore , it is not liable to rigorous analysis  @xcite .
c2sadl provides type verification for events communication .
dynamic wright provides a refined mechanism of control events to determine the moment to perform a dynamic reconfiguration .
although , the assessment of dynamic reconfiguration is not provided on four adls .
in this paper we analysed the support of adls for handling dynamic reconfigurations .
we started with a motivation example and some reconfiguration scenarios and we described the example and the scenarios using four well - known adls .
we used the example and the specifications to discuss the following issues : ( i ) how each adl addresses the issue of consistently reconfiguring both instances and types ; ( ii ) how each adl takes into account the behaviour of the architectural elements during reconfiguration ; and ( iii ) how each adl supports the assessing of dynamic reconfiguration .    in comparison to related works , we analysed some important issues for the dynamic reconfiguration support at the architectural level : foreseen and unforeseen changes ; instance and type level modifications ; structure and behaviour for all architectural elements ; definition of nominally and dynamic reconfiguration behaviour for all architectural elements ; and , the analysis of dynamic reconfiguration .    we can conclude that some issues still remain open as no adl provides support for all of them together : how to apply the changes made in type level to their respective instances ?
how to control the set of intermediate states of a software system during a dynamic reconfiguration ?
how to assess dynamic reconfiguration ?
special thanks to collge doctoral international ( cdi)/uni - versit europenne de bretagne ( ueb ) for financial support this work .
r.  allen , r.  douence , and d.  garlan . specifying and analyzing dynamic software architectures . in _ proceedings of the 1998 conference on fundamental approaches to software engineering ( fase98 )
_ , lisbon , portugal , march 1998 . an expanded version of a the paper `` specifying dynamism in software architectures , '' which appeared in the proceedings of the workshop on foundations of component - based software engineering , september 1997 .
t.  v. batista , a.  t.  a. gomes , g.  coulson , c.  chavez , and a.  f. garcia . on the interplay of aspects and dynamic reconfiguration in a specification - to - deployment environment . in _ proceedings of the 2nd european conference on software architecture _ , ecsa 08 , pages 314317 , berlin , heidelberg , 2008 .
springer - verlag .
k.  h. bennett and v.  t. rajlich . software maintenance and evolution : a roadmap . in _ proceedings of the conference on the future of software engineering _ , icse 00 , pages 7387 , new york
, ny , usa , 2000 .
acm .
d.  garlan , r.  monroe , and d.  wile .
acme : an architecture description interchange language . in _ proceedings of the 1997 conference of the centre for advanced studies on collaborative research_. ibm press , 1997 .
a.  gomes , t.  v. batista , a.  joolia , and g.  coulson . .
in r.  de  lemos , c.  gacek , and a.  romanovsky , editors , _ architecting dependable systems iv _ , volume 4615 of _ lecture notes in computer science _ ,
pages 237261 .
springer berlin / heidelberg , berlin , heidelberg , 2007 .        j.  magee and j.  kramer .
self organising system structuring . in _
joint proceedings of the second international software architecture workshop ( isaw ) and international workshop on multiple perspectives in software development ( viewpoints 96 ) on sigsoft 96 workshops _ , isaw 96 , pages 3538 , new york , ny , usa , 1996 .
acm press .
n.  medvidovic , p.  oreizy , j.  e. robbins , and r.  n. taylor .
using object - oriented typing to support architectural design in the c2 style . in _ proceedings of the 4th acm
sigsoft symposium on foundations of software engineering _ , sigsoft 96 , pages 2432 , new york , ny , usa , 1996 .
acm .
p.  oreizy , m.  m. gorlick , r.  n. taylor , d.  heimbigner , g.  johnson , n.  medvidovic , a.  quilici , d.  s. rosenblum , and a.  l. wolf .
an architecture - based approach to self - adaptive software .
, 14(3):5462 , may / june 1999 .
p.  oreizy , n.  medvidovic , and r.  n. taylor .
architecture - based runtime software evolution . in _ proceedings of the 20th international conference on software engineering _ , icse 98 , pages 177186 , washington , dc , usa , 1998 .
ieee computer society .
p.  oreizy and r.  n. taylor . on the role of software architectures in runtime system reconfiguration . in _ configurable distributed systems , 1998 .
fourth international conference on _ , pages 6170 , may 1998 .
m.  pinto , l.  fuentes , and j.  m. troya .
daop - adl : an architecture description language for dynamic component and aspect - based development . in
_ proceedings of the 2nd international conference on generative programming and component engineering _ , gpce 03 , pages 118137 , new york , ny , usa , 2003 .
springer - verlag new york , inc .
r.  n. taylor , n.  medvidovic , k.  m. anderson , j.  whitehead , e.  james , j.  e. robbins , k.  a. nies , p.  oreizy , and d.  l. dubrow .
a component- and message - based architectural style for gui software . , 22(6):390406 , june 1996 .
j.  vera , l.  perrochon , and d.  c. luckham .
event - based execution architectures for dynamic software systems . in _ proceedings of the tc2 first working ifip
conference on software architecture ( wicsa ) _ , wicsa , pages 303318 , deventer , the netherlands , the netherlands , 1999 .
kluwer , b.v .
p.  waewsawangwong .
a constraint architectural description approach to self - organising component - based software systems . in _ proceedings of the 26th international conference on software engineering _
, icse 04 , pages 8183 , washington , dc , usa , 2004 . ieee computer society .


we are motivated by studying equivariant pullbacks of @xmath6-algebras exemplified , for instance , by a join construction for compact quantum groups .
insisting on equivarince to be given by
free actions " leads to galois extensions of @xmath6-algebras by hopf algebras , and generalising pullbacks to  multi - pullbacks " brings up distributive lattices as a fundamental language . as a by - product of our considerations , we obtain an equivalence between the distributive lattices generated by @xmath3 ideals intersecting to zero and flabby sheaves of algebras over a certain @xmath7-projective space .
comodule algebras provide a natural noncommutative geometry generalisation of spaces equipped with group actions .
less evidently , principal extensions @xcite appear to be a proper analogue of principal bundles in this context ( see section  [ prelimi ] for precise definitions ) .
principal extensions can be considered as functors from the category of finite - dimensional corepresentations of the hopf algebra ( replacing the structure group ) to the category of finitely generated projective modules over the coaction - invariant subalgebra ( playing the role of the base space ) .
the aim of this article is to establish a viable concept of locality of comodule algebras and analyse its relationship with principality .
the notion of locality we use herein results from decomposing algebras into `` pieces '' , meaning expressing them as multiple fibre products ( called multirestricted direct sums in @xcite ) .
if @xmath8 is a compact hausdorff space and @xmath9 form a finite closed covering , then @xmath10 can be expressed as such a multiple fibre product of its quotient @xmath6-algebras @xmath11 .
this leads to a @xmath6-algebraic notion of a  covering of a quantum space " given by a finite family of algebra surjections @xmath12 with @xmath13 ( see @xcite , cf .
@xcite ) .
recall that not all properties of group actions are local in nature : there is a natural example of a locally proper action of @xmath14 on @xmath15 that is not proper ( see @xcite , cf .
* example  1.14 ) for more details ) . on the other hand ,
a group action is free if and only if it is locally free .
therefore , since for compact groups all actions are proper , the principal ( i.e. , free and proper ) actions of compact groups are local in nature .
our main result ( theorem  [ main ] ) is a noncommutative analogue of this statement : a comodule algebra @xmath0 which is covered by `` pieces '' @xmath5 is principal if and only if so are the pieces . in particular , a smash product of an @xmath1-module algebra @xmath16 with the hopf algebra @xmath1 ( with bijective antipode ) is principal , so that gluing together smash products is a way of constructing principal comodule algebras .
however , it was pointed out in @xcite that the aforementioned coverings can show a certain incompleteness when going beyond the @xmath6-setting .
this is related to the fact that the lattice of ideals generated by the @xmath17 s is in general not distributive .
( this problem does not arise for @xmath6-algebras . )
hence we analyse a stronger notion of covering that includes this nontrivial assumption as part of the definition ( see definition  [ covdef ] ) . if all @xmath5 s are smash products , we arrive at a concept of piecewise trivial comodule algebras .
they appear to be a good noncommutative replacement of locally trivial compact principal bundles .
our motivation for going beyond @xmath6-algebras comes from the way we consider compact principal bundles ( the hausdorff property assumed ) .
we aim to use at the same time algebraic techniques of hopf - galois theory and analytic tools coming with @xmath6-algebras . to this end , we look at the total space of such a bundle in terms of the algebra of functions continuous along the base and polynomial along the fibres @xcite
. then the base space algebra is always a @xmath6-algebra , but , unless the group is finite , the total space algebra is not @xmath6 .
the data of a covering by @xmath3 pieces can be equivalently encoded into a flabby sheaf of algebras over @xmath18 .
this is the 2-element field @xmath7-projective space whose topology subbasis is its affine covering .
it is a finite space encoding the  combinatorics " of an @xmath3-covering , and is non - hausdorff unless @xmath19 .
the lattice of all open subsets of @xmath18 turns out to be isomorphic to a certain lattice of antichains in the set of all subsets of an @xmath3-element set . combining this with the chinese remainder theorem for distributive lattices of ideals in an arbitrary ring
, we prove that distributive lattices generated by @xmath3 ideals are equivalent to flabby sheaves over @xmath18 .
in particular , consider a compact hausdorff space @xmath8 with a covering by @xmath3 closed subsets @xmath9 .
then we have the soft sheaf of continuous functions with @xmath3 distinguished @xmath6-algebras @xmath20 .
however , the soft sheaf of complex - valued continuous functions on @xmath8 is not a sheaf of @xmath6-algebras .
therefore , there seems to be no evident way to use soft sheaves in the noncommutative setting . to overcome this difficulty
, we declare the closed sets open and consider @xmath8 with the new topology generated by these open sets .
this leads us to flabby sheaves over @xmath18 .    this way we obtain a covering version of gelfand s theorem : there is an equivalence between the category of compact hausdorff spaces with @xmath3-coverings by closed subsets and the category of flabby sheaves of unital commutative @xmath6-algebras over @xmath18 . in the noncommutative setting
, this sheaf - theoretic reformulation of coverings allows us to view piecewise trivial comodule algebras as introduced in this paper as what is called  locally trivial quantum principal bundles " in @xcite .    throughout
, we work over a field @xmath21 and all considered algebras , coalgebras etc .
are over @xmath21 .
an unadorned @xmath22 denotes the tensor product of @xmath21-vector spaces . for coproduct and coactions
we adopt the sweedler notation with the summation sign suppressed : @xmath23 , @xmath24 .
we recall here elementary facts concerning pullback diagrams that will be used in what follows . to focus attention , we consider the category of vector spaces , which suffices for our applications .
let @xmath25 and @xmath26 be linear maps of vector spaces .
the pullback ( fibre product ) @xmath27 of @xmath28 and @xmath29 is defined by a universal property , and turns out to be isomorphic to @xmath30    as a consequence of this description , we obtain : @xmath31 this is because for any linear map @xmath32 of vector spaces one has @xmath33 .
next , let us consider the following commutative diagram of linear maps @xmath34_\eta \ar[ddll]_{\phi_1 } \ar[ddrr]^{\phi_2 } & & \\   & & \overset{\phantom{\pi}}{v_1}\!\underset{\pi_1,\pi_2}{\times } \!v_2   \ar[dll]^{p_1 } \ar[drr]_{p_2 } & & \\
v_1 \ar[drr]_{\pi_1 } & & & & v_2 \ar[dll]^{\pi_2}\ , \\ & & v_{12 } & & } \ ] ] and show :    [ fib]assume that the @xmath35 s and @xmath36 s in the diagram ( [ hunz ] ) are surjective
. then @xmath37 is surjective if and only if @xmath38 .
assume first that @xmath37 is surjective , and @xmath39 .
then both @xmath40 and @xmath41 belong to @xmath42 , and there exist @xmath43 and @xmath44 such that @xmath45 and @xmath46 . clearly , @xmath47 .
therefore , as @xmath48 , @xmath49 , and @xmath50 we conclude that @xmath51 .
conversely , if @xmath52 is in the fibre product , then @xmath53 , so that @xmath54 for some @xmath55 and @xmath56 .
hence , for @xmath57 , we have @xmath58 .      we need a method yielding a presentation of elements in finitely generated distributive lattices .
we denote by @xmath59 the set of antichains in @xmath60 . for any @xmath61
we define @xmath62 it is easy to see that @xmath63 . if @xmath64 is a lattice generated by @xmath65 , then we define map @xmath66 , @xmath67 conversely , we define map @xmath68 , @xmath69 by the definition of @xmath70 it follows that for any @xmath71 , @xmath72 . on the other hand , as @xmath73 is a distributive lattice generated by the @xmath74 s , there exits @xmath61 such that @xmath75 .
note that for any @xmath76 , @xmath77 , and hence there exists @xmath78 such that @xmath79 .
it follows that @xmath80 and therefore @xmath81 .
thus , we have proven that for any finitely generated distributive lattice @xmath73
@xmath82    let us define two binary operations @xmath83 : @xmath84 it is immediate by the distributivity of @xmath73 that for all @xmath85 , @xmath86      let @xmath87 be a hopf algebra with bijective antipode .
a right @xmath1-comodule algebra @xmath0 is a unital associative algebra equipped with an @xmath1-coaction @xmath88 that is an algebra map . for a comodule algebra @xmath0 ,
we call @xmath89 the subalgebra of coaction - invariant elements in @xmath0
. the assumed existence of the inverse of the antipode allows us to define a left coaction @xmath90 by the formula @xmath91 .
this makes @xmath0 a left @xmath1-comodule and a left @xmath92-comodule algebra .
let @xmath0 be a right comodule algebra over a hopf algebra @xmath1 with bijective antipode , and let @xmath93 be the coaction - invariant subalgebra .
the comodule algebra @xmath0 is called _ principal _ if the following conditions are satisfied :    1 .   the coaction of @xmath1 is galois , that is , the map @xmath94 ( called the canonical map ) is bijective , 2 .   the comodule algebra @xmath0 is right @xmath1-equivariantly projective as a left @xmath16-module ,
i.e. , there exists a right @xmath1-colinear and left @xmath16-linear splitting of the multiplication map @xmath95 .
this splitting can always be chosen to be unital @xcite .
also , in this setting , one can show that the @xmath1-equivariant projectivity of @xmath0 over @xmath16 is equivalent to the faithful flatness of @xmath0 as a @xmath16-module @xcite .
if @xmath0 is a principal comodule algebra , then the extension of algebras @xmath96 is a special case of principal extensions defined in @xcite .
a cleft hopf - galois extension ( e.g. , a smash product @xmath97 of an @xmath1-module algebra @xmath16 by @xmath1 ) is always principal . indeed , by @xcite , cleft hopf - galois extensions always enjoy the normal basis property , and the latter can be viewed as equivariant freeness , a special case of equivariant projectivity . for more details and an introduction to hopf - galois theory , see , e.g. , @xcite .
the inverse of the canonical map defines a monomorphism @xmath98 , @xmath99 called the translation map .
it turns out that lifts of this map to @xmath100 that are both right and left @xmath1-colinear yield an equivalent approach to principality @xcite :    [ strongdef ] let @xmath1 be a hopf algebra with bijective antipode .
then a strong connection ( cf .
@xcite ) on a right @xmath1-comodule algebra @xmath0 is a unital linear map @xmath101 satisfying @xmath102 here @xmath103 is the lift of @xmath104 to @xmath100 .
the last property of the strong connection ( splitting of @xmath105 ) gives rise to the commutative diagram @xmath106 ^ -{\ell } \ar[d]_{1\otimes{\operatorname{\rm i d } } } &   p \otimes p \ar[dl]_{{\widetilde{\mathsf{can } } } } \ar[d]^{\text{canonical surjection}}\\ p \otimes h & \;\;p \otimes_b p \,.\ar[l]^{\,{\mathsf{can}}}}\ ] ] using the sweedler - type notation @xmath107 ( summation suppressed ) , we can write the bicolinearity and splitting property of a strong connection as follows : @xmath108 applying @xmath109 to the last equation yields a very useful formula : @xmath110    one can prove that an @xmath1-comodule algebra @xmath0 is principal if and only if it admits a strong connection @xcite .
given a strong connection @xmath111 , one can show that the formula @xmath112 defines the inverse of the canonical map @xmath104 , so that the coaction of @xmath1 is galois .
next , one can also show that @xmath113 is a splitting whose existence proves the equivariant projectivity .
much as above , one argues that the formula @xmath114 provides a left @xmath1-colinear and right @xmath16-linear splitting of the multiplication map@xmath115 .
the functions continuous along the base and polynomial along the fibre on a principal bundle with compact structure group have an analogue in the noncommutative setting : let @xmath116 be the @xmath6-algebra of a compact quantum group in the sense of woronowicz @xcite and @xmath1 its dense hopf @xmath117-subalgebra spanned by the matrix coefficients of the irreducible unitary corepresentations .
let @xmath118 be a unital @xmath6-algebra and let @xmath119 be a @xmath6-algebraic right coaction of @xmath116 on @xmath118 .
( see ( * ? ? ?
* definition 0.2 ) for a general definition and ( * ? ? ? * definition 1 ) for the special case of compact quantum groups . ) then the subalgebra @xmath120 of elements for which the coaction lands in @xmath121 ( algebraic tensor product ) , @xmath122 is an @xmath1-comodule algebra .
it follows from results of @xcite and @xcite that @xmath0 is dense in @xmath118 .
we call @xmath0 the comodule algebra associated to the @xmath6-algebra @xmath118 .
it is straightforward to verify that the operation @xmath123 commutes with taking fibre products .
note also that @xmath124 .
to show the piecewise nature of principality , we begin by proving lemmas concerning quotients and fibre products of principal comodule algebras .    [ fer ] let @xmath125 be a surjection of right @xmath1-comodule algebras ( bijective antipode assumed ) .
if @xmath0 is principal , then :    1 .
the induced map @xmath126 is surjective .
2 .   there exists a unital @xmath1-colinear splitting of @xmath127 .
it follows from the colinearity of @xmath127 that @xmath128 . to prove the converse inclusion , we take advantage of the left @xmath2-linear retraction of the inclusion @xmath129 that was used to prove ( * ? ? ?
* theorem  2.5(3 ) ) : @xmath130 here @xmath111 is a strong connection on @xmath0 and @xmath131 is any unital linear functional on @xmath0 .
if @xmath132 , then @xmath133 is a desired element of @xmath2 that is mapped by @xmath127 to @xmath134 . indeed , since @xmath135 , using the unitality of @xmath111 , @xmath127 and @xmath131 , we compute @xmath136    concerning the second assertion , one can readily verify that the formula @xmath137 defines a unital colinear splitting of @xmath127 . here
@xmath138 is any @xmath21-linear unital splitting of @xmath139 , e.g. , @xmath140 , and @xmath111 is again a strong connection on @xmath0 .
+    [ strocopuba ] let @xmath0 be a fibre product in the category of right @xmath1-comodule algebras : @xmath141   \ar[rd ] & \\ p_1 \ar[dr]_{\pi^1_2 } & & p_2 \ar[dl]^{\pi^2_1}\\ & p_{12}\ , . & } $ } \ ] ] then , if @xmath142 and @xmath143 are principal and @xmath144 and @xmath145 are surjective , @xmath0 is a principal comodule algebra
.    given strong connections @xmath146 and @xmath147 on @xmath142 and @xmath143 , respectively , we want to construct a strong connection on @xmath0 .
a first approximation for such a strong connection is as follows : @xmath148 here @xmath149 , and @xmath150 is a unital colinear splitting of @xmath145 , which exists by lemma  [ fer](2 ) .
the map @xmath151 is unital and bicolinear , but it does not split the lifted canonical map : @xmath152 now , let @xmath153 be the lifted canonical map on @xmath154 . applying the splitting of @xmath153 given by @xmath147 ( cf .
( [ ei0 ] ) ) to the right hand side of the above equation , gives a correction term for @xmath151 : @xmath155 this defines a bicolinear map into @xmath154 which annihilates 1 .
considering @xmath151 as a map into @xmath156 , we can add these two maps .
the map @xmath157 is still unital and bicolinear and splits the lifted canonical map on @xmath156 . remembering ( [ compa ] ) and ( [ elco ] ) , it is clear from the formula for @xmath158 that to make it taking values in @xmath159 we only need to add the term @xmath160 much as above , here @xmath161 and @xmath162 is a unital colinear splitting of @xmath163 , which exists by lemma  [ fer](2 ) .
the formula ( [ t ] ) defines a bicolinear map into @xmath164 which annihilates 1 . since the lifted canonical map on @xmath156 vanishes on @xmath164 , the sum @xmath165 splits the lifted canonical map , takes values in @xmath159 and is unital and bicolinear .
thus it is as desired a strong connection on @xmath0 .
+ let us now consider a family @xmath166 , @xmath167 , of surjections of right @xmath1-comodule algebras with @xmath168 .
denote @xmath169 . by lemma  [ fib ] and
formula  [ kereta ] , for any @xmath170 there is a fibre - product diagram of right @xmath1-comodule algebras @xmath171+<3mm,3 mm >   \ar[rd ] & \\
\save-<-3mm,0mm>*{p/(j_1 \cap \ldots \cap j_k ) }   \restore \mbox{\huge \   }   \save
< 3mm,-14 mm > * { } \ar[dr]_(.15){\pi^1_2 } \restore & & p / j_{k+1 } \ar[dl]^(.35){\pi^2_1}\\ & p/((j_1\cap\ldots\cap j_k)+j_{k+1 } ) & .}$}\ ] ] assume that all the @xmath172 are principal
. then lemma  [ strocopuba ] implies by an obvious induction that @xmath173 is principal for all @xmath174 .
in particular ( @xmath175 ) , @xmath0 is principal . on the other hand ,
if @xmath0 is principal then all the @xmath5 s are principal : if @xmath176 is a strong connection on @xmath0 , then @xmath177 is a strong connection on @xmath5 .
thus we have proved the following :    [ main ] let @xmath166 , @xmath167 , be surjections of right @xmath1-comodule algebras such that @xmath168 .
then @xmath0 is principal if and only if all the @xmath5 s are principal .
our next step is a statement about a relation between the ideals of a principal comodule algebra @xmath0 that are also subcomodules , and ideals in the subalgebra @xmath16 of coaction - invariant elements .
both sets are obviously lattices with respect to the operations @xmath178 and @xmath179 .
[ diens ] let @xmath0 be a principal right @xmath1-comodule algebra and @xmath93 the coaction - invariant subalgebra .
denote by @xmath180 the lattice of all ideals in @xmath16 and by @xmath181 the lattice of all ideals in @xmath0 which are simultaneously subcomodules .
then the map @xmath182 is a monomorphism of lattices .
the only non - trivial step in proving that @xmath183 is a homomorphism of lattices is establishing the inclusion @xmath184 . to this end
, we proceed along the lines of the proof of lemma  [ fer](1 ) . since @xmath185 is a comodule and an ideal , from the formula ( [ ei1 ] ) we obtain : @xmath186 now , let @xmath187 , @xmath188 , @xmath189 .
then ( [ stropro ] ) implies that @xmath190 applying any unital linear functional @xmath191 to the second tensor component implies @xmath192 . finally , since @xmath193 is a splitting of the multiplication map , it follows from ( [ stropro ] ) that @xmath194 .
this , in turn , proves the injectivity of @xmath195 .
+    much as the formula ( [ ei1 ] ) implies ( [ stropro ] ) , the formula ( [ ei2 ] ) implies @xmath196 therefore , since @xmath197 is a splitting of the right multiplication map , @xmath198 . combining this with the above discussed left - sided version yields @xmath199
note that the homomorphism @xmath195 is not surjective in general .
a counterexample is given by a smash product ( trivial principal comodule algebra ) of the laurent polynomials @xmath200 $ ] with the hopf algebra @xmath201 $ ] of laurent polynomials ( @xmath202 ) .
the action is defined by @xmath203 , @xmath204 .
viewing @xmath205 and @xmath206 as generators of @xmath0 , it is clear that @xmath207 .
it is straightforward to verify that , if @xmath208 is the two - sided ideal in @xmath16 generated by @xmath209 , then the right ideal @xmath210 is not a two - sided ideal of @xmath0 .
hence the map @xmath195 can not be surjective by ( [ linv ] ) .    in @xcite , families @xmath12 of algebra homomorphisms as in theorem  [ main ]
were called coverings .
however , it was explained therein that such coverings are well - behaved when the kernels @xmath17 generate a distributive lattice of ideals ( with respect to @xmath178 and @xmath179 as lattice operations ) .
hence we adopt in the present paper the following terminology :    [ covdef ] a finite family @xmath211 , @xmath212 , of surjective algebra homomorphisms is called a weak covering if @xmath213 . a weak covering
is called a _ covering _ if the lattice of ideals generated by the @xmath214 s is distributive .
the above definition can obviously be extended to the case when the @xmath36 s are algebra and @xmath1-comodule morphisms .
then the @xmath214 s are ideals and @xmath1-subcomodules .
the next claim is concerned with the distributivity condition from definition  [ covdef ] for coverings of principal comodule algebras .
it follows from proposition  [ diens ] and lemma  [ fer](1 ) .
[ auchmain ] let @xmath12 , @xmath212 , be surjective homomorphisms of right @xmath1-comodule algebras .
assume that @xmath0 is principal .
then @xmath215 is a covering of @xmath0 if and only if @xmath216 is a covering of @xmath2 .
the above corollary is particularly helpful when @xmath2 is a @xmath6-algebra because lattices of closed ideals in a @xmath6-algebra are always distributive ( due to the property @xmath217 ) .
we are now ready to propose a noncommutative - geometric replacement of the concept of local triviality of principal bundles .
since these are the closed rather than open subsets of a compact hausdorff space that admit a natural translation into the language of @xmath6-algebras , we use finite closed rather than open coverings to trivialize bundles . as is explained in ( * ? ? ?
* example  1.24 ) , there is a difference between these two approaches .
we reserve the term  locally trivial " for bundles trivializable over an open cover , and call bundles trivializable over a finite closed cover  piecewise trivial " .
it is the latter ( slightly more general ) property that we generalize to the noncommutative setting .
[ pipri ] an @xmath1-comodule algebra @xmath0 is called _ piecewise principal ( trivial ) _ if there exist comodule algebra surjections @xmath12 , @xmath212 , such that :    1 .   the restrictions
@xmath218 form a covering .
the @xmath5 s are principal .
( the @xmath5 s are isomorphic as @xmath1-comodule algebras to a smashed product @xmath219 . )
while not every compact principal bundle is piecewise ( or locally ) trivial ( ( * ? ?
* example  1.22 ) ) , every piecewise principal compact @xmath220-space ( i.e. , covered by finitely many compact principal @xmath220-bundles ) is clearly a compact principal @xmath220-bundle .
the second statement becomes non - trivial when we replace compact @xmath220-spaces by comodule algebras .
however , it is an immediate consequence of theorem  [ main ] and corollary  [ auchmain ] :    let @xmath1 be a hopf algebra with bijective antipode and @xmath0 be an @xmath1-comodule algebra that is piecewise principal with respect to @xmath221 . then @xmath0 is principal and @xmath221 is a covering of @xmath0 .
finally , let us consider the relationship between piecewise triviality and a similar concept referred to as  local triviality " in @xcite .
therein , sheaves @xmath222 of comodule algebras were viewed as quantum analogues of principal bundles .
they were called locally trivial provided that the space @xmath8 on which @xmath222 is defined admits an open covering @xmath223 such that all @xmath224 s are smash products .
if we assume such a sheaf to be flabby ( that is , for all open subsets of @xmath225 , @xmath226 , the restriction maps @xmath227 are surjective ) , then we can use theorem  [ main ] to deduce the principality of all @xmath228 s :    [ niema ] let @xmath1 be a hopf algebra with bijective antipode and @xmath222 be a flabby sheaf of @xmath1-comodule algebras over a topological space @xmath8 .
if @xmath223 is a finite open covering such that all @xmath224 s are principal , then @xmath228 is principal for any open subset @xmath229 .
in this section , we focus entirely on a flabby - sheaf interpretation of distributive lattices of ideals defining coverings of algebras ( see definition  [ covdef ] ) .
we will explain that for a flabby sheaf in corollary  [ niema ] , the underlying topological space plays only a secondary role and can be replaced by a certain space that is universal for all @xmath3-element coverings .
this space is the 2-element field @xmath230-projective space @xmath231 whose topology subbasis is its affine covering , i.e. , it is the topology generated by the subsets @xmath232    consider now an arbitrary space @xmath8 with a finite covering @xmath233 . define on @xmath8 the topology generated by the @xmath234 s ( considered as open sets ) and pass to the quotient by the equivalence relation @xmath235 obviously , @xmath236 depends on the specific features of the covering @xmath223 .
however , for a fixed @xmath3 , it can always be embedded into @xmath237 :    [ embedding ]    let @xmath238 be any set equipped with the topology generated by the @xmath234 s .
let @xmath239 be the quotient map defined by the equivalence relation ( [ paul ] ) .
then @xmath240 is an embedding of topological spaces .
it is immediate that @xmath241 is well defined and injective .
next , since @xmath242 is open for each @xmath243 , all @xmath244 s are open in the quotient topology on @xmath245 . now
the continuity of @xmath241 follows from the fact that @xmath246 s form a subbasis of the topology of @xmath237 .
the key step is to show that images of open sets in @xmath245 are open in @xmath247 .
first note that by the definition of the relation  ( [ paul ] ) , @xmath248 therefore , as preimages and images preserve unions and any open set in @xmath8 is the union of intersections of @xmath234 s , @xmath249 is an open map . on the other hand , by the surjectivity of @xmath249 , we have @xmath250 for any subset @xmath251 . hence it follows that a set in @xmath245 is open if and only if it is an image under @xmath249 of an open set in @xmath8 . finally , by the definition of @xmath241 , @xmath252 and the claim follows from the distributivity of @xmath179 with respect to @xmath253 .
+ note that the map @xmath254 is a homeomorphism precisely when the @xmath234 s are in a generic position , that is when all intersections @xmath255 such that @xmath256 are non - empty .
thus we have shown that if we consider @xmath8 and the @xmath234 s as in corollary  [ niema ] , then the composition @xmath257 is continuous .
hence we can produce flabby sheaves over @xmath237 by taking direct images of flabby sheaves over @xmath8 .
they will have the same sections globally and on the covering sets . in this sense
, they carry an essential part of the data encoded in the original sheaf .
let @xmath258 .
denote by @xmath259 $ ] the class of @xmath260 in @xmath261 .
define a family of closed sets @xmath262\in { \mathbb p}^{n-1}({\mathbb c})\;|\ ;    @xmath263 s cover @xmath8 , and moreover , for all @xmath264 such that @xmath265 , @xmath266 , the element @xmath267\in x , \text{\ where\ } x_i=\left\{{{\!\!\!1 \text{\ if\ } i\in\lambda}\atop { 0 \text{\ otherwise}}}\right.\ ] ] belongs to @xmath268 .
it follows that the @xmath263 s are in generic position and the map @xmath269 ( proposition  [ embedding ] ) is a homeomorphism ( if @xmath270 is considered with finite topology as in proposition  [ embedding ] ) .
let @xmath271\in{\mathbb p}^{n-1}({\mathbb c})\;|\ ; x_i\neq 0\;\},\ \ \
i=1,\ldots , n\ ] ] be the standard ( open ) affine cover of @xmath261 and @xmath272 be the homeomorphism @xmath273 \mapsto ( x_1/x_i,\ldots,\widehat{x_i / x_i},\ldots , x_{n}/x_i).\ ] ] observe that for all @xmath274 , @xmath275 and latexmath:[\[\psi_i(x_i)=\{(y_1,\ldots , y_{n-1})\in{\mathbb c}^{n-1}\;|\;\forall_j\ ;    sets .
our next aim is to demonstrate that flabby sheaves over @xmath237 are just a reformulation of the notion of covering introduced in definition  [ covdef ] .
it turns out that the distributivity condition discussed in the previous section is the key property needed to reconcile the results from @xcite with those from @xcite .
in particular , our results imply the principality of pflaum s noncommutative instanton bundle ( see the last section for details ) .
let us consider the lattice @xmath277 of open subsets of @xmath18 generated by the @xmath246 s ( [ ai ] ) .
[ upperin ] if @xmath278 , for some @xmath61 then @xmath279 .
suppose that @xmath280 .
therefore , for all @xmath281 there exists @xmath282 , such that @xmath283 .
then @xmath284 as @xmath246 s are in generic position ( see the remark after proposition  [ embedding ] ) . hence @xmath285 can not be contained in @xmath286 .    by lemma  [ upperin ] ,
it is clear that @xmath287 as @xmath288 , it follows that for any @xmath61 , @xmath289 thus , for any @xmath290 , using ( [ idcone ] ) , ( [ latticeid ] ) and ( [ mordot ] ) , @xmath291 similarily one can show that @xmath292 hence , we have proven    [ isomlattice ] the map @xmath293 is an isomorphism of distributive lattices ( with @xmath294 ) where @xmath59 is a distributive lattice with meet and join operations defined in ( [ meetjoin ] ) .    in the following proposition ,
we use the above results for the lattice @xmath277 of open subsets of @xmath18 and the lattice @xmath295 of ideals generated by the kernels of surjections forming an @xmath3-covering . for the first lattice , we consider the category of flabby sheaves over @xmath18 , and for the second , the category of @xmath3-coverings of algebras . here
`` @xmath3-covering '' means a covering by @xmath3 surjections , and a morphism between @xmath3-coverings @xmath215 and @xmath296 consists of morphisms @xmath297 and @xmath298 such that @xmath299 .
[ nagut ] let @xmath300 be the category of @xmath3-coverings of algebras , and @xmath301 be the category of flabby sheaves of algebras over @xmath18 .
then the following assignments @xmath302 yield an equivalence of categories .
suppose we are given a flabby sheaf @xmath222 of algebras over @xmath18 .
let @xmath303 denote the restriction map for any open @xmath304,@xmath305 , @xmath306 .
for brevity , we write @xmath307 instead of @xmath308 , if @xmath309 . by the flabbiness of @xmath222 , the morphisms @xmath310 ( see ( [ ai ] ) ) are surjective .
the property @xmath311 follows from the sheaf condition .
it remains to prove the distributivity of the lattice generated by the kernels of @xmath310 s .
lattices of sets are always distributive , so that it is enough to show that the assignment @xmath312 defines a surjective morphism from the lattice of open subsets of @xmath18 onto the lattice of ideals generated by @xmath313 s . here by a morphism of lattices we mean a map that transforms the union and intersection of open subsets to the intersection and sum of ideals , respectively .    to show this , let @xmath314 , @xmath315 be open subsets of @xmath316 .
since @xmath222 is a sheaf , we know that @xmath317 is the fibre product of @xmath318 and @xmath319 .
now it follows from ( [ kereta ] ) that @xmath320 , as needed .
similarly , since the sheaf @xmath222 is flabby , lemma  [ fib ] implies that @xmath321 .
thus we have shown that ( [ gga ] ) assigns coverings to flabby sheaves .
conversely , assume that we are given a covering . for brevity ,
let us denote for any @xmath322 , @xmath323 .
let @xmath304 , @xmath314 be open subsets of @xmath18 such that @xmath324 . for all @xmath325 , @xmath326 which implies that there exists a subset @xmath327 such that @xmath328 .
it is then clear that @xmath329 and one can define restriction map @xmath330 hence @xmath222 is a presheaf .
let @xmath304 be an open subset of @xmath18 and let @xmath331 be an open covering of @xmath304 ( i.e. @xmath332 ) .
suppose that @xmath333 is a family of elements , where for each @xmath334 , @xmath335 , and @xmath336 . by the distributivity of lattice of ideals generated by @xmath214 and generalised chinese remainder theorem ,
( see e.g.  @xcite , theorem  18 on p.  280 ) there exists an element @xmath337 such that , for all @xmath243 , @xmath338 .
it is easy to see that if @xmath339 , for any open subsets @xmath304 , @xmath314 of @xmath18 then this element is unique . but
this follows by lemma  [ isomlattice ] and ( [ mordot ] )
.    denote assignement in ( [ ggb ] ) by @xmath340 and functor defined by ( [ gga ] ) by @xmath220 .
the functoriality of @xmath220 is immediate .
let @xmath341 , @xmath342 be the morphism of @xmath3-coverings @xmath215 and @xmath296 .
note that from @xmath299 it follows that for all @xmath243 , @xmath343 .
accordingly , for any open subset @xmath304 of @xmath18 , @xmath344 , and therefore for all open @xmath304 , the following family defines a map of corresponding sheaves @xmath345    that @xmath346 is a functor naturally isomorphic to identity functor in the category of @xmath3-coverings is obvious , as @xmath347 and @xmath348 .    on the other hand
suppose that we are given a flabby sheaf @xmath222 . by the sheaf property , for any open sets @xmath304 , @xmath314 , @xmath349 is a fibre product of @xmath228 and @xmath318 over @xmath350 . then using flabbines
, we can apply lemma  [ fib ] and formula [ kereta ] to conclude that @xmath351 then by the property that assignement @xmath352 is a morphism of lattices and again using flabbiness one sees that for all open @xmath304 , @xmath353 , but this immedietaly shows that @xmath354 is naturally isomorphic to identity functor on @xmath301 , which ends the proof .
+ since the intersection of closed ideals in a @xmath6-algebra equals their product , lattices of closed ideals in @xmath6-algebras are always distributive .
thus we immediately obtain :    [ claco ] compact hausdorff spaces with a fixed covering by @xmath3 closed subsets are equivalent to flabby sheaves of commutative unital @xmath6-algebras over @xmath18 .    here
, the zero algebra is allowed as a unital @xmath6-algebra .
this is needed if the closed sets are not in generic position .
the set of unital morphisms from the zero @xmath6 algebra to any other is understood to be empty .
in this last section we recall from @xcite the construction of examples for the above concepts that illustrate possible areas of applications .
if @xmath220 is a compact group , then the join @xmath355 becomes a @xmath220-principal fibre bundle over the unreduced suspension @xmath356 of @xmath220 , see e.g.  @xcite , proposition  vii.8.8 or @xcite .
for example , one can obtain the hopf fibrations @xmath357 and @xmath358 in this way using @xmath359 and @xmath360 , respectively . recall that @xmath355 is obtained from @xmath361 \times g \times g$ ] by shrinking to a point one factor @xmath220 at @xmath362 $ ] and the other factor @xmath220 at @xmath363 .
@xmath364{pict215.eps } \nonumber\ ] ]    alternatively , one can shrink @xmath365 at @xmath366 to the diagonal .
this picture is generalised in @xcite .
our aim in this first part of section  [ examples ] is to describe a noncommutative analogue of this construction that nicely fits into our general concepts and will be studied in greater detail in @xcite .    to this end ,
let @xmath1 be the hopf algebra underlying a compact quantum group @xmath116 ( see @xcite or chapter  11 of @xcite for details ) .
we define @xmath367,\bar h ) \otimes h\,|\ ,      f(0 ) \in \delta(h)\},\nonumber\\   & & p_2:=\{f \in c([0,1],\bar h ) \otimes h\,|\ ,      f(1 ) \in \mathbb{c } \otimes h\}\nonumber\end{aligned}\ ] ] which will play the roles of the two trivial pieces of the principal extension . here
we identify elements of @xmath368,\bar h ) \otimes h$ ] with functions @xmath361
\rightarrow \bar h \otimes h$ ] .
the @xmath5 s become @xmath1-comodule algebras by applying the coproduct of @xmath1 to @xmath1 , @xmath369,\bar h ) } \otimes \delta$ ] , and the subalgebras of @xmath1-invariants can be identified with @xmath370,\bar h)\,|\,f(0 ) \in \mathbb{c}\ } ,            \nonumber\\   & & b_2:=\{f \in c([0,1],\bar h)\,|\,f(0 ) \in
\mathbb{c}\}.            \nonumber \end{aligned}\ ] ] furthermore , @xmath371 , @xmath372 , where @xmath1 acts on @xmath373 via the adjoint action , @xmath374 , @xmath375 $ ] , see @xcite .
now one can define @xmath0 as a glueing of the two pieces along @xmath376 , that is , as the pull - back @xmath377 of the @xmath5 s along the evaluation maps @xmath378 theorem  [ main ] implies that @xmath0 is principal .
based on the idea of a heegaard splitting of @xmath379 into two solid tori , a noncommutative deformation of @xmath379 was proposed in @xcite . on the level of @xmath6-algebras
, it can be presented as a fibre product @xmath380 of two @xmath6-algebraic crossed products @xmath381 and @xmath382 of the toeplitz algebra @xmath383 by @xmath384 .
we denote the isometries generating @xmath383 in the two algebras by @xmath385 . the @xmath384-actions are implemented by unitaries @xmath386 , respectively , in the following way : @xmath387 the fibre product is taken over @xmath388 with action @xmath389 , where @xmath390 is the generator of @xmath391 and @xmath392 is the unitary giving the @xmath384-action in this algebra .
the corresponding surjections defining the fibre product are @xmath393 there is a natural @xmath394-action on @xmath380 corresponding classically to the action in the hopf fibration , see @xcite .
its restriction to the two crossed products is not the canonical action of @xmath394 viewed as the pontryagin dual of @xmath384 .
however , to obtain the canonical actions one can identify @xmath380 with a fibre product of the same crossed products , but formed with respect to the surjections @xmath395 the identification is given by @xmath396+<-3mm,3mm>_{\pi^1_2 } \ar@/^2pc/[rrrrr]^{\phi_1 } & &   { \mathcal{t}}\rtimes_{-\theta } \mathbb{z } \ar[ld]+<3mm,3mm>^{\pi^2_1 } \ar@/^2pc/[rrrrr]^{\phi_2 } & & & { \mathcal{t}}\rtimes_{\theta } \mathbb{z } \ar[rd]+<-3mm,3mm>_{\hat\pi^1_2 } & &   { \mathcal{t}}\rtimes_{-\theta } \mathbb{z}\ar[ld]+<3mm,3mm>^{\hat\pi^2_1}\\ & \save[]*\txt{$c(s^1 ) \rtimes_{\theta } \mathbb{z}$\mbox{\ } } \ar[rrrrr]+<-12mm,0mm>^-{\phi_{12}}\restore & & & & & \save[]*\txt{$c(s^1 ) \rtimes_{\theta } \mathbb{z}$}\restore & . } } \ ] ] here isomorphisms @xmath397 are given on respective generators by @xmath398    the @xmath6-subalgebra of @xmath394-invariants is the @xmath6-algebra of the mirror quantum 2-sphere from @xcite . as mentioned in the introduction
, we can pass from @xmath380 to the associated principal extension , and this procedure commutes with taking fibre products . in this way , we obtain a subalgebra @xmath399 which is a piecewise trivial @xmath400-comodule algebra , so that it fits the setting of this paper .
the invariant subalgebra @xmath2 is again the @xmath6-algebra of the mirror quantum 2-sphere .    on the other hand
, there is a second natural hopf - like @xmath394-action on @xmath401 described in @xcite ( see also @xcite ) .
again , its restriction to the two crossed products making up the fibre product @xmath401 is not the canonical action of @xmath394 .
this fibre product can be transformed into an isomorphic one ( carrying the canonical @xmath394-action ) constructed by gluing two copies of @xmath382 over @xmath402 ( with generators @xmath403 ) using the gluing maps    @xmath404    the identifying maps are now given by @xmath396+<-3mm,3mm>_{\pi^1_2 } \ar@/^2pc/[rrrrr]^{\tilde\phi_1 } & &   { \mathcal{t}}\rtimes_{-\theta } \mathbb{z } \ar[ld]+<3mm,3mm>^{\pi^2_1 } \ar@/^2pc/[rrrrr]^{\tilde\phi_2 } & & & { \mathcal{t}}\rtimes_{-\theta } \mathbb{z } \ar[rd]+<-3mm,3mm>_{\check\pi^1_2 } & &   { \mathcal{t}}\rtimes_{-\theta } \mathbb{z}\ar[ld]+<3mm,3mm>^{\check\pi^2_1}\\ & \save[]*\txt{$c(s^1 ) \rtimes_{\theta } \mathbb{z}$\mbox{\ } } \ar[rrrrr]+<-13mm,0mm>^-{\tilde\phi_{12}}\restore & & & & & \save[]*\txt{$c(s^1 ) \rtimes_{-\theta } \mathbb{z}$}\restore & . } } \ ] ]    here isomorphisms @xmath397 are given on generators by @xmath405    the subalgebra of @xmath394-invariants is now the @xmath6-algebra of the generic podle quantum 2-sphere from @xcite .
however , note that it is not possible to obtain the algebraic podle sphere in this way by replacing @xmath406 by the coordinate algebra of a quantum disc with generator @xmath407 satisfying @xmath408 @xcite .
this is related to the fact that already in the commutative case the algebra of polynomial functions on a sphere has no covering corresponding to two hemispheres  there are no nontrivial polynomials vanishing on a hemisphere .
therefore to be in this setting of fibre products we use more complete algebras , e.g. , @xmath6-algebras .
the authors are very grateful to pawe  witkowski for producing the join picture , and to gabriella bhm , tomasz brzeziski , george janelidze , dorota marciniak , tomasz maszczyk , fred van oystaeyen , marcin szamotulski and elmar wagner for discussions .
this work was partially supported by the european commission grants eif-515144(uk ) , mktd - ct-2004 - 509794 ( rm ) , the polish government grants1  p03a  036  26 ( pmh , rm ) , 115/e-343/spb/6.pr ue / die 50/2005 - 2008 ( pmh , bz ) , and the university of d grant 795 ( bz ) .
pmh is also grateful to the max planck institute for mathematics in the sciences in leipzig for its hospitality and financial support .