Kamis, 10 Desember 2009

Supply Chain Produk Biskuit Kaleng



Di dalam pembuatan biscuit kaleng dipabrik biscuit (manufacture) dibutuhkan bahan-bahan yang dibagi ke dalam :

1.Bahan Baku, antara lain gandum (tepung terigu), telur, gula (tebu), garam, mentega, kaleng (aluminium)

2.Bahan Pelengkap, antara lain obat pengembangan biscuit, pengawet makanan, dan lain-lain.

Bahan-bahan tersebut didapat dari supplier-supplier antara lain :

· Supplier Terkecil : Penghasil Gandum, Penghasil Tebu, Penghasil Garam, Penghasil Mentega, Penghasil Telur, Penghasil Obat Pengembang, Penghasil Pengawet makanan, Penghasil Alumunium, dan Pengahsil Plastik.

· Suppllier Besar : Pabrik Tepung Terigu, Pabrik Gula, Pabrik Gula, Pabrik Obat Pengembang, Pabrik Pengawet Makanan, Pabrik Kaleng,dan Pabrik Plastic.

Setelah bahan-bahan dipasok ke pabrik biscuit, lalu diolah dan diuji laboraturium terlebih dahulu. Setelah itu disimpan didalam gudang, barulah didistribusikan oleh para distributor yang dibagi menjadi : distributor local dan distributor luar negri. Dari distributor lalu disalurkan ke supermarket-supermaket (wholesaler) dan barulah sampai ditangan konsumen.



Selasa, 08 Desember 2009

Open Services Gateway Initiative (OSGi)

Open Service Gateway Initiative (OSGI)

OSGI (Open Service Gateway Initiative) adalah sebuah rencana industri untuk cara standar untuk menghubungkan perangkat seperti perangkat rumah tangga dan sistem keamanan ke Internet. OSGI berencana menentukan program aplikasi antarmuka (API) untuk pemrogram menggunakan, untuk memungkinkan komunikasi dan kontrol antara penyedia layanan dan perangkat di dalam rumah atau usaha kecil jaringan. OSGI API akan dibangun pada bahasa pemrograman Java. Program java pada umumnya dapat berjalan pada platform sistem operasi komputer. OSGI adalah sebuah interface pemrograman standar terbuka. The OSGI Alliance (sebelumnya dikenal sebagai Open Services Gateway inisiatif, sekarang nama kuno) adalah sebuah organisasi standar terbuka yang didirikan pada Maret 1999. Aliansi dan anggota – anggotanya telah ditentukan sebuah layanan berbasis Java platform yang dapat dikelola dari jarak jauh.Spesifikasi OSGI yang dikembangkan oleh para anggota dalam proses terbuka dan tersedia untuk umum secara gratis di bawah Lisensi Spesifikasi OSGI. OSGI Alliance yang memiliki program kepatuhan yang hanya terbuka untuk anggota. Pada Oktober 2009, daftar bersertifikat OSGI implementasi berisi lima entri.

Manfaat dalam penerapan OSGI ini antara lain :

· Mengurangi Kompleksitas (Reduced Complexity) – Mengembangkan dengan teknologi OSGi berarti mengembangkan bundel: komponen OSGi. Bundel adalah modul. Mereka menyembunyikan internal dari bundel lain dan berkomunikasi melalui layanan didefinisikan dengan baik. Menyembunyikan internals berarti lebih banyak kebebasan untuk berubah nanti. Hal ini tidak hanya mengurangi jumlah bug, itu juga membuat kumpulan sederhana untuk berkembang karena bundel ukuran benar menerapkan sepotong fungsionalitas melalui interface didefinisikan dengan baik. Ada sebuah blog menarik yang menjelaskan teknologi OSGi apa yang mereka lakukan bagi proses pembangunan

· Reuse – Para model komponen OSGi membuatnya sangat mudah untuk menggunakan banyak komponen pihak ketiga dalam suatu aplikasi. Peningkatan jumlah proyek-proyek sumber terbuka memberikan JAR’s mereka siap dibuat untuk OSGi. Namun, perpustakaan komersial juga menjadi tersedia sebagai bundel siap pakai.

· Real World – OSGi kerangka kerja yang dinamis. Ini dapat memperbarui bundel on the fly dan pelayanan yang datang dan pergi. Ini dapat menghemat dalam penulisan kode dan juga menyediakan visibilitas global, debugging tools, dan fungsionalitas lebihy daripada yang telah dilaksanakan selama satu solusi khusus.

· Easy Deployment – teknologi OSGi bukan hanya sebuah standard untuk komponen, tapi juga menentukan bagaimana komponen diinstal dan dikelola. API telah digunakan oleh banyak berkas untuk menyediakan sebuah agen manajemen. Agen manajemen ini bisa sesederhana sebagai perintah shell, TR-69 sebuah protokol manajemen pengemudi, OMA DM protokol sopir, komputasi awan antarmuka untuk Amazon EC2, atau IBM Tivoli sistem manajemen. Manajemen standar API membuatnya sangat mudah untuk mengintegrasikan teknologi OSGi dalam sistem yang ada dan masa depan.

· Dynamic Updates – Model komponen OSGi adalah model dinamis. Kumpulan dapat diinstal, mulai, berhenti, diperbarui, dan dihapus tanpa menurunkan keseluruhan sistem. Banyak pengembang Java tidak percaya ini dapat dilakukan pada awalnya oleh karena itu tidak digunakan dalam produksi. Namun, setelah menggunakan ini dalam pembangunan selama beberapa waktu, sebagian besar mulai menyadari bahwa itu benar-benar bekerja dan secara signifikan mengurangi waktu penyebaran.

· Simple - The OSGi API sangat sederhana. API inti hanya terdiri dari satu paket dan kurang dari 30 kelas / interface. API inti ini cukup untuk menulis kumpulan, menginstalnya, start, stop, update, dan menghapus mereka dan mencakup semua pendengar dan keamanan kelas.

· Kecil (Small) – The OSGi Release 4 Framework dapat diimplementasikan kedalam JAR 300KB. Ini adalah overhead kecil untuk jumlah fungsi yang ditambahkan ke salah satu aplikasi dengan memasukkan OSGi. Oleh karena itu OSGi berjalan pada berbagai macam perangkat: dari sangat kecil, kecil, dan untuk mainframe. Hanya meminta Java VM minimal untuk menjalankan dan menambahkan sangat sedikit di atasnya.

· Cepat (Fast) – Salah satu tanggung jawab utama dari Framework OSGi memuat kelas-kelas dari bundel. Di Java tradisional, JARs benar-benar terlihat dan ditempatkan pada daftar linear. Pencarian sebuah kelas memerlukan pencarian melalui daftar ini. Sebaliknya, pra-kabel OSGi bundel dan tahu persis untuk setiap bundel bundel yang menyediakan kelas. Kurangnya pencarian yang signifikan faktor mempercepat saat startup.

Teknologi OSGi meliputi :

· The Problem (Permasalahan)

· The Solution (Pemecahan Masalah)

· The Framework (Kerangka Kerja)

· Standard Services (Pelayanan Standard)

· Framework Services (Pelayanan Kerangka Kerja)

· System Services (Pelayanan Sistem)

· Protocol Services (Pelayanan Protokol)

· Miscellaneous Services (Bermacam-macam pelayanan)

· Conclusion (Kesimpulan)

Framework OSGi :



Komponen inti dari Spesifikasi OSGi adalah Framework OSGi. Framework menyediakan lingkungan standar untuk aplikasi (disebut bundel).


Layer-layer OSGI



· Bundels – komponen OSGi yang dibuat oleh pengembang

· Services – Layanan bundel menghubungkan lapisan dalam cara yang dinamis dengan menawarkan menerbitkan-menemukan-model mengikat Jawa lama untuk menikmati objek.

· Life Cycle – The API untuk instalasi, start, stop, update, dan menghapus bundel.

· Modules – Lapisan yang mendefinisikan bagaimana sebuah bundel dapat mengimpor dan mengekspor kode.

· Security (Keamanan) – Lapisan yang menangani aspek keamanan.

· Execution Environment (Eksekusi Lingkungan) – Menetapkan metode dan kelas-kelas apa saja yang tersedia dalam platform tertentu.

Penjelasan:

  1. Bundel
    Kumpulan jar normal komponen dengan nyata tambahan header. Sebuah
    bundel adalah sekelompok kelas Java dan sumber daya tambahan yang dilengkapi dengan rincian file pada MANIFEST.MF nyata semua isinya, serta layanan tambahan yang diperlukan untuk memberikan kelompok termasuk kelas Java perilaku yang lebih canggih, dengan tingkat deeming seluruh agregat sebuah komponen.
  1. Layanan
    Layanan yang menghubungkan lapisan bundel dalam cara yang dinamis dengan menawarkan, menerbitkan dan menemukan model dapat mengikat Java lama untuk menikmati objek (POJO). Siklus hidup menambahkan lapisan bundel dinamis yang dapat diinstal, mulai, berhenti, diperbarui dan dihapus. Buntalan bergantung pada lapisan modul untuk kelas loading tetapi menambahkan API untuk mengatur modul – modul dalam run time. Memperkenalkan lapisan siklus hidup dinamika yang biasanya bukan bagian dari aplikasi. Mekanisme ketergantungan luas digunakan untuk menjamin operasi yang benar dari lingkungan.
  1. Layanan Registrasi (Services-Registry)

API untuk manajemen jasa (ServiceRegistration, ServiceTracker dan ServiceReference).
OSGi Alliance yang telah ditentukan banyak layanan. Layanan yang ditentukan oleh antarmuka Java. Kumpulan dapat mengimplementasikan antarmuka ini dan mendaftarkan layanan dengan Layanan Registri. Layanan klien dapat menemukannya di registri, atau bereaksi ketika muncul atau menghilang.

  1. Siklus Hidup (Life-Cycle)

API untuk manajemen siklus hidup untuk (instal, start, stop, update, dan uninstall) bundel.

  1. Modul
    Lapisan yang mendefinisikan enkapsulasi dan deklarasi dependensi (bagaimana sebuah bungkusan dapat mengimpor dan mengekspor kode).

  1. Keamanan
    Layer yang menangani aspek keamanan dengan membatasi fungsionalitas bundel untuk pra didefinisikan kemampuan.
  1. Pelaksanaan Lingkungan

Mendefinisikan metode dan kelas apa yang tersedia dalam platform tertentu. Tidak ada daftar tetap eksekusi lingkungan, karena dapat berubah sebagai Java Community Process menciptakan versi baru dan edisi Jawa. Namun, set berikut saat ini didukung oleh sebagian besar OSGI implementasi:







Middleware Telematika

Middleware

Apakah middleware itu? Istilah “middleware” dapat diartikan sebagai sebuah perangkat lunak yang menghubungkan komponen perangkat lunak atau aplikasi. Middleware memungkinkan data yang terdapat dalam satu database diakses dari tempat lain. Ini cocok untuk integrasi aplikasi enterprise dan data integration software.
Teknologi ini dikembangkan untuk menyediakan interoperabilitas dalam mendukung arsitektur distribusi yang koheren, sering digunakan untuk mendukung dan menyederhanakan aplikasi distribusi yang kompleks termasuk web server, aplikasi server, dan tools serupa yang mendukung pengembangan aplikasi dan pengiriman. Middleware menyatukan teknologi informasi modern berdasarkan XML, SOAP, web service, dan service-oriented architecture.
Middleware berada di tengah-tengah antara perangkat lunak aplikasi pada sistem operasi yang berbeda. Mirip dengan arsitektur 3-tier. Contohnya seperti software EAI, software telekomunikasi, transaksi monitor, messaging and querying software.
Perbedaan antara sistem operasi dan fungsionality middleware, fungsi kernel inti hanya dapat diberikan oleh sistem operasi itu sendiri. Beberapa fungsionalitas middleware yang sebelumnya disediakan terpisah, kini telah terintegrasi dalam sistem operasi.
Dalam simulasi teknologi, middleware umumnya digunakan dalam konteks arsitektur tingkat tinggi (HLA) yang diterapkan pada banyak simulasi distribusi. Middleware terdiri dari fungsi library, dan memungkinkan sejumlah aplikasi simulasi seperti HLA federates ke halaman fungsi-fungsi ini dari library umum daripada menciptakan kembali untuk setiap aplikasi.
Vendor-vendor seperti IBM, Red Hat, dan Oracle Corporation adalah pemasok utama yang menyediakan perangkat lunak middleware. Kelompok-kelompok seperti Apache Software Foundation dan ObjectWeb Consortium mendorong pengembangan dari open source middleware. Pada dasarnya arsitektur Microsoft .NET “Framework” merupakan middleware dengan fungsi yang didistribusikan antara berbagai produk.
Manfaat dari middleware itu sendiri yaitu memungkinkan aplikasi :
• Transparansi di seluruh jaringan sehingga menyediakan interaksi dengan layanan atau aplikasi lain
• Independen dari layanan jaringan
• Handal dan selalu tersedia

Middleware menawarkan beberapa keunggulan untuk bisnis dan industri. Dalam bisnis sering digunakan untuk menghubungkan informasi dari departemen database seperti penggajian, penjualan, dan akuntansi. E-Commerce juga menggunakan middleware ini untuk membantu dalam menangani transaksi cepat dan aman di berbagai jenis lingkungan komputer. Singkatnya, middleware telah menjadi elemen penting di berbagai industri, berkat kemampuannya untuk menyatukan sumber daya yang berbeda di seluruh jaringan atau platform komputasi.
Jenis Middleware
Hurwitz mengatur sistem klasifikasi berbagai jenis middleware yang tersedia saat ini. Klasifikasi ini didasarkan pada skalabilitas dan recoverability :
• Remote Procedure Call
Klien membuat panggilan dengan prosedur yang berjalan pada sistem remote. Dapat asinkron atau sinkron.
• Message Oriented Middleware
Pesan yang dikirim ke client dikumpulkan dan disimpan sampai ditindaklanjuti, sementara client terus dengan pengolahan lain.
• Object Request Broker
Jenis ini memungkinkan aplikasi untuk mengirim permintaan dalam suatu sistem berorientasi objek.
• SQL-oriented Data Access
Middleware antara aplikasi dan database server
• Embedded Middleware
Layanan komunikasi dan integrasi antarmuka software / firmware yang beroperasi antara aplikasi dan real time operating system.


Ref :
http://en.wikipedia.org/wiki/Middleware

Arsitektur

Arsitektur 2-tier dan 3-tier

Pada awalnya client / server merupakan sebuah sistem yang saling berhubungan dalam sebuah jaringan yang memiliki dua komponen utama yaitu client dan server. Istilah ini kemudian dikenal juga dengan “2-tier”. Kemudian istilah tier itu sendiri digunakan untuk menjelaskan pembagian sebuah aplikasi yang melalui client dan server. Saat ini, pembagian proses kerja telah menjadi bagian utama dari konsep client / server sehingga proses pembagian kerja telah diatur lebih spesifik.

2-tier membagi proses load ke dalam 2 bagian. Aplikasi utama berjalan pada sisi client yang biasanya mengirimkan request dalam bentuk sintax SQL ke sebuah database server yang fungsinya menyimpan data.

Perkembangan internet dan jaringan yang pesat saat ini tidak memungkinkan lagi diselesaikan dengan metode 2-tier client / server. Aplikasi client / server berskala luas telah dikembangkan dan kini muncul E-Commerce yang berbasis internet. Hal tersebut tentunya membuat aplikasi-aplikasi semakin kompleks. Aplikasi-aplikasi tersebut dibagi menjadi beberapa komponen dan didistribusikan melalui multiprocesor. Banyak perusahaan besar yang sudah menggunakan client / server mulai merasakan 2-tier tidak relevan lagi untuk diimplementasikan kembali. Itu disebabkan karena perusahaan dituntut harus dapat mendukung internet dan semua komponennya. Aplikasi tersebut harus dapat melayani ribuan komputer client dimana aplikasi ini sering berjalan pada banyak server dan terdiri dari ratusan komponen-komponen software di dalamnya. Kemudian lahirlah istilah 3-tier.

3-tier membagi proses loading antara :

1. Komputer client menjalankan GUI logic

2. Aplikasi server menjalankan business logic

3. Database atau legacy aplication

3-tier menjelaskan pembagian secara fisik dari sebuah aplikasi yang melalui terminal (tier ke-1), minicomputer (tier ke-2), dan mainframe (tier ke-3).

Dengan pembagian kerja seperti itu maka 3-tier client / server lebih populer dibandingkan dengan 2-tier client / server. Kriteria yang cocok untuk menggunakan model arsitektur 3-tier client / server diantaranya :

· Banyaknya layanan atau class aplikasi lebih dari 50

· Program aplikasi dibuat dalam beberapa bahasa pemrograman yang berbeda untuk masing-masing organisasi

· Dua atau lebih data source yang heterogen seperti dua DBMS yang berbeda

· Suatu aplikasi akan digunakan lebih dari 3 tahun. Apalagi jika kita akan merencanakan banyak modifikasi atau penambahan

· Beban kerja yang sangat tinggi misalnya lebih dari 50000 transaksi perhari

Ekspektasi bahwa aplikasi akan terus berkembang sepanjang waktu