Hi Andres,
I agree that we should rely on technologies which are specified in a JSR to build on reliable standards. However, the current formulation in the
specification draft does not list any JSR as required: “should be specified using JSR-303”, “should conform to JSR-343” (which is only if JMS is used), “recommended to use” (JSR-330 and/or JSR-346). I propose to change these formulations to be more strict,
i.e. “must” and “required”, where applicable.
Since selecting a JSR directly implies a technology choice, the implications of that choice must be discussed first. Especially the use of OSGi[1]
has not been on the table so far although it also affects the Event Bus[2].
So long,
Andreas
[1]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=457424#c2
[2]
https://bugs.eclipse.org/bugs/show_bug.cgi?id=457427
Von: open-measured-data-wg-bounces@xxxxxxxxxxx [mailto:open-measured-data-wg-bounces@xxxxxxxxxxx]
Im Auftrag von Andres Almiray
Gesendet: Donnerstag, 22. Januar 2015 17:30
An: The open MDM Working group mailing list.
Betreff: Re: [open-measured-data-wg] Minutes of Architecture Committee Conference Call on 2015-01-16
Hello everyone,
I’d like to address the point of the JSRs. The idea for proposing those standards is to make sure that components implemented by different vendors at different timeframes can be used within the same application. You may think of the OpenMDM(tm)
5 API as the standard for MDM powered applications, however the MDM layer is but one of the many layers that interact together. Relying on JSRs protect the component’s APIs as you can move from one implementation to the next with relative ease. I should point
that the 4 listed JSRs must be complemented by the following two:
- JSR-305 Annotations for Softare Defect Detection
- JSR-311 JAX-RS: API for RESTful WebServices
Must be used to define the REST endpoints
Thus, these JSRs are neither examples nor recommendations but the basis for deriving the specification on an OpenMDM(tm) Component.
please find attached the minutes of the conference call along with the specification draft discussed.
Andreas Benzing
Diplominformatiker
System-/Softwareingenieur
Business Unit Automotive
Informatik Consulting Systems AG
Address: Sonnenbergstr. 13, 70184 Stuttgart / Mailing Address: Postfach 102431, 70020 Stuttgart, Germany
Domicile and Court of Registry: Stuttgart / Commercial Register No.: HRB 18569
Chairman: Dr. Philipp Bauer / Management Board: Franz-Josef Winkel, Cid Kiefer
This e-mail message may contain confidential and/or privileged information. If you are not an addressee or otherwise authorized to
receive this message, you should not use, copy, disclose or take any action based on this e-mail or any information contained in the message. If you have received this material in error, please advise the sender immediately by reply e-mail and delete this
message. Thank you.
<20150116_architecture_committee.pdf><openmdm-architecture-20150115.zip>_______________________________________________
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