To me this makes sense. How complex is the subsystem for what is configurable?

In any case if you were to include it in the tx/xts subsystem, you would probably need to include the same config elements there, so the complexity apart from an extra extension/subsystem would likely be the same.

On 20 Mar 2013, at 14:36, Paul Robinson wrote: > All, > > To use our implementation of the REST-AT spec, a developer has jump through a lot of hoops. We'd like to remove these hoops making it easier for users to get started with distributed transactions over REST. > > The subsystem would carry out the following steps, that are currently the burden of the application developer: > > 1. Deploy a war application containing the transaction coordinator. > 2. Register some interceptors for deployments that use REST-AT > 3. Register a single REST endpoint (for all applications) to receive protocol messages from remote coordinators. > 4. Start the recovery manager > > So, I'm pretty sure we should do these steps in a subsytem. > > The next question is, do we create a new subsytem, or add this to one of the existing transaction subsytems (transactions or xts)? > > The transactions subsytem contains the bulk of the transactions functionality. The XTS subsytem contains just enough to distribute transactions over Web services, delegating the core transaction management capabilities to the transaction subsytem. I think we need another subsytem called 'RTS' that provides the REST specific functionality of REST-AT and delegates to the transaction subsytem for the core transaction management capabilities. > > The other benefit of having XTS and RTS in separate subsytems is that they can be separately enabled/disabled. This is especially important when you consider that each depend on a transport (Web services and REST) which may not be enabled. > > My concern with creating another subsytem is that it is yet another thing to maintain. Maybe you are trying to keep the number of subsytems low? > > Paul. > > -- > Paul Robinson > Web Service Transactions Lead > paul.robinson(a)redhat.com > > JBoss, a Division of Red Hat > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson > (USA), Charlie Peters (USA) > > _______________________________________________ > jboss-as7-dev mailing list > jboss-as7-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jboss-as7-dev --------------------------------------- Kabir Khan Prinicipal Software Engineer JBoss by Red Hat

So I think an extra subsystem sounds fine On 20 Mar 2013, at 15:26, Paul Robinson wrote: > Kabir, > > On 20 Mar 2013, at 15:13, Kabir Khan <kabir.khan(a)jboss.com&gt; wrote: > >> To me this makes sense. How complex is the subsystem for what is configurable? > > The subsytem is unlikely to have much configuration. It will probably only have one or two options initially. > >> In any case if you were to include it in the tx/xts subsystem, you would probably need to include the same config elements there, so the complexity apart from an extra extension/subsystem would likely be the same. > > I don't think the RTS subsytem would share much/anything with the XTS subsytem, so I think combining them would result in the same amount of code lumped into one subsytem. > >> On 20 Mar 2013, at 14:36, Paul Robinson wrote: >> >>> All, >>> >>> To use our implementation of the REST-AT spec, a developer has jump through a lot of hoops. We'd like to remove these hoops making it easier for users to get started with distributed transactions over REST. >>> >>> The subsystem would carry out the following steps, that are currently the burden of the application developer: >>> >>> 1. Deploy a war application containing the transaction coordinator. >>> 2. Register some interceptors for deployments that use REST-AT >>> 3. Register a single REST endpoint (for all applications) to receive protocol messages from remote coordinators. >>> 4. Start the recovery manager >>> >>> So, I'm pretty sure we should do these steps in a subsytem. >>> >>> The next question is, do we create a new subsytem, or add this to one of the existing transaction subsytems (transactions or xts)? >>> >>> The transactions subsytem contains the bulk of the transactions functionality. The XTS subsytem contains just enough to distribute transactions over Web services, delegating the core transaction management capabilities to the transaction subsytem. I think we need another subsytem called 'RTS' that provides the REST specific functionality of REST-AT and delegates to the transaction subsytem for the core transaction management capabilities. >>> >>> The other benefit of having XTS and RTS in separate subsytems is that they can be separately enabled/disabled. This is especially important when you consider that each depend on a transport (Web services and REST) which may not be enabled. >>> >>> My concern with creating another subsytem is that it is yet another thing to maintain. Maybe you are trying to keep the number of subsytems low? >>> >>> Paul. >>> >>> -- >>> Paul Robinson >>> Web Service Transactions Lead >>> paul.robinson(a)redhat.com >>> >>> JBoss, a Division of Red Hat >>> Registered in England and Wales under Company Registration No. 03798903 >>> Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson >>> (USA), Charlie Peters (USA) >>> >>> _______________________________________________ >>> jboss-as7-dev mailing list >>> jboss-as7-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev >> >> --------------------------------------- >> Kabir Khan >> Prinicipal Software Engineer >> JBoss by Red Hat >> > > -- > Paul Robinson > Web Service Transactions Lead > paul.robinson(a)redhat.com > > JBoss, a Division of Red Hat > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (USA), Brendan Lane (Ireland), Matt Parson > (USA), Charlie Peters (USA) > --------------------------------------- Kabir Khan Prinicipal Software Engineer JBoss by Red Hat