Archive for the ‘Bigi Edinme’ Category

Hangi portu hangi program kullanıyor.

Şubat 13, 2017

netstat -o -n -a | findstr 0.0:8080 verilen PID no görevyöneticisinden hangi uygulamanın kullandığını göre biliriz

SQL Developer Setup Configuration

Kasım 30, 2015

…/sqldeveloper/sqldeveloper/bin/sqldeveloper.conf

SetJavaHome ../../jdk

terminalde Jdk yı indirdiğiniz klasörün içerisine gelerek (teyit etmek için bulunduğunun klasörün icinde bin klasörü var ise doğru yerdesiniz) pwd komutunu yazıp enter a basarsanız o klasörün path ini vercecektir.

Memcache, ehcache, redis gibi cache Sistemleri Nedir?

Ekim 3, 2013

1. Caching Nedir?
Çok sıklıkla istekte bulunulan ancak içerigi çok fazla değişmeyen sayfaların ya da istekte bulunulan içeriklerin tekrar tekrar oluşturulma sürecine girmeden, daha önce hazır olarak tutulan nesneden cevap verilmesi sürecini yönetmektir.
Lokal Caching Sistemleri: Kullanıcı program ile caching sisteminin aynı hafıza alanında
Global Caching Sistemleri: Birden fazla sunucu üzerine dağıtık olarak
2. Memcached
Yüksek trafikli sitelerin vazgeçilmez yazılımlarından biri olan memcache tüm dünyada milyonlarca site tarafından kullanılıyor.
Memcache yüksek trafikli sitelerde tampon bellek oluşturmak için Danga Interactive tarafından LiveJournal için geliştirilen bir sistemdir. Proje her ne kadar LiveJournal için geliştirilse de özellikle Facebook mühendisleri tarafından daha da geliştirilerek işlemci ve ram kullanımında %20 ile %30′ luk bir performans artışı sağlanmıştır.
Yüksek trafik alan dinamik web uygulamalarının veri tabanına gitme sayısını azaltmayı, bu sayede de, performansı artırmayı hedefleyen bir uygulamadır.
Memecached Unix, Linux, Windows ve MacOSX üzerinde çalışabilmekte ve serbest yazılım lisansı altında dağıtılmaktadır (BSD).
3.EhCache
Hibernate gibi populer O/R Mapping araçları Second Level Caching’i default olarak destekliyor.
Second Level Cache tools:
a-JBossCache:
b-EHCache : Cache araçları içerisindeki en hızlı ve en kolay uygulanabilir olanı. EHCache’in de memory ve disk tabanlı caching desteği mevcut. EHCache bir çok open-source ve lisanlı uygulama tarafından kullanılmakta. EHCache’in de cluster desteği mevcut.
c-OSCache :
d-SwarmCache :

4.Redis
Redis, açık kaynak kodlu olarak geliştirilmiş, kullanıcı program ile aynı hafıza alanında (in memory) faaliyette bulunan bir anahtar-değer (key-value) veri deposudur. ANSI C koduyla geliştirilen Redis, VMware tarafından desteklenmektedir.

Kaynak
http://www.bilgisayarkavramlari.com/2012/11/07/caching-mekanizmalari/
http://www.frmtr.com/c/4503208-caching-onbellekleme-sqlcachde-dependency.html
http://www.teknolojioku.com/haber/php-ile-memcache-kullanimi-35.html
http://mustafatan.blogspot.com/2006_09_01_archive.html

JPA Nedir?

Ağustos 15, 2013

Java Persistence API (JPA), Object Relational Mapping (ORM) teknoloji apilerinden bir tanesi olup database tarafinda tum table larin program tarafinda ki bir (entity) class a denk gelmesi ve tum islemlerinin bu (entity) class uzerinde yapilmasini sağlayan bir teknolojidir.
Amaç tabi ki sadece bu değil. JPA teknolojisi ile, veritabanı ile bilgi alışverişi esnasında veri güvenliği ve performans da üst düzeye çıkarılmış olur.

Entity
JPA’yı kullanarak veri tabanında kalıcı kılınacak olan nesneye entity denir. Bir nesnenin entity olması için gerek ve yeter şart o nesnenin kendisinden üretileceği sınıfın ya @Entity notuyla notlandırılması ya da XML ayarlarında entity olarak ifade edilmesidir. (Biz bu yazıda genel olarak notlu ayarı temel alacağımızdan okuyucu, aksi söylenmedikçe bütün ayarların notlarla ifade edildiğini varsaymalıdır.) Entity bir iç sınıf (inner class), bir interface ya da enum tipi veya final olmamalıdır ve public ya da protected olan bir argumansız yapılandırıcısı (no-arg constructor) olmalıdır.

Entitynin veri tabanında saklanancak olan kalıcı durumu (persistent state), tamamen nesne değişkenlerinden oluşacaktır. Bu yüzden kalıcı durumun parçası olacak nesne değişkenleri final olmamalıdır. Nesne değişkenleri private olabilir hatta olmalıdır ve kalıcı olan nesnenin istemcileri (client), nesnenin değişkenlerine get/set metotları ile ulaşmalıdır. Entitylerin kalıcılığının minimum sayıda alandan (nesne değişkeni) oluşması gerektiği düşünüldüğünde, veri tabanında kalıcı olması gerekmeyen değişkenler @Transient ile notlandırılması gerekir.

Bir sınıfın entity olması için teorik olarak zorunlu olmamakla birlikte konulmadığında pratikte pek çok sıkıntı çıkardığı için gerekli olarak belirttiğimiz bir diğer not ise @Id’dir. Bu not, notlandırdığı alanın, içinde bulunduğu nesnenin kimlik (identity) bilgisini ifade etmesini ve veri tabanında da bir anahtar alana (primary key) karşı gelmesini sağlamaktadır.

JPA, bir JPA ürünü ve kullanılacak veri tabanıyla ilgili olarak yapılacak ayarları classpathde META-INF klasörünün altında persistence.xml isimli bir dosyada olmasını bekler.
persistence.xml dosyasındaki her kalıcılık birimi için bir JPA sağlayıcı (provider) belirtilmelidir.

jpa1

Bir entity sınıfındaki eşleştireceğiniz ilk alan daima o sınıftan oluşturulan nesnelerin ayırt edici özelliği olan ve @Id ile notlandırılan kimlik (identity) alanı olmalıdır. Bazen kimlik bilgisinin, veri tabanı gibi bir yapı tarafından ardışıl olarak üretilmesini isteriz. Bu durumda @GeneratedValue notu ile bu not içinde @GenerationType notunu kullanıp, JPA sağlayıcının ve veri tabanının özelliklerine göre mümkün olan kimlik bilgisi üretme stratejilerinden en uygun olanını seçebiliriz. @GeneratedValue notu isteğe bağlı iki özellik alır: String tipinde bir üretici ile GenerationType enum tipinde bir üretim tipi. GenerationType’ın, AUTO, IDENTITY, SEQUENCE ve TABLE olmak üzere 4 nesnesi vardır. Örneğin Customer2 sınıfının custId alanını, üretim şeklini Hibernate’e bırakarak aşağıdaki gibi notlandırabiliriz:
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Column(name = “CUSTOMERID”) private long custId;
Hibernate bu durumda Oracle XE’de HIBERNATE_SEQUENCE isimli bir dizi (sequence) oluşturup Customer2 sınıfının kimlik bilgisini buradan üretmektedir. Bu durumda Test sınıfımızda artık Customer2 nesnelerini oluştururken kimlik bilgisi geçmemeliyiz, aksi taktirde hata alırız.

EntityManager

Özellikle geliştirme ve test amaçlı olarak hızlıca yazılan uygulamalarda JPA’in veri tabanında şema (schema) oluşturma yeteneğinden faydalanılır. Böyle bir ayar durumunda, EntityManager isimli nesne ilk oluşturulduğunda, JPA tamamen varsayılan ayarları kullanarak veri tabanında @Entity olarak notlandırılan sınıfların isimlerini kullanarak aynı isimde tablolar oluşturur ve tabloların sütunlarını da entity sınıflarının kalıcı olan alanlarının isimleriyle aynı yapar ve ve bu sütunlara uygun tipler atar.

persistence.xml ‘deki ; ayar satırı ile de,
hibernate.hbm2ddl.auto: Bu özelliklik Hibernate’e veri tabanındaki şemayla alakalı nasıl bir tavır takınacağını öğretmek içindir. Yukarıdaki dosyada bu ayar “create” olduğu için Hibernate ilk EntityManager nesnesi oluşturulduğunda veri tabanına gidip varsayılan değerlerle bir şema oluşturacaktır. Şemanızı ilk defa oluşturduktan sonra bu özelliğin değerini “update”e değiştirebilirsiniz.

EntityManager, veri tabanına açılan bir oturumdur (session), yapı itibariyla Java’nın web katmanındaki HttpSession nesnesine benzer ya da Hibernate’in orijinal API’sinin Session nesnesiyle tamamen aynı işi yapar. Dolayısıyla EntityManager’i olabildiğince kısa aralıklar içinde kullanmak, yani bu nesnenin ömrünü olabildiğince kısa tutmak gereklidir

Zaten EntityManager nesnesini kullanmanın iki yolu olabilir: Ya nesne değişkeni ya da metot değişkeni (local) olarak. Nesne değişkeni olarak kullandığınızda bu nesnenin pek çok metotta aynı anda kullanılması söz konusudur. Buradaki problem EntityManager’in thread-safe olmamasıdır. EntityManagerFactory thread-safedir, dolayısıyla bu nesneyi, nesne değişkeni olarak kullanıp, entitylerle alakalı YODS işlemlerini yapacağımız metotlarda, bu nesne üzerinden yerel bir EntityManager nesnesi almak daha doğru bir yaklaşım olacaktır. Bu durumda EntityTransaction nesnesini de kullanarak EntityManager nesnesi üzerindeki metotları çağırıp, sonra da close ile EntityManager nesnesini kapatarak programımızı yazarız.

Aşağıda bu sınıfın üzerinde çağırabileceğimiz nesne hayat döngüsünü düzenleyen metotlar ve kullanımları sıralanmıştır:

* void persist(Object entity) Yeni bir entityyi veri tabanında kalıcı kılar ve nesneyi yönetilir (managed) hale getirilir.
* Object find(Class entityClass, Object id) Geçilen entityClass’ın geçilen id’ye sahip nesnesini veri tabanından getirir.
* Object merge(Object entity) Koparılmış (detached) haldeki nesneye yapılan değişiklikleri, veri tabanındaki entityle birleştirir. Bu metot geriye birleştirilmiş entityi döndürür.
* void remove(Object entity) Entityyi veri tabanından siler.
* void refresh(Object entity) Entitynin veri tabanındaki halini getirip kalıcılık bağlamındakinin üzerine yazar.
* boolean contains(Object entity) Geçilen nesnenin kalıcılık ortamında entity olarak olup olmadığını boolean olarak geri döndürür.
* void clear() Kalıcılık ortamını temizler ve ortamda bulunan nesneleri koparılmış (detached) hale getirir.
* void flush() Kalıcılık ortamınındaki entitylere yapılan değişiklikleri veri tabanına gönderir (synchronize).

EntityManager tarafından persist ile kalıcı kılınan ya da find ile veri tabanından getirilen entitylerin durumu (state) yine EntityManager tarafından takip edilir. Böyle bir entityye “yönetilen” (managed) denir. Yönetilen nesnelere yapılan değişiklikler veri tabanına EntityManager tarafından yansıtıldığı için ayrıca güncelleme gibi bir metot çağırmaya gerek yoktur.

İşlem (Transaction) Yönetimi
Yukarıda EntityManager’in metotlarını incelemeden de anlaşılacağı gibi entityler işlem içerisinde kalıcı hale getirilirler (persist), güncellenirler (merge) ve silinirler (remove). Ayrıca yönetilen entitylere yapılan güncellemeler, EntityManager nesnesi tarafından takip edilir ve ne zaman bu nesne üzerinden ulaşılan EntityTransaction nesnesi begin ile başlatılıp commit ile bitirilirse yukarıdaki üç metotun sonucu ve kalıcılık bağlamındaki tüm güncellemeler veri tabanına yansıtılır.
EnetityManager nesnesi üzerindeki metotları çağırırken ya da başka bir sebeple ortaya çıkan durumlardan dolayı entityler üzerindeki değişiklikleri EntityTransaction üzerinde commit’i çağırarak veri tabanına göndermek yerine rollback’i çağırarak ile geri almak isteyebilirsiniz. rollback en son begin’den sonraki entitylere yapılan değişiklikleri geli alır, veri tabanına yansıtmaz.

Entity Hayat Döngüsü (Life Cycle)

Bir entity şu dört durumdan birinde olabilir: yeni (new), yönetilen (managed), silinmiş (removed) ve koparılmış (detached). (Bkz. lifeCycle())
Bir entity ilk yaratıldığında yeni (new) durumundadır. Bu durumda olan entitynin veri tabanıyla bir ilgisi yoktur, yani henüz veri tabanına yazılmamıştır. EntityManager’in persist metotuyla veri tabanında kalıcı hale gelir ve durumu yönetilen (managed) olur. (Bkz. createACustomer()) Yönetilen entity var olan kalıcılık ortamında bulunur ve durumu EntityManager tarafından takip edilir. Bu nesneye yapılan değişiklikler EntityTransaction nesnesine yapılan ilk commit çağrısında veri tabanına yansılıtır ve nesne yönetilen olarak kalmaya devam eder. (Bkz. createAndManageCustomer())

Veri tabanındaki bir entity EntityManager‘in find metotu ya da daha ileride göreceğimiz Query nesneleriyle veri tabanında getirildiğinde yine yönetilen durumuna girer. Bu durumdayken EntityManager’in remove metotuyla silinmiş hale gelir. Tekrardan veri tabanına yazılması için persist metotuna geçilmesi gereklidir. (Bkz. removeACustomer())

EntityManager üzerinde çağırılacak close ya da clear metotlarıyla da kalıcılık bağlamındaki bütün nesneler koparılmış hale gelirler ve durumlarındaki değişiklikler artık EntityManager tarafından takip edilmezler. Bu tür entitylerin durumlarını veri tabanında güncellemek ve tekrar yönetilen hale döndürmek için merge metotunu kullanırız. merge metotu, uzun işlem (long transaction) denen ve entitynin genelde içinde bulunduğu katmandan başka katmanlara gidip, orada değiştirildikten sonra değişikliklerin veri tabanına yansıtılması için geri gönderildiğinde kullanılır. Örneğin veri tabanında getirdiğiniz entity bir JSP sayfasında kullanıcıya görüntülenecek ve kullanıcının bazı alanları değiştirip kaydetmesine izin verilecekse, bunu yapmanın iki yolu olabilir: Ya EntityManager nesnesini JSP içinde alıp üzerindeki metotları kullanarak entitynizi değiştireceksiniz ki bu JSP içinde veri katmanıyla ilgili iş yapmak anlamına gelecektir ve popüler olan MVC (Model-View-Controller) tasarım desenine (design pattern) aykırı bir durum oluşturacaktır. Ya da entitynizi veri tabanında değiştirecek EntityManager nesnesini arka tarafta yani veri katmanında tutacaksınız ve entitynizi JSP sayfasına değiştirilmek üzere göndereceksiniz ve bunu yaptığınız yerde de EntityManager nesnesi üzerinde close metotunu çağıracaksınız. Bu durumda entityniz koparılmış olacaktır. Dolayısıyla JSP’de değiştirilen entity, veri katmanına tekrar gönderildiğinde, yeni bir EntityManager nesnesi oluşturup bir işlem içerisinde bu kez merge metotunu çağırarak güncelleyeceksiniz. Bu ikinci yöntem çok daha sağlıklı olup uzun işlem olarak adlandırılır. (Bkz. detachACustomer())”

Kaynaklar…
http://www.javaturk.org/?p=1119-
-http://kodcu.com/2011/10/java-persistence-giris/-
-http://www.turkishh.com/programlama/java-persistence-api-jpa-ile-programlama-1/-
-http://www.serefakyuz.com/2011/07/jpa-nedir.html-
-http://www.aliboyraz.com/jpa-nedir-1/-

EJB – Session Bean – Message Driven Bean – Entity Bean

Temmuz 31, 2013

Session Bean (Stateless-Stateful -Singleton):
cikone
EJB’ lere interfaceler aracılığı ile ulaşılır. Yani kullanıcı sadece interfacede tanımlı metotlara erişebilir. @Local ,@Remote adinda iki tane notasyonumuz var bunlar isimlerindende anlasilacagi gibi @Remote uzaktan çağrılan işlemler için , @Local notasyonu ise localden çağrılan işlemler için kullanılacak olan bir EJB interfacesi olduğunu tanımlıyor.

package ejbbeans;

import java.util.List;
import javax.ejb.Remote;
import pojo.UrunPojo;

/**
*
* @author http://www.turkishh.com
*/

@Remote

public interface TesterInterfaces {

// interface clasimizda iki tane methodumuz var

// Bu methodumuz bize urunlerimizin oldugu List donderiyor
public List<UrunPojo> getDeneme();

//Bu methodumuz ise bizden bir tane urun nesnesi aliyor
public void setDeneme(UrunPojo deneme1);
}

Burada interface sinifimizi tanimliyoruz ve iki tane methoduz olacak birisi list donderecek birisi ise urun nesnesi alip implements ettigimiz sinifimizda listemize ekliyecek.

UrunPojo sinifizimi yazalim .

package pojo;
/**
*
* @author http://www.turkishh.com
*/
public class UrunPojo {

String urunAdi;
String urunAciklama;
int urunFiyat;

public String getUrunAdi() {
return urunAdi;
}

public void setUrunAdi(String urunAdi) {
this.urunAdi = urunAdi;
}

public String getUrunAciklama() {
return urunAciklama;
}

public void setUrunAciklama(String urunAciklama) {
this.urunAciklama = urunAciklama;
}

public int getUrunFiyat() {
return urunFiyat;
}

public void setUrunFiyat(int urunFiyat) {
this.urunFiyat = urunFiyat;
}
}

Simdi ise is yapan methodlarimizin oldugu intefacemizi implement eden SessionBean sinifimizi olusturalim .

package ejbbeans;

import java.util.ArrayList;
import java.util.List;
import javax.ejb.Stateful;
import pojo.UrunPojo;

/**
*
* @author http://www.turkishh.com
*/
@Stateful
public class DenemeSessionBean implements TesterInterfaces {

//Urun tipnde bir tane listemiz var
List urunler;

public DenemeSessionBean() {
urunler = new ArrayList();
}

//Implements edilen bize urun listesi donderen method
@Override
public List getUrun() {
return urunler;
}

//Implements edilen bizden bir tane urun nesnesi alip
//urunler listesine dolduran methodumuz.
@Override
public void setUrun(UrunPojo urun) {
urunler.add(urun);
}
}

Simdi ise jsf sayfasi kullanicagimiz icin bir tane controller sinifimizi (Managed Bean) olusturalim
package controller;

import ejbbeans.TesterInterfaces;
import java.util.List;
import javax.ejb.EJB;
import javax.faces.bean.ManagedBean;
import javax.faces.bean.SessionScoped;
import pojo.UrunPojo;

/**
*
* @author http://www.turkishh.com
*/
@ManagedBean(name = “TesterBeans”)
@SessionScoped
public class TesterBean {

// En basta EJB’ lere interfaceler aracılığı ile ulaşılır demistik bunun icin
// @EJB notasyonu ile interface sinifimizdan referans
// aliyoruz ki methodlarimizi kullanabilelim
@EJB
TesterInterfaces bean;
UrunPojo urunPojo;

public TesterBean() {
urunPojo = new UrunPojo();
}

// Birtane urun nesnemizi alip listimize ekleyen
// ejb methodumuza gonderiyoruz
// ve sayfamizi refresh yapiyoruz
public String setTable() {
bean.setUrun(urunPojo);
return “index.xhtml”;
}

//Burada ise jsf sayfamizdaki tabloya listemizdeki urunleri yazdiracayiz
public List getTable() {
return bean.getUrun();
}

public UrunPojo getUrunPojo() {
return urunPojo;
}

public void setUrunPojo(UrunPojo urunPojo) {
this.urunPojo = urunPojo;
}
}

ve jsf sayfamizi olusturuyoruz .

Facelet Title

SessionBean Ornegi

@Stateful

Simdi arkadaslar bu ornekte notasyonumuz olarak @Stateful kullandik bu notasyonun nasil davrandigini tarayicimiz uzerinden bakalim..Ilk once chrome ile aciyorum ve bir tane urun ekliyorum ,ekledikten sonra mozillada aciyorum sayfayi ve su sekilde gorunuyor.

1

Simdi 2 tarayiciyada ayri ayri birer tane urun daha ekliyorum ve ciktisi soyle oluyor..

2

Goruldugu gibi her istemciye ayri ayri bean olusturuluyor . Stateful notasyonunu daha iyi anlayabilmeniz icin resimde gostermeye calisalim ..

ejb-konteyner1

@Singleton

Bir baska notasyonumuz @Singleton nasil davrandigina deyinecek olursak singleton notasyonu bir tane sabit bean tutar ve her istemciye ayni bean yollar .. Simdi kodumuza geri donerek @Stateful notasyonunu @Singleton olarak degistirelim ve tarayicilarimizda nasil farkliliklar var gorelim .Ayni islemi tekrarliyalim chrome ile bir tane kitap ismi ekleyelim ve mozilla ile eklemiyelim bakalim ne olacak..

4

Bu sefer isler degisti   :)  mozilladan urun eklemedigim halde bana ejb konteyner ayni bean’i gonderdi .. Yani durum assagidaki resimde anlattigim  gibi oldu ..

singletonbean

@Stateless
Simdi gelelim @Stateless notasyonumuza bu notasyonumuzda su sekilde calismaktadir , uygulamaya baglanan tum istemciler erisilebilen  bean cesitidir. Istemci nesneyi biraktiktan sonra baska bir istemci icin hazir hale gelir . Bu notasyonu kullandigimizda uygulama sunucunun ozelliklerine bagli olarak konteynerde hazirda bekleyen bir kactane bean olusturur  , istemci istek yolladiginda konteynarda hazirda bean varsa onu yollar yoksa eger yenisini olusturup yollar istemciye.

stateless

Kaynak………….
http://www.turkishh.com/programlama/ejb-session-bean-stateless-stateful-singleton-kullanimi/

EJB Nedir?

Temmuz 30, 2013

EJB (Enterprise Java Beans), java sınıflarının belli kurallara göre oluşturulması ve geniş amaçlı uygulamalarda kullanılması, yani belli bir amaca yönelik, belli bir işi görecek metotlardır.

EJB belirtimine göre üç temel bileşen çeşidi bulunmaktadır. Bunlar:
1- Entity Bean
2- Session Bean 
3- Message-Driven Bean

EJB’nin İskeleti

EJB’nin öncelikle bilinmesi gereken özelliği dağıtık nesne teknolojilerini kullanmasıdır ve şu anda J2EE platformunun standart olarak kullandığı dağıtık nesne protokolü IIOP’dur. Ancak herhangi bir J2EE platformu (uygulama sunucusu da denilebilir) satıcısı kendi tescilli protokolünü bunun yanında kullanabilir. Bilindiği gibi dağıtık nesneler istemci tarafındaki bir vekil (stub) vasıtasıyla sunucu tarafındaki bir nesneye ulaşır.

Dağıtık nesneler üç parçadan oluşur.

1- İstemcide bulunan “stub” nesnesi
2- İstemci ile sunucu arasındaki iletişimi sağlayan protokol
3- Sunucuda bulunan “skeleton” nesnesi ve gerçek nesne

Basit bir dağıtık nesne uygulaması şöyle gerçekleştirilebilir:
Sunucu tarafından sağlanan isimlendirme (naming) servisiyle istemci aradığı nesnenin “stub” nesnesini ister. İstemcide bulunan “stub” nesnesi ile gerçekte iletişim kurmak istediğimiz nesne aynı arayüzü paylaştıkları için “stub” nesnesi gerçek nesnede bulunan bütün metodlara sahiptir. İstemci “stub” üzerinden bir metodu çağırır. Bu metodun ismi ve argümanları iletişim protokolü aracılığıyla “skeleton” nesnesine aktarılır. Sunucuda bulunan “skeleton” nesnesi aldığı metot ismini ve argümanları kullanarak gerçek nesne üzerinde metot çağırımını gerçekleştirir. Metot tarafından döndürülen sonuç “skeleton” nesnesi tarafından iletişim protokolü kullanılarak “stub” nesnesine döndürülür ve sonuç istemci tarafından kullanılır.

Dağıtık nesne teknolojilerine bir örnek CORBA’dır. CORBA standardına uygun ORB’lar istemci ile sunucu arasında bir omurga kurarak bu iki platformu birbirine bağlar ve sunucu taraftaki nesneleri isimlendirme (naming) servisiyle kullanıma açar.
stub

*Resimde istemci tarafından bulunan nesneler gerçek nesneler değil, sunucu tarafındaki nesnelere ulaşmayı sağlayan vekil (proxy, stub vs.) nesnelerdir.

Yukarıda tipik bir istemci-sunucu etkileşimi görülmektedir. Şekil (a)’da istemci RPC’yi kullanarak sunucuda bulunan bir yordamı çağırmaktadır. Bu yaklaşım fonksiyonel dillerde geçerlidir. Şekil (b)’de ise çağırılan yordam her nesne için farklı sonuçlar üretir. Bunun nedeni nesnelerin verilerini kendi içlerinde barındırmalarıdır.

Tipik bir EJB bileşeni en azından şu üç sınıfı içerir:

1- Home Interface
2- Remote Interface
3- Bean Class

Java RMI (Java Remote Method Invocation) : Bir makina üzerinde çalışan bir java nesnesinin, başka bir makina üzerinde çalışan diğer bir java nesnesinin
metodunun çağırmasını sağlar.Bu da dağıtık uygulama inşa etmemizi sağlar.

JMS(Java Message Service) API :JMS API’ deki mesajlaşma yazılım bileşenleri arasında haberleşme sağlar.Böylece yazılım bileşenleri, durumları hakkında bilgi sağlarlar. Peer- to – Peer ilişkisi vardır. Mesaj alınır, iletilir.

Kaynaklar………………………..

ejb-1 http://www.teknoturk.org/docking/yazilar/tt000081-yazi.htm
ejb-2 http://www.teknoturk.org/docking/yazilar/tt000085-yazi.htm
ejb-3 http://www.teknoturk.org/docking/yazilar/tt000093-yazi.htm

http://www.ethemsulan.com/category/remote-method-invocation-rmi
http://www.farukbozan.com/2009/12/jmsjava-message-service-api-1/

MVC

Temmuz 17, 2013

MVC projemizde kullandığımız yapıları katmanlamamızı sağlar.
Veri tabanı için bir katman, sorgularımız için ayrı bir katman ve son kullanıcıya sunulacak olan ekran için ise ayrı bir katman oluşturmaktır.

Model
Verileri işlediğimiz kısım. Controller tarafından gönderilen verileri işler. Yada controller a yada drek olarak view a döner.

Controller
model yardımı ile oluşturulan sorgulara view den gelen bilgileri ekleyerek nasıl cevap verileceğinin belirlendiği kısımdır.

Wiev
Kullanıcının sistemle iletişim kurmasını sağlar. View de gösterilen veriler;
* Controllerin modelden elde ettiği veriler,
* Drek Controllerden
* Drek Modelden

FTP KURULUMU VE AYARLARI debian

Haziran 10, 2013

aptitude update
aptitude install vsftpd

nano /etc/vsftpd.conf konfigurasyon dosyası içeririnde şu satırları açalım;

anonymous_enable=NO : anonymous parolasız kullanıcısını pasif eder.
write_enable=YES
ftpd_banner=Welcome to fdurmus.com FTP service. Enjoy.
local_enable=YES

chroot_list_enable=YES
chroot_list_file=/etc/vsftpd.chroot_list

tail -f /var/log/vsftpd.log : komutu ile ftp log dosyasını görüntüleyebiliriz.

TRT Aöf videolarını indirmek

Mayıs 8, 2013

$ apt-get install python-lxml
$ python trtokul.py

https://bitbucket.org/myururdurmaz/toolkit/src/tip/trtokul.py

MongoDb Install on Debian

Mayıs 2, 2013

mongodb

> apt-key adv –keyserver keyserver.ubuntu.com –recv 7F0CEB10

> nano /etc/apt/sources.list.d/10gen.list

> echo ‘deb http://downloads-distro.mongodb.org/repo/ubuntu-upstart dist 10gen’ | tee /etc/apt/sources.list.d/10gen.list

> apt-get update

> apt-get install mongodb-10gen=2.4.1

Configurasyon
> nano /etc/mongodb.conf
> nano /etc/init.d/mongodb
> cd /var/lib/mongodb
> cd /var/log/mongodb

> /etc/init.d/mongodb start
> /etc/init.d/mongodb restart
> /etc/init.d/mongodb stop

> mongo

> db.test.save( { Fatih: 1 } )
> db.test.find()