| [open-measured-data-wg] Technology decisions |
Hello everyone, As most of you have noticed, the recent Architecture Draft document makes no mention of OSGi at all. The main reason behind this is that the architecture per se is defined in terms of logical structures and not technologies (although some JSRs are mentioned however their usage does not contradict OSGi if it were to be a chosen technology). The architecture can be decided in 3 layers: #1 paints a picture of how pieces fall together into the puzzle. This is what you currently see in the document. #2 defines the technologies that can fulfil the architecture. OSGi is a candidate technology. #3 defines the products that supply the technologies. Eclipse Equinox is a container that provides OSGi support. Given that the majority of stakeholders have agreed so far that the architecture is sound, we can proceed with selecting the technologies that can realise it. Perhaps one of the reasons why the topic “why OSGi is not mentioned?” arises is that there’s a previous document (the OpenMDM Tag dated Feb 2014) where OSGi was a selected technology. This decision was made at a time where the requirements were known. However requirements have change since, most notably: - do not reuse code from OpenMDM4. Components must be designed afresh. - UI independence. - remove dependency on CORBA as much as possible. The proposed architecture addressed these concerns (you’ll find them listed as main drivers at the beginning of the document). During a meeting of the Architecture project we decided to come up with a matrix of options to be able to select a candidate technology that can fulfil many of the architecture goals and design. The following entries were identified: - service lifecycle. Start/Stop. Implies a bootstrapping mechanism or container of sorts. - configuration of services. - service discovery. - service connection. Services can establish a link (local and/remote) to other services in order to consume their behaviour. - dependencies between services. - failover. Shutdown a misbehaving service. Bring back a dead service. - supporting different versions of the same library in the same process. This means a service may bring dependencies whose versions are incompatible with another one within the same container, still both services can work in unison. As you may notice OSGi and OSGi containers fulfil most of these requirements however there are other technologies that can make it happen too. Please remember that OSGi was proposed and developed at a time (more than 10 years ago) where alternatives were not ready. It’s 2015 and we have those alternatives at hand. We also have to think about the future of the platform as a whole. Without further ado, I’d like to ask you if there are any other requirements that you may see must be covered by this matrix. I’ll compile all results and generate the matrix with candidate technologies for review next week. Please reply with suggestions at your earliest convenience. Cheers, Andres
|