Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [open-measured-data-wg] Technology decisions

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.

 

Cheers,

Andres

 

 

Andres Almiray
Canoo Engineering AG
Kirschgartenstrasse 5
CH-4051 Basel

Tel: +41 61 228 94 44
Fax: +41 61 228 94 49

andres.almiray@xxxxxxxxx
http://www.canoo.com

 

On 13 Feb 2015, at 14:15, Andres Almiray <andres.almiray@xxxxxxxxx> wrote:



Dear all,

 

Please find the sources of Technology matrix document at git.eclipse.org/gitroot/mdmweb/org.eclipse.mdmweb.architecture.git

I’m attaching a rendered copy of the document to his message.

 

Cheers,

Andres

 

<technology.html>

 

 

 

Andres Almiray
Canoo Engineering AG
Kirschgartenstrasse 5
CH-4051 Basel

Tel: +41 61 228 94 44
Fax: +41 61 228 94 49

andres.almiray@xxxxxxxxx
http://www.canoo.com

 

On 30 Jan 2015, at 10:52, Andres Almiray <andres.almiray@xxxxxxxxx> wrote:



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

 

 

Andres Almiray
Canoo Engineering AG
Kirschgartenstrasse 5
CH-4051 Basel

Tel: +41 61 228 94 44
Fax: +41 61 228 94 49

andres.almiray@xxxxxxxxx
http://www.canoo.com

 

_______________________________________________
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

 

 


Back to the top