Open Services Gateway Initiative
Specification
The OSGi specification is developed by the members in an open process and
made available to the public free of charge under the OSGi Specification
License. The OSGi Alliance has a compliance program that is open to members
only. As of November 2010, there are seven certified OSGi framework implementations.
A separate page lists both certified and non-certified OSGi Specification Implementations,
which include OSGi frameworks and other OSGi specifications.
Any framework that implements the
OSGi standard provides an environment for the modularization of applications
into smaller bundles. Each bundle is a tightly coupled, dynamically loadable
collection of classes, jars, and configuration files that explicitly declare
their external dependencies (if any).
Architecture
The framework is conceptually
divided into the following areas:
Bundles
Bundles are normal jar components with extra manifest headers.
Services
The services layer connects bundles in a dynamic way by
offering a publish-find-bind model for plain old Java Interfaces (POJI) or Plain Old Java
Objects POJO.
Services
Registry
The API
for management services (ServiceRegistration,
ServiceTracker
and ServiceReference).
Life-Cycle
The API
for life cycle management for (install, start, stop, update, and uninstall)
bundles.
Modules
The layer that defines encapsulation and declaration of
dependencies (how a bundle can import and export code).
Security
The layer that handles the security aspects by limiting
bundle functionality to pre-defined capabilities.
Execution
Environment
Defines what methods and classes are available in a specific
platform. There is no fixed list of execution environments, since it is subject
to change as the Java Community Process creates new
versions and editions of Java. However, the following set is currently
supported by most OSGi implementations:
·
OSGi/Minimum-1.0
·
OSGi/Minimum-1.1
·
JRE-1.1
·
From J2SE-1.2 up to J2SE-1.6
Sumber : http://en.wikipedia.org/wiki/OSGi
Automotive
Multimedia Interface Collaboration adalah sebuah kelompok yang dibuat oleh
pembuat/pabrik automotive untuk menciptakan standar umum untuk mengatur
bagaimana perangkat elektronik, seperti computer dan unit-unit hiburan
berkomunikasi dengan kendaraan.
Tapi kenapa perlu ada Automotive Multimedia Interface Collaboration? Ternyata para pembuat/pabrik automotive mengkhawatirkan bahwa perangkat elektronik dan multimedia akan tidak cocok/tidak kompatibel dengan kendaraan; bahwa perangkat tersebut dapat mengganggu elektronik yang mengontrol sistem keselamatan dan bahwa organisasi standar yang ada tidak akan bergerak cukup cepat. Oleh karena itu terbentuklah Automotive Multimedia Interface Collaboration.
Atau dengan kata lain Automotive Multimedia Interface Collaboration (AMI-C) adalah organisasi global yang mewakili mayoritas dunia produksi kendaraan.
Tapi kenapa perlu ada Automotive Multimedia Interface Collaboration? Ternyata para pembuat/pabrik automotive mengkhawatirkan bahwa perangkat elektronik dan multimedia akan tidak cocok/tidak kompatibel dengan kendaraan; bahwa perangkat tersebut dapat mengganggu elektronik yang mengontrol sistem keselamatan dan bahwa organisasi standar yang ada tidak akan bergerak cukup cepat. Oleh karena itu terbentuklah Automotive Multimedia Interface Collaboration.
Atau dengan kata lain Automotive Multimedia Interface Collaboration (AMI-C) adalah organisasi global yang mewakili mayoritas dunia produksi kendaraan.
AMIC didirikan pada Oktober 1998 dengan tujuan untuk mengembangkan
serangkaian spesifikasi umum untuk multimedia. Automotive Multimedia
Interface Collaboration (AMI-C) sudah memiliki anggota : Fiat, Ford, General
Motors, Honda, Mitsubishi, Nissan, PSA Peugeot-Citroen, Renault. AMI-C
mengembangkan dan men-standarisasi antarmuka multimedia dan telematika otomotif
yang umum untuk jaringan komunikasi kendaraan. Dan 40 pemasok elektronik
mendaftarkan diri untuk menulis standar. Mereka berpendapat untuk menulis
standar diperlukan waktu selama 2 tahun. Tapi dua tahun adalah masa di
telematika. Penyelenggara elektronik, ponsel, komputer dan peralatan video yang
akan menggunakan koneksi dapat melewati beberapa generasi dalam waktu itu.
Dua bagian
penting dari spesifikasi AMI-C adalah Vehicle Service Interface (VSI) API dan
Human Machine Interface (HMI) API. VSI API yang menyediakan cara seragam
mengakses informasi tentang status kendaraan, seperti tingkat bahan bakar atau
informasi diagnostik, serta kontrol menyediakan fungsi-fungsi kendaraan
tertentu, seperti kunci pintu. HMI API yang menyediakan aplikasi perangkat
lunak dengan metode untuk mengirim dan menerima informasi ke atau dari sopir
atau penumpang kendaraan tanpa aplikasi memiliki pengetahuan sebelum kendaraan
khusus perangkat HMI, seperti speaker, display, tombol dan switch.
Tujuan utamanya adalah untuk:
·
Menyediakan
interface standar untuk memungkinkan pengendara mobil untuk menggunakan
berbagai media, komputer dan perangkat komunikasi - dari sistem navigasi dan
hands-free telepon selular, melalui manusia maju / mesin sistem antarmuka,
termasuk pengenalan suara dan sintesis, untuk dipersembahkan komunikasi jarak
dekat ( DSRC) sistem untuk kendaraan untuk infrastruktur komunikasi dan sistem
mobil seperti airbag, pintu kunci dan diagnostik input / output;
·
Meningkatkan
pilihan dan mengurangi keusangan sistem elektronik kendaraan.
·
Memotong biaya
keseluruhan informasi kendaraan dan peralatan hiburan dengan meningkatkan
ukuran pasar yang efektif dan memperpendek waktu pengembangan - industri
otomotif efektif terdiri dari banyak pasar yang kecil karena setiap platform kendaraan
sering mengandung berbagai adat-mengembangkan komponen dan platform yang khas
hanya sekitar 50.000 unit
·
Menawarkan standar
terbuka dan spesifikasi untuk informasi interface dalam kendaraan dan antara
kendaraan dan dunia luar.
The Automotive Multimedia Interface
Colaboration (AMI-C) mengumumkan hak cipta seluruh dunia penugasan dari
otomotif 1394, spesifikasi teknis kepada Asosiasi Perdagangan 1394. Berikut
document AMI-C yang sekarang milik 1394TA :
· AMI-C 3.023 Power Management Spesifikasi
· AMI-C 3.013 Power Management Arsitektur
· AMI-C 2001 1.0.2 common Pesan Set Power Management
· AMI-C Uji 3.034 Document Manajemen Power
· AMI-C 4.001 Revisi Spesifikasi Fisiksumber : http://hasanahrainism.blogspot.com/2012/12/bagaimana-fungsional-kolaborasi.html
Java Community Process
The Java Community Process (JCP), established in 1998, is a formalized mechanism that allows interested parties to develop standard technical specifications for Java technology. Anyone can become a JCP Member by filling a form available at the JCP website. JCP membership for organizations and commercial entities requires annual fees but is free for individuals.
The JCP involves the use of Java Specification Requests (JSRs) – the formal documents that describe proposed specifications and technologies for adding to the Java platform. Formal public reviews of JSRs take place before a JSR becomes final and the JCP Executive Committee votes on it. A final JSR provides a reference implementation that is a free implementation of the technology in source code form and a Technology Compatibility Kit to verify the API specification.
A JSR describes the JCP itself. As of 2009, JSR 215 describes the current version (2.7) of the JCP.
sumber : http://en.wikipedia.org/wiki/Java_Community_Process
