Hi Andres,
thank you for the reminder!
The compiled Technology Matrix and Architecture are also available at
https://wiki.eclipse.org/Open-Measured-Data-Management-WG/Architecture_Committee
There are actually two points which I think should be addressed.
First, the document primarily considers the question how to satisfy the dependencies of an openMDM component. The question how the artifacts created
for openMDM can be used to fulfil the dependencies of others is not discussed. Although this scenario is not essential to create a successful measured data management solution, it provides the foundation to cooperate with other projects.
Second, the distinction between the alternatives is not entirely clear. Even if some alternatives consists of multiple technologies, they should
be grouped to a single instance and evaluated as such. I understand that the possibility to change the composition as needed is a major benefit. However, the technology is most certainly going to be the same for each requirement in one component and should
also be consistent across components to facilitate the goal of an openMDM model kit. In other words, having an individual setup for each component makes it virtually impossible for the openMDM AC/QC to verify the conformity to any specification. Speaking of
committees, I think having a table with the pros and cons condensed to --/-/0/+/++ would not only help to clearly identify alternatives but also might encourage people who otherwise get lost in the details to join the discussion.
Another minor remark: Could you maybe add a list of acronyms?
So long,
Andreas
Von: open-measured-data-wg-bounces@xxxxxxxxxxx [mailto:open-measured-data-wg-bounces@xxxxxxxxxxx]
Im Auftrag von Andres Almiray
Gesendet: Dienstag, 17. Februar 2015 12:11
An: The open MDM Working group mailing list.
Betreff: Re: [open-measured-data-wg] Technology decisions
Dear all,
Any comments and feedback on the linked document (see attachment on previous message) are greatly appreciated.
Dear all,
I’m attaching a rendered copy of the document to his message.
<technology.html>
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.
- 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 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.
_______________________________________________
open-measured-data-wg mailing list
open-measured-data-wg@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/open-measured-data-wg