Petals Distribution

Deprecate the old domain/subdomain style of topology

Details

  • Description:
    Hide

    The runtime architecture of a bus in terms of container is described using a topology.

    Currently, a topology is made of a domain and subdomains: the idea being that one subdomain is attached to one registry (and thus one implementation of it) and can see each others. The domain was the complete bus
    The objective was to enable communication between subdomains at one point.

    In practice, this has never been implemented, and the concept of subdomain doesn't bring anything that the concept of domain already bring.
    Moreover, after some discussion, it seems that it is better to use the concept of domains combined with a BC for propagating services inbetween them as described in PETALSDISTRIB-175.

    Hence, we should remove the concept of subdomains (as it is now) and move its current functionalities (such as containing containers, having a registry, attaching container to a subdomain, detaching, querying, etc) to the concept of domain.

    This will have impacts mainly on the Container (including JMX administration, topology definition and WS API extension) (PETALSESBCONT-351) and the Petals CLI (PETALSESBCLI-125).

    We should also take the opportunity to make the registry more independent of the style of the topology (PETALSREGOVER-7 and PETALSREGCLI-5).

    Show
    The runtime architecture of a bus in terms of container is described using a topology. Currently, a topology is made of a domain and subdomains: the idea being that one subdomain is attached to one registry (and thus one implementation of it) and can see each others. The domain was the complete bus The objective was to enable communication between subdomains at one point. In practice, this has never been implemented, and the concept of subdomain doesn't bring anything that the concept of domain already bring. Moreover, after some discussion, it seems that it is better to use the concept of domains combined with a BC for propagating services inbetween them as described in PETALSDISTRIB-175. Hence, we should remove the concept of subdomains (as it is now) and move its current functionalities (such as containing containers, having a registry, attaching container to a subdomain, detaching, querying, etc) to the concept of domain. This will have impacts mainly on the Container (including JMX administration, topology definition and WS API extension) (PETALSESBCONT-351) and the Petals CLI (PETALSESBCLI-125). We should also take the opportunity to make the registry more independent of the style of the topology (PETALSREGOVER-7 and PETALSREGCLI-5).
  • Environment:
    -

Issue Links

Activity

Victor NOËL made changes - Thu, 15 Oct 2015 - 13:55:31 +0200
Field Original Value New Value
Link This issue blocks PETALSDISTRIB-177 [ PETALSDISTRIB-177 ]
Victor NOËL made changes - Thu, 15 Oct 2015 - 13:56:00 +0200
Status New [ 10000 ] Open [ 10002 ]
Priority Major [ 3 ]
Assignee Christophe DENEUX [ cdeneux ] Victor NOËL [ vnoel ]
Victor NOËL made changes - Thu, 15 Oct 2015 - 14:25:05 +0200
Link This issue depends on PETALSESBCONT-351 [ PETALSESBCONT-351 ]
Victor NOËL made changes - Thu, 15 Oct 2015 - 14:32:49 +0200
Link This issue blocks PETALSREGOVER-7 [ PETALSREGOVER-7 ]
Victor NOËL made changes - Thu, 15 Oct 2015 - 14:42:58 +0200
Link This issue blocks PETALSREGCLI-5 [ PETALSREGCLI-5 ]
Victor NOËL made changes - Thu, 15 Oct 2015 - 15:03:00 +0200
Description The runtime architecture of a bus in terms of container is described using a topology.

Currently, a topology is made of a domain and subdomains: the idea being that one subdomain is attached to one registry (and thus one implementation of it) and can see each others. The domain was the complete bus
The objective was to enable communication between subdomains at one point.

In practice, this has never been implemented, and the concept of subdomain doesn't bring anything that the concept of domain already bring.
Moreover, after some discussion, it seems that it is better to use the concept of domains combined with a BC for propagating services inbetween them as described in PETALSDISTRIB-175.

Hence, we should remove the concept of subdomains (as it is now) and move its current functionalities (such as containing containers, having a registry, attaching container to a subdomain, detaching, querying, etc) to the concept of domain.

This will have impacts on the Container and its topology definition, the Registry, Petals Admin JMX things, Petals CLI and the WS API extension
The runtime architecture of a bus in terms of container is described using a topology.

Currently, a topology is made of a domain and subdomains: the idea being that one subdomain is attached to one registry (and thus one implementation of it) and can see each others. The domain was the complete bus
The objective was to enable communication between subdomains at one point.

In practice, this has never been implemented, and the concept of subdomain doesn't bring anything that the concept of domain already bring.
Moreover, after some discussion, it seems that it is better to use the concept of domains combined with a BC for propagating services inbetween them as described in PETALSDISTRIB-175.

Hence, we should remove the concept of subdomains (as it is now) and move its current functionalities (such as containing containers, having a registry, attaching container to a subdomain, detaching, querying, etc) to the concept of domain.

This will have impacts mainly on the Container (including JMX administration, topology definition and WS API extension) (PETALSESBCONT-351) and the Petals CLI (PETALSESBCLI-125).

We should also take the opportunity to make the registry more independent of the style of the topology (PETALSREGOVER-7 and PETALSREGCLI-5).
Victor NOËL made changes - Thu, 15 Oct 2015 - 15:03:25 +0200
Link This issue depends on PETALSESBCLI-125 [ PETALSESBCLI-125 ]
Victor NOËL made changes - Thu, 15 Oct 2015 - 16:54:17 +0200
Status Open [ 10002 ] In Progress [ 10003 ]
Victor NOËL made changes - Thu, 15 Oct 2015 - 16:54:22 +0200
Status In Progress [ 10003 ] Resolved [ 10004 ]
Fix Version/s 5.0.0 [ 10574 ]
Resolution Fixed [ 1 ]
Transition Status Change Time Execution Times Last Executer Last Execution Date
New New Open Open
2m 37s
1
Victor NOËL
Thu, 15 Oct 2015 - 13:56:00 +0200
Open Open In Progress In Progress
2h 58m
1
Victor NOËL
Thu, 15 Oct 2015 - 16:54:17 +0200
In Progress In Progress Resolved Resolved
5s
1
Victor NOËL
Thu, 15 Oct 2015 - 16:54:22 +0200

People

Dates

  • Created:
    Thu, 15 Oct 2015 - 13:53:23 +0200
    Updated:
    Thu, 15 Oct 2015 - 16:54:22 +0200
    Resolved:
    Thu, 15 Oct 2015 - 16:54:22 +0200