Hep birilerini bekliyoruz, bir süper kahraman, bir kısmet, bir mucize… Hayatımızda değişmesini istediğimiz herşeyi kendimizden başka herşeye bağlıyoruz ve bekliyoruz…bekliyoruz….bekliyoruz….Kendi hayatımızın kahramanı olduğumuzun farkına varamıyoruz çoğu zaman. Peki ya ben size o beklediğiniz kahramanın kendi içinizde saklı olduğunu söylesem? Gülüp geçer misiniz, yoksa okumaya devam mı edersiniz? Çoğumuzun gerçek hayatta karşılaştığı zorlukları super kahramanın karşılaştığı ejderhalardan ya da sorunlardan daha az önemli olduğunu kim söylüyor? Ben değil:)
İşte bizi super kahraman olmaktan alıkoyan 7 davranış paterni:
1. Etrafımızdaki çağrıları görmezden geliyoruz.
“Heroes may not be braver than anyone else. They’re just braver 5 minutes longer. ― Ronald Reagan
Ünlü mitolojist Joseph Campbell (bkz: wikipedia) eski hikayeleri ve mitleri değerlendirerek bir çalışma yaptı ve bu çalışmada tüm kahramanların ilk aksiyonunun harekete geçmek olduğunu gördü. Yani çağrıya yanıt vermek. Eğer siz yapılan bir imdat çağrısına yanıt vermiyorsanız ve bu konuda bir adım atmazsanız, çok üzgünüm ama hayatımızda kahramanca bir şeyler de olamıyor. Buna konfor alanımızdan çıkmak da diyebiliriz:)
2. Hepimiz mutlu son bekliyoruz.
“And will I tell you that these three lived happily ever after? I will not, for no one ever does. But there was happiness. And they did live.” ― Stephen King
Eğer hayatımızda hedef, amaç ya da plan yoksa bu da çocukken okuduğumuz masallar gibi sonu hep iyi biten bir pembe toz bulutu olarak kalır. Masalların tarihçesini inceleyecek olursanız, aslında çocukları gerçek hayatla yüzleştirmek üzerinedir. Ben yeğenlerime okurken bazen hayretten ağzım açık kalıyor ve duraksıyorum, bu kadar acımasız mı hayat diye…İnanın masallar gerçeklerden daha acımasız çoğu zaman, sonunun iyi bitmesi onları daha az korkutucu yapmıyor maalesef. Siz yine de kışa gore hazırlanın, varsın bahar gelsin:)
3. Kurtarıcı olmaktan ziyade kurban olmayı seçiyoruz.
“We are all ordinary. We are all boring. We are all spectacular. We are all shy. We are all bold. We are all heroes. We are all helpless. It just depends on the day. ― Brad Meltzer
Siz istemedikçe kimse sizi kurtaramaz biliyor musunuz? Çok sert bir cümle oldu ama siz istemedikten sonra kimse sizi gerçekten de kurtarmayacak, öyle bir dünya yok maalesef. Istemeniz gerek, bedel ödemeniz gerek ki gerçekten değişmek ve bir şeyleri başarmak istediğimizi kendimize ispatlayalım.
4. Güçten etkileniyoruz fakat güçlü olduğumuza inanmıyoruz.
“You don’t need superpowers to be someones hero ― Ricky Maye
Hepimizin çocukken onlar gibi olmak istediğimiz kahramanları vardı. Benimkisi Red Kit’ti mesela:) En derinde belki hepimiz gizli bir gücümüz olsun isteriz, bizi diğer insanlardan daha özel ve daha güçlü yapan. Kendi hayatımızı ve başkalarının hayatını değiştirebilen, dünyayı değiştirebilen. Asıl gücün ne olduğunu bilmiyoruz çoğu zaman. O yüzden beyaz atlı prensi ya da uyuyan güzeli beklemekten ziyade kendi hikayemizin kahramanı, kendi filmimizin hem yönetmeni hem de baş oyuncusu olmamız gerekiyor. Neden mi? Çünkü bunu yapabilirsiniz ve hak ediyorsunuz:)Yazının Tamamı İçin
SSO Ayarları, JDeveloper IDE screenshotları kullanılarak açıklanmıştır.
1) ApplicationName: acme
2) Context Root ayarı: protected_acme , weblogic.xml de session tab’inde “/” kullanarak context root ismi yazılır.
3) Ear Adı: acme (optional)
4) Application Deployment ayarlarında iki maddenin tiki kaldırılacak
CANLIDA SSO AYARI İÇİN aşağıda seçili olan radio butonu işaretledikten sonra next next ile finish yapılır.
TEST ORTAMI İÇİN GÖNDERİLECEK DEPLOYMENT AYARINDA HHTP_BASIC VEYA FORMS BASED SEÇİLİ KALIR.
CLUSTERED ORTAM AYARLARI
SSL (Secure Sockets Layer): 2 uygulamanın ağ üzerinde birbiriyle ilk iletişim kurarken ve veri alışverişi yaparken birbirlerinin (sadece server yani tek taraflı da olabilir) kimliklerini çeşitli sertifika tipleriyle tanıttıkları ve bir şifreleme algoritması üzerinden haberleştikleri güvenlik katmanıdır.
HTTPServerlara (örneğin Oracle tarafında OHS)uygulanabildiği gibi WL Admin ve managed serverlara da uygulanabilir. http serverlarda genel olarak (eğer browserlara https://hostname şeklinde yazılıp port belirtilmezse 443 olarak varsayılır, http için bu 80 dir) 443 iken WLS da bu port default olarak 7002 dir. Console üzerinden değiştirilebilir
WLS üzerinde SSL konfigürasyonunun etkin (enabled) olduğunu anlayabilmenin ilk yöntemi https://myserver:7002 şeklinde kontrol etmektir. Ancak enabled olmasına rağmen port değişikliği yapılmış olabileceğinden console üzerinden Servers bölümünden ilgili sunucunun General-> Configuration tabına erişilip kontrol edilebilir.
Bu şekilde enabled olduğunu gördükten sonra https üzerinden ilk erişimde tarayıcı sertifikasyon bilgisini client tarafına getirecektir.
Sertifika ayarlamalarında test ortamı için selfsigned sertifikalar yada piyasadaki otoritelerce kabul edilen merkezlerin sunduğu geçici deneme sertifikaları kullanılabilir. (ör: https://www.symantec.com/page.jsp?id=how-ssl-works&tab=secTab5) Ancak production ortamında bu önerilmez ve production ortamı için oluşturulan sertifikanin CN(common name) alanının sunucunun hostname i ile eşleştiğinden emin olunmalıdır. Doğru bir örnek için aşağıdaki resim dikkate alinabilir.
1: Sertifika oluşturma:
a: Sunucu üzerindeki komut satırından setDomainEnv script i çalıştırılır yada keytool u kullanabileceğimiz ortama geçiş yapılır.
b: Bu private – public key pair i oluşturmak birkaç farklı tool ile olabilmekte ancak biz jdk içerisindeki keytool u kullanıyoruz.
keytool -genkey -alias client -keyalg RSA -keysize 2048 -keystore identity.jks -storepass password -keypass password
c:Certificate Signing Request (CSR) dosyasını aşağıdaki gibi oluşturarak CA ‘ya (sertifika almak istedğimiz otorite) gönderip cevap istiyoruz.
keytool -certreq -keyalg RSA -keysize 2048 -alias client -file certreq.csr -keystore identity.jks -storepass password
CA bize RootCA ile birlikte bazen IntermediateCA yı gönderecektir.
d: Elde ettiğimiz sertifikaları keystore dosyasının içine koyacağız.(import process) Bu işlem iki farklı şekilde yapılabilir. Birincisi RootCA, IntermediateCA ve cevap olarak gelen sertifikyı hiyerarşik olarak import etmek. İkincisi de .pem dosyası içinde bir sertifika zinciri oluşturmak.
Biz ikinci yöntemi takip edelim, “CertChain.pem” adıyla bir dosyada toplayalım. Aşağıdaki kodda client key alias tır değiştirilebilir.
keytool -import -file CertChain.pem -alias client -keystore identity.jks -storepass password
e: Keystore oluşturma: RootCA sertifikası olmayan bir keystore kullanılarak oluşturulabilir yada yada mevcut birisinin içine import edilebilir.
keytool -import -file rootCA.cer -alias RootCA -keystore trust.jks -storepass password
Kontrol etmek için aşağıdaki komut kullanılır.
Keytool –list –v –keystore <keystore-name> -storepass <keystore-password>
2: Keystore u WLS ye uygulamak:
a: Admin console a giriş yaparak SSL uygulanacak sunucu seçilip Configuration->Keystores seçilir.
Keystores bölümündeki Change butonuna tıklanarak Custom Identity and Custom Trust seçilip Save edilir.
b: Sunucu Identity konfigurasyonu
Sunucu kimliğini belirleyebilmek için SSL sekmesine geçilip oluşturulan private key in alias ı (bu anlatımda client idi) ve passphrase i girilir.
NOT: Bu anlatımda yapıldığı gibi sunucuda yalnızca SSL aktif edilirse varsayılan olarak OneWaySSL aktif olacaktır.(Genelde kullanılan durum budur, yani sunucunun kendini tanıtması) Eğer 2Way SSL olarak değiştirilmesi isteniyorsa Advanced seçeneğinden değiştirilebilir.
Server loglarında aşağıdaki gibi logların yazılması beklenmektedir.
<Notice> <Security> <BEA-090171> <Loading the identity certificate and private key stored under the alias client from the JKS keystore file C:\Wonders\WebLogic\Security\SSL-Certs\Verisign\identityVerisign.jks.>
<Notice> <Security> <BEA-090169> <Loading trustedcertificates from the JKS keystore file C:\Wonders\WebLogic\Security\SSL-Certs\Verisign\trustVerisign.jks.>
Bu dokümanın hazırlanmasında base aldığım dokümanın sahibi ve bu konuları anlamamda bana çok emeği geçen kişi Arman Altuğ ÖZHAN‘dır. Canı gönülden teşekkürlerimi sunuyorum.
Bu doküman Java EE teknolojileri kullanılarak ADF ile proje geliştirebilmek üzerine daha çok persistence ve control katmanı konusunda bilgiler içermektedir. Çok katmanlı mimari göz önüne alınarak tasarlanan sistem göz önüne alınmıştır. ADF teknolojisinin business (EO xml leri ve VO lar) modeli kullanılmadan ADF projelerinin geliştirilebilmesi açıklanmıştır.
Model katmanı
Bu bölüm genellikle EJB3.0 ve buna bağlı olarak geliştirilmiş tekrar kullanılabilir objeler ile sağlanan alt yapı kullanılarak proje geliştirme aşamalarının üzerinden geçmektedir.
Üzerinden geçilecek başlıklar:
1. Entity Beanler
2. Filtreler
3. DAO Objeleri
4. Exceptionlar
5. Session Beanler
Entity Beanler, veri kaynağındaki objeleri tanımlamak için kullanılırlar. Projedeki objeleri temsil ederler.
Filtreler, entity beanlere bağlı olarak üzerlerinde sorgu oluşturmak için kullandığımız objelerdir. sorgulanacak her bir entity objesine bir filtre hazırlanması gerekir.
DAO Objeleri, veri erişim kodlarının business kodları arasına yazılıp da kodu daha kompleks ve az anlaşılır hale getirmemesi için yaratılan tekrar kullanılabilir kod katmanlarıdır.
Exceptionlar, projenin beklenen çalışma düzeninden saptığında ortaya çıkan istinai durumlardır. Projede client ve server olmak üzere iki ana başlıkta toplanmıştır.
Session Beanler, projede yapılan işleri temsil ederler ve business kodlarının bulunduğu kod katmanlarıdır. Proje boyunca yapılacak ana işler bu katmanda gerçekleşir. Burada geliştirilen kodların anlaşılır olmasına ayrıca önem verilmelidir.
Entity Beans
Entity Bean objeleri önceki EJB versiyonlarında olduğu gibi verinin saklanacağı kaynak ile ilişkilendirilmesi için kullanılmaktadır. EJB3.0 versiyonlarında annotationların kullanılmaya başlanmasıyla ve veri kaynağının çeşitli veri kaynakları yerine veritabanı ile ilişkilendirilmesi ile daha anlaşılır ve daha kolay uygulanabilir bir hale gelmiştir.
Entity Beanler bildiğimiz basit java bean objelerinin bir türevidir. Annotationlar kullanılarak veri kaynağı ile java beanler ilişkilendirilir ve Object to Relational Mapping yapısı sağlanmış olur. Hibernate ORM (Object Relaional Mapping) tool kullanılarak bu entity’ler ve ilgili varlıklar veritabanı üzerinde otomatik olarak oluşturulması sağlanabilmektedir.
Projede geliştirme yaparken entity beanlerimizi, com.acme.proje_adı.modül_adı.entity paketi altında konumlandırmaktayız.
SuperEntity
BaseEntity ve BaseEntityView class ları tarafından extend edilen soyut bir sınıftır. Entity lerde kullanılan en temel ve genel methodları barındırır. @MappedSuperClass annotation ı ile işaretlenmiştir.
BaseEntityView
Geliştireceğimiz uygulamada entity objemiz, uygulamamız tarafından yönetilmeyecek oluşturulmayacak bir view yada tablo ise yani yalnızca bilgi okuyacaksak bu tür entity beanler BaşeEntityView objesinden türetilecektir. Böylelikle türetilen objenin serializable olmasının sağlanmasının yanı sıra objenin içerisindeki alt yapı için gerekli olan id, version ve entityName değişkenleri de otomatik olarak kullanması sağlanacaktır.
BaseEntity
Geliştireceğimiz ve uygulama tarafından okunup yazılacak(CRUD işlemlerinin tümü) entity beanler BaseEntity objesinden türetilecektir. Böylelikle türetilen objenin serializable olmasının sağlanmasının yanı sıra objenin içerisindeki alt yapı için gerekli olan id, version ve entityName değişkenleri de otomatik olarak kullanması sağlanacaktır. @MappedSuperClass annotation ı ile işaretlenmiştir.
İlk Entity Bean
Entity Bean’i geliştirirken öncelikle java bean’imizi Entity Bean olarak belirten @Entity annotationini kullanmalıyız. Entity annotationin bir özelliği olarak name alanını kullanmamız özellikle önemlidir. çünkü daha sonradan kullanılacak entityleri çağırırken bu isim kullanılacaktır. Örneğin EJB/QL(yada HQL) içerisinde kullanılacak entity adını bu alan belirlemektedir. Boş bırakıldığı takdirde class ismi bu ad yerine varsayılan olarak kullanılacaktır. Projede kullanışlılığı açısından Class ismini name özelliği olarak kullanacağız.
Entity annotationından sonra veri kaynağındaki tablo adı ile ilişki kurmakta işimize yarayacak olan @Table annotationini kullanmamız gerekiyor. Bu alanın özelliği olarak tablo adını tanımlamamız gerekmektedir. Burada name için kullanılacak format büyük harfler ile (varsa-modül_kısa_adı+)entity_adı+çoğul_eki olacaktır. Örneğin entity class name:Company tablename:COMPANİES
Son olarak kullandığımız veritabanının veya alt yapının özelliklerine göre bize primary key alanı olarak kullanabileceğimiz otomatik olarak artan bir değer sunan generatorları tanımlamamız gerekmekte. Projede kullanılan veritabanı Oracle olduğundan dolayı otomatik id alan değerini sequence alt yapısını kullanarak sağlayacağız. Bunun için @SequenceGeneratör annotationini kullanacağız. Özellik olarak name ve sequenceName alanlarını tanımlamamız gerekiyor. Buradaki format hem name için hem sequenceName için büyük harf ile Entity_adı+çizgi+SEQ cümleciği olacaktır.
Eğer BaseEntityView kullanıyorsak ve kullanıma verilen datasource taki veri yapısında(table-view) belirli bir PK alanı yapısal olarak yok, birkaç alan birleştirilerek çıkartılabiliyorsa aşağıdaki gibi entity_classname_PK ismiyle bir class yaratılarak ilgili entity’de kullanılabilmektedir.
Bu tanımları yaptıktan sonra JavaBeanımızın parametresiz constructorini tanımlayacağız. Constructor içerisine entityName alanı yukarıda kullanılan @Entity ile aynı değeri taşıyacak şekilde verilmelidir. Ayrıca bir collection objesi varsa bu initialize edilmelidir.
Daha sonra Entity Beanımızın hangi özellikleri taşıyacağı belirlenmelidir. Örnek olarak çalışan birisi için sicil numarası, adı, soyadı gibi alanlar private olarak tanımlandıktan sonra bir IDE aracılığı ile getter ve setter metodları yaratılmalıdır. Getterların önce yaratılması birçok uygulama sunucusu için önemlidir. Çünkü annotationlar getter methodların üzerine yazılır. (field tanımlanan alanda da yazılabilmektedir)
Getter ve setter metodlarının tanımlanmasından sonra bu alanların özelliklerini belirtmek için tekrar annotationlar yardımı ile tanımlar yapmamız gerekmektedir. Veritabanında karşılığı bulunan her alan için @Column annotationini ve bunun name özelliğini doldurmamız gerekmektedir. Kullanılacak format büyük harfler ile alan_adı olmalıdır. Karşılığı olmayacak alan için ise @Transient annotation i kullanılmalıdır.
Özel Alanlar
Bazı alanlar kullanımları açısından diğerlerinden farklıdır. id alanları ve diğer entityler ile ilişki kurulan alanlar bu kapsama girerler.
Id Alani
Bir alanın primary key alanı olduğu @id annotationi ile belirtilir. @id annotationi başka bir özellik taşımaz. Bunun dışında bu alanın değerinin ne şekilde sağlandığını belirtmek için @GeneratedValue annotationi kullanılır. Bu annotatinin iki özelliği vardır. Birisi değerin ne şekilde yaratılacağını belirten strategy diğeri ise bu değeri yaratacak nesnenin belirten generatör’dir. id alanı diğer alanlar gibi @Column annotationini kullanmalıdır.
Relation Alanlari
Relation alanları bir fieldin diğer bir entity ile ilişkisini tanımlamakta kullanılır. En yaygın olanları aşağıda listelenmiştir.
Bkz => http://en.wikipedia.org/wiki/Cardinality_(data_modeling)
@OneToOne uni-bidirectional
@OneToMany uni-bidirectional
@ManyToOne uni (one-to-many bidirectional many-to-one bidirectional ile aynıdır)
@ManyToMany uni-bidirectional
Bu relationlar tanımlanırken öncelikle targetEntity ile ilişkinin kurulduğu diğer Entity classi belirtilir. Bunun dışında cascade ile entity üzerinde işlem yapıldığında diğer entitynin durumunun ne şekilde etkileneceği belirtilir. Ve son olarak fetch ile bu alanın değerinin diğer entity ile otomatik olarak doldurulup doldurulmayacağına karar verilir.
Ayrıca relation annotationlarının yanısıra diğer entity ile ilişkinin veritabanında hangi alanda tutulacağını tanımlamak için @JoinColumn kullanılır.
toString Metodu
tostring metodu ile objenin görünen değeri set edilir. Mesela çalışanların yapılacağı bir entity için return getName()+” “+getLastName() şeklinde bir tanımlama yapılabilir.
Filters
Filtreler bir entity objesine bağlı olarak çalışan ve dinamik olarak sorgu yapmaya yarayan objelerdir. Bu yüzden veri kaynağından sorgulama yapılmak istenen her bir entity objesi için buna bağlı olarak çalışabilecek bir filter objesi yaratılmalıdır.
Filtreler, *.model.filter paketi altında tutulurlar. isimlendirme formatı olarak kendisi ile ilişkilendirilen entity objesinin isminin sonuna Filter uzantısı getirilerek oluşturulur.
Filtre class ları BaseFilter objesinden türetilirler. BaseFilter constructor’ı object parametresi olarak ilişkilendirilen entity bean objesini alır. BaseFilterin sorgulama yaparken kullanılacak createQuery metodu ile sorgu oluşturulurken kullanılan isNüllOrEmpty metodu vardır. createQuery metodunda entitynin doldurulmuş alanları kontrol edilir ve bunlara göre sorgu oluşturulur.
DAO Layer
DAO katmanı session beanlerin veri kaynağı ile işlemlerini gerçekleştirdikleri katmandır. session bean içerisinde yazılan business kodları ile veritabanı erişim kodlarını birbirinden ayırmak için, daha doğrusu veri kaynağına erişim kodlarını isole edebilmek için bu kodların farklı katmanlarda tutulmaları gereklidir. Bu yüzden veritabanı ile yapılan işlemler bu katman üzerinde gerçekleştirilir.
Aşağıda veritabanı üzerinde çalıştırılan modül bağımsız metodların çalıştığı dao örneği görülebilir.
findByPrimaryKey id alanı atanmış herhangi bir entity objesinin veritabanından çağrılmasını sağlamaya yönelik bütün session bean objeleri tarafından kullanılabilecek bir örnektir.
Bir diğer örnek olarak getEntityList verilen entity türünden bütün objeleri veritabanından çağırarak bir collection objesinde toplar.
fındByFilter örneğinde ise verilen bir filter objesinden üretilen sorgu ve bu sorgu sonucu dönen entity objeleri business katmanına geri döndürülür.
Her modülün ortak olarak kullanabileceği metodlar için bir MainDAO objesinin yanısıra her modülün kendi işlemlerini gerçekleştirebileceği bir dao objesi bulunabilir. Örneğin EDYS projesinde ApplicationDao class ı listelerin dolmasını sağlayan, SP(StoredProcedure) çağıran metodları barındıran bir dao objesi olarak tüm Test Talep ve EDYS projelerinin istediği sorgulamaları yapmaktadır.
DAO objeleri *.model.dao paketi altinda konumlanmistir.
Exceptions
Exceptionlar program içerisinde normal çalışma akışı dışında meydana gelen durumlardır. Bu durumların elden geldiğince maksimum düzeyde kontrol edilmesi iyi bir uygulamanın özelliklerinden birisidir.
Session Beans
Entity beanler objeleri temsil ederken session beanler işlemleri temsil ederler. Bu işlemler genellikle entity beanler üzerinde yapılır. Örneğin kayıt, banka transferi, stoktan mal çıkarma gibi işlemler hep sessionbean kullanılarak yapılırlar. Her session beanın en az bir interface objesi bulunur. Bu obje sessionbean objesi ile iletişim kurmakta kullanılır. Bahsedilen interfaceler local ve remote olarak ikiye ayrılır. Local objeler aynı jvm üzerinden çağırılabilirken remote objeler dağıtılmış uygulamalarda kullanılırlar. Bu yüzden istemciler tarafından kullanılacak her metod bu interfacelerde tanımlanmalıdırlar.
Session beanler com.acme.model.sessionbean paketi altında bulunurlar.
Session bean tanımlanırken öncelikle session beanın tipi belirtilir. Projede kullanacağımız session bean türü stateless session beanlerdir. @Stateless annotationi beanımızın stateless olduğunu belirtmede kullanılır. Ayrıca veritabanı ile yapılacak transactionları containerin yönetmesini sağlamak için @TransactionManagement annotationi kullanılır ve tipi de CONTAiNER olarak belirtilir. Ayrıca performans ve log tutmak için alt yapı tarafından kullanılan interceptorlar da @Interceptors annotationi kullanılarak sessionbeane tanımlanır.
Bu tanımları yaptıktan sonra beane default erişim seviyesini de beanı geliştirmeye başlamadan önce verebiliriz. Bu seviye bütün metodlar için geçerli olacaktır.
Stateless session beanler ile ilgili önemli bir konuda adından da anlaşılabileceği gibi bu beanler client ile ilişkili durum bilgilerini tutmazlar. Bu yüzden işlem yaparken herhangi bir durumlarını scope’u metod dışında olan bir değişkende tutup kontrol etmek veri tutarsızlığına kadar giden sorunlara yol açabilecektir.
Session beanımızı geliştirirken ilk yapmamız gerekenlerden birisi ORM ile ilişkiyi yönetecek olan EntityManageri tanımlamaktır. Bu objeyi tanımlarken hangi persistence context(entity objelerini tutan alan) ile ilişkisi olacağını @PersistenceContext annotationi ile yapabiliriz. Bu annotationa özellik olarak ünitName tanımlanır ve buraya verilecek değer persistence.xml dosyası içerisinde bulunur.
Constructorda bean içerisinde ortak olarak kullanılacak daolar initialize edilir.
Interface te tanımlı metodlarda metoda girmeden önce @RolesAllowed ile yetki seviyesi rol bazında belirlenmelidir. Default olarak classta tanımlanan role geçerli olacaktır. Birden fazla role yetki verilebilir.
EntityManager ile transactional işlemler yapmadan önce veri tutarlılığı açısından EntityManager’in flush modu COMMiT olarak atanmalıdır.
Bilinmesi gereken bir diğer obje de serverResponse’ tur. serverResponse içerisinde hem data hem de client tarafından işlenebilecek kontrol edilmiş exceptionları barındıran bir sınıftır. Özellikle işlem yapıldığı takdirde uyarı çıkabilecek durumlarda kullanılmalıdır.
Bunlar;
- synchronizeEntities(GridData gridData) throws Exception
· refreshEntities(serverResponse response, Collection entityList)
- persistEntities(serverResponse response, Collection entityList)
- removeEntities(serverResponse response, Collection entityList)
synchronizeEntities client tarafında grid üzerinde tutulan datanın son halinin veritabanına yazılması için kullanılan metoddur. Grid içerisindeki data ile tek tek işlem yapar ve kontrol dahilinde olan bir exception oluştuğunda bunu response içerisine ekler ve diğer datalar üzerinde işlem yapmaya devam eder.
synchronizeEntities metodu kullanılırken dikkat edilmesi gereken bu metoda gönderilen griddeki dataların birbirleri ile bağlantısının ne şekilde olacağıdır. Örnek olarak grid self reference olan entity objelerini tutuyorsa veri tutarlılığı açısından kullanılan metod değiştirilmelidir.
refreshEntities metodu veritabanından son halleri çekilecek olan entitiylerin response objesi olarak geri döndürülmesi için kullanılan metoddur.
persistEntities ve removeEntities te refreshEntities metodu gibi entityList içerisinde bulunan entitylerin veritabanına kaydedilmesi ve silinmesi işlemlerini yaparlar ve yanıtları response objesinde tutarlar.
Development
EJB bean ler JNDİ üzerinden structure projesi altındaki ServiceLocator objesi ile çağrılır. JNDI a kaydolabilmesi için Model projesi içerisinde ilgili xml file da gerekli tanımlamalar yapılmalıdır.
Deployment kütüphanelerinin önceliği ise weblogic-application.xml dosyasında belirtilir.
Sıradan bir tanımlama ekranı geliştirirken izlenebilecek sıra şu şekilde olabilir.
• Server tarafında geliştirme yaparken öncelikle entitylerin tanımlanması mantıklı olur. Entityler hem server hem client tarafında kullanılacak temel objelerdir.
• Entity tanımlandıktan sonra eğer bu entity objesi üzerinde sorgulama yapılacaksa filtre tanımlanmalıdır.
• Bu işlemden sonra gerekli dao metodlarının tanımlanması gerekir. Bu adım her zaman gerekmeyebilir veya sessionbeanler geliştirilirken dao metodları aynı zamanda geliştirilebilir.
• Bu adımda exceptionların tanımlanması gerekir. Business exceptionlar yalnızca ve yalnızca sessionbeanler üzerinden atılmalıdır.
• Exceptionların ardından business işlemlerinin gerçekleştiği session beanlerin ve interfacelerin tanımlanması gelir. sessionbeanler yukarıda bahsedilen adımlarda geliştirilen tüm objeleri kullanabilirler bu yüzden en son veya 3. ve 4. adımla birlikte tanımlanmaları gerekir. session beanden önce interface objesinin tanımı yapılmalıdır. interface objesinin metodları önce session bean objesinde tanımlanır.
Business işlemleri gerçekleştirilirken ise
• Entity beanler genellikle önceden yaratılmış olacaktır.
• Filtre objeleri muhtemelen gerekmeyecektir veya önceden tanımlı olacaktır.
• Muhtemelen önceden hazırlanmış dao metodları kullanılacaktır(fındByPrimaryKey, fındByFilter gibi).
• Business işlemleri yapılırken oluşacak istisnai durumlar göz önüne alınıp bu durumlara uygun exceptionların oluşturulması gerekir.
• Business işlemleri gerçekleştirecek sessionbeanler ve interfaceleri hazırlanır. Gerekiyor ise weblogic-ejb-jar.xml dosyasına tanımlanırlar.
Bu işlemlerden sonra model projesi deploy edilmeye hazır hale gelmiş olacaktır.
Resources
Java uygulamalarında statik olarak hazırlanan textlerin yerel dillere çevrilmesi için kullanılan en yaygın metod resource bundleları kullanmaktır. Resource Bundle’lar bir anahtar sözcüğün karşılığı olarak bir obje döndüren dizilerdir.
Çoğu java uygulaması gibi bu uygulamada da bu iş için Resource Bundle’lar kullanılmaktadır. Altyapı ve her modül için ayrı birer resource bundle tanımlanmıştır. ResourceBundle’lar ListResourceBundle objesinden türemişlerdir.
Component etiketleri, exception tanımları, genel mesajlar(lütfen bekleyiniz, işlem başarılı veya konfirmasyon işlemleri gibi), veya modül bağımsız genel ekranlar(login, logout, şifre değişimi) gibi işlemler alt yapı için kullanılan resource bundle içinde tanımlanabilirler. Resource Bundle’lar; Resources projesi altindaki com.arsivist.resource.bundle paketi altinda bulundurulurlar.
İsimlendirme olarak da ResourceBundle+”_”+varsa-modul_adi+”_”+local_dil_kodu verilebilir.
ViewController projesi Geliştirme
Oracle ADF ile Web uygulamaları , masaüstü uygulamaları, mobil uygulamalar; JDeveloper geliştirme ortamının sunduğu deklaratif yöntemlerle ve görsel arayüz desteğiyle kolaylıkla oluşturulabiliyor.
Model: İş mantığı (Business Logic) bölümüdür. Tek katmandan oluşabileceği gibi, birden fazla katmanı da içinde barındırabilir. Tek katmandan oluştuğunda genelde veritabanına kayıt ekleme, kayıt çekme, kayıt silme vb. veritabanı işlemleri için kullanılır. Controller’den gelen değerleri işler ve geriye döndürür. Model katmanında herhangi bir –loglama haricinde- output işlemi yapılmaz.
View: Uygulamanın kullanıcıya gösterilen arayüzünün bulunduğu katmandır. Html, Css, Javascript, JSF vb. bu katmanda bulunur.
Controller: Uygulamanın karar mekanizmasıdır. Model ile View arasında köprü görevi görür.
İş Servisleri Katmanı: Bu katman farklı kaynaklardaki veriye erişimin sağlandığı ve iş mantığının tanımlandığı katmandır.
Bu katmanların tümünde, Oracle ADF istenilen teknolojinin kullanılmasına olanak sağlar. EJB, örneğin iş servisleri katmanında Web servisleri, JavaBeans, JPA, Hibernate kullanılabilirken, View katmanında, JSF, JSP, ADF Faces kullanılabilir. Sektördeki uygulama sunucularından biri olan WebLogic JDeveloper ile entegre olarak paketlenmiş halde gelmektedir. JDeveloper ve ADF ile uygulamanızı geliştirirken, aynı anda WebLogic üzerinde test/debug yapılabilmektedir.
MVC tasarım deseni temel alan Oracle ADF framework unde UI tarafında JavaServerFaces standardının üstüne konumlandırılan ADFFaces kullanılarak UI bileşenleri tasarlanır, UI bileşenleriyle model tarafını konuşturan Contoller’lar (MBean classları) aynı projede geliştirilebilmektedir(ViewController projesi). MBean ler gibi java objeleri src nin altında *.vc.projectname hiyerarşisindeki gibi bir paket yapısıyla yer alırken html bileşenleri ve taşk-flow konfigürasyon dosyaları public_html klasörünün altında yer bulur.
Basit bir fonksiyonel ekran düşünelim. Önyüzde son kullanıcıya bazı UI bileşenleri gösterilecek, girilen yada otomatik yüklenen bazı bilgilere göre kullanıcıya bazı bilgiler gösterilecek. Bu durumda öncelikle aklımıza hangi bilgilerin ne şekilde getirilerek gösterileceği aklımıza gelmektedir. Veri kaynağını sağlayacak business service bir webservisi, web’e açık bir api, bir ADFBC datacontrol bileşeni, EJB nesnesi olabilir. Bu service nesneleri, veritabanından, BPM’den yada yalnızca memorydeki bir pojo objesinden veri getiriyor olabilir. Veri getirilen katman ve kontrolörleri model katmanı olarak düşünebiliriz. Bu kısmı tamamladığımızı düşünürsek ön tarafta kullanıcının neleri nasıl göreceğini ve nasıl kontrol edeceğini düşünmeye geçeriz. Bu aşamadaki çözüm Controller katmanıdır; ADF frameworkundeki karşılığı ise taskflowlar olabilmektedir.
Task-flow da kullanılacak (ManagedBean)MBean ler task-flow larda tanımlanarak on yüzden tetiklenmesi yada önyüzü oluşturulması sağlanır. MBean ler ise Model projesi ve diğer util projelerine ulaşarak task-flow un ihtiyaç duyduğu verileri kaydedip sağlayarak hizmet verir, WebService çağırarak süreç tetikler, UCM den doküman çeker yada revizyonlar… Contoller objeleri; View katmanından gelen istekleri(request) model’e gönderir ve Model katmanından aldığı verileri view’e aktarır.
Oluşturulan task-flow yapısı xml dosyaları ile file systemde tutulmaktadır. Task-flow bileşenlerine özgü bileşen palette inden view bileşenini eklersek. Bu bileşenin karşılığı olarak bir web sayfası(jsp, jspx, jsf, jsff) yaratacağız demektir. Sayfaya, ihtiyacımız olan UI bileşenlerini ekleyerek task-flowda tanımladığımız MBean class ındaki ilgili metotlarla bağlantısını kurarız(binding). Task-flow üzerinde tanımlanan sayfa ve metot çağrımları sırasında ise veri geçişlerini çağıracak parametre leri tanımlarız.
Uygulamayı portal uygulaması olarak planladıysak oluşturulan task -flow lar bir jspx dosyasına atılarak geliştirme sırasında integrated weblogic sunucusu üzerinde çalışması gözlemlenir. Her bir ön yüz bileşeni esasında jsff fragment i olarak tasarlanabilmektedir. Her bir fragment ise istenilen –yapısına uygun olmak koşulu ile- bir task-flow içerisinde bir view bileşenine denk gelecek biçimde kullanılabilmektedir.
Engellenmemiş Traceroute Komutu
Windows sitemlerde bir sayfaya ya da sunucuya veri sağlayan tüm sunucuların adreslerini çıkarmaya yarayan komut tracert komutudur.
Windows işletim sitemi üzerinde yapılmış basit bir traceroute örneği örneği aşağıda ekran görüntüleri ile açıklanmıştır. Herhangi bir firewall engellemesi olmadığı için komut sağlıklı çalışmaktadır.
1) “Start > Run” veya “Windows Tuşu+R 2) Açılan ekrana “cmd” yazıp “Enter” basın bu bizi DOS komut satırına götürecektir. 3) Komut satırına “tracert www.yandex.com.tr” yazıp enter’ a basın 4) Karşınızdaki ekranda verinin gidişini izleyebilirsiniz
Örnekte hostname olarak www.yandex.com.tr adresi verilmiştir. Bu adres yerine ip bilgisi de
yazılarak da paketler kontrol edilebilir. Aşağıdaki ekran görüntüsünde paketlerin ne kadar süre içinde
karşılık veridiğini ve ip kaynak yönlendirme seçeneğinin hangisi olduğunu görebilirsiniz.
Traceroute IP başlığındaki TTL (Time To Live- Yaşam Süresi) alanını ve ICMP (Internet Control Message Protocol – İnternet Kontrol Mesaj İletim Kuralı) kullanır. Ekran görüntüsündeki ms cinsindeki üç değer, o TTL değeri ile gönderilen üç veri paketinin, icmp mesajının gelişine kadar gecen sürelerdir. Sistemin sağlıklı çalışması için hedefte bir UDP modülü olması yeterlidir.
Traceroute yapılmasını Windows firewall kullanarak engelleme
Windows üzerinde aşağıdaki gibi basit bir giden firewall kuralı tanımlayarak UDP’ye olan erişimi engelleyebiliriz.
İzlenmesi gereken yol:
Başlat > Denetim Masası > Windows Güvenlik Duvarı > Gelişmiş Ayarlar > Giden Kuralları > Yeni Kural
Aşağıda windowsun kendi sihirbazlarını kullanarak oluşturduğumuz “cemip” adlı giden kuralı
sayesinde yandex.com.tr adresine yapılan tracert komutunun sonucunu görebilirsiniz.
Konsol uygulamamızda Windows firewall iletişimi kestiği için “Hedef sistem ismi çözümlenemedi” sonucu
alınmaktadır.
Dünyada kullanılan iş zekası çözümlerinden ticari olarak en kabul görenlerinden birine Oracle BI ürününü örnek gösterilebilir. Oracle firması RDBMS veritabanlarının en güvenilir kendini kanıtlamış olanı ile uzun süre bilgi teknolojileri çevresinin duyulan ve bilinen ismiydi. Sun’ı ve piyasadaki daha nice OpenSource ürünleri satın alarak bir koldan açık kaynak kullanım paketini desteklerken diğer koldan bu ürünlerin üzerine kendi ticari paketlerini inşa etmektedir. ( aklıma gelen örnekler şöyle sıralanabilir: BEA->Weblogic, AqualogicBPM->OracleBPM…) Yoğun data, veri madenciliği, istatistik ve raporlama gibi konuları içeren İş Zekası çözüm araçlarından birinin veritabanı ile ünlü bir firma tarafından da geliştirilmiş olması bu açıdan şaşırtıcı görünmemektedir.
Oracle BI Enterprise Edition ürünleri BI yetenekleri açısında oldukça geniş bir yelpaze sunmaktadırlar. İnteraktif gösterge panelleri, ad-hoc analizleri, proaktif uyarılar, gerçek zamanlı tahminleme olanakları, kurumsal ve finansal raporlamalar bunlar arasında sayılabilir.
OLAP (Online Analytical Processing) OLAP çevrimiçi analitik işleme için bir kısaltmadır. İş zekası için arama iş verilerini analiz etmek için bilgisayar tabanlı bir tekniktir. OLAP küpü, kendi boyutları içinde anlaşılabilir 1 yada daha fazla boyutlu veri dizisidir.
Kaynak: http://en.wikipedia.org/wiki/OLAP_cube
Oracle OLAP Oracle 11g veritabanı ile entegre olan ,firmalara kolayca bir iç bakış ve kavrama ile iş performansı kazanımını amaçlayan bir bileşendir.
· Harici sorgu, hesaplama ve farklı küplerle harmanlanarak daha kapsamlı yada anlamlı olabilecek raporlamalar yapabilme,
- Zengin analitik yetenekler,
· İşi yapan kullanıcılara (örneğin bütçe uzmanı, mali işler uzmanı…) sürekli IT desteği ile ilerlemek yerine kendi raporlamalarını kendileri tasarlayarak raporlayabilecekleri ortam.
- Yine tüm SQL araçlarınca özgürce erişim imkanı
gibi yetenekler sunulmaktadır.
Oracle BI OLAP
Oracle 11g veritabanı OLAP opsiyonu ile birlikte kurulur. 11.1.1.0.8.7 yada yukarısı olmalıdır. Analitik Çalışma Ortam Yöneticisi (AWM de bu kurulumda işaretlenmelidir)
Kurulum yada kullanımdaki açık konular yada geliştirilmesi düşünülen konular OTN foruma yazılarak destek aranabilir. Yada ticari lisansa sahip olunursa Oracle’dan direk destek istenebilir.
Yerel çokboyutlu nesne tipleri OLAP küplerince desteklenmektedirler. Küpler, Ölçümler(Measures) ile oluşturulup Boyutlar(Dimensions) ile düzenlenirler.
Measures , Sayış, Maliyet, Kar gibi gerçek verileri sunar. Bu veriler veritabanında belli aralıklarla hesaplanarak saklanıp isteğe göre hızlı bir şekile buradan üretilir yada anlık sorgulama zamanında her seferinde hesaplanarak hizmete sunulur. Ölçümler veritabanında saklanıp buradan yüklenir. Ortak hesaplamalarla oranlar, farklar, zaman serileri gibi datalar elde edilir. Hesaplamalar için disk alanına ihtiyaç duyulmaz.
Dimensions, ölçüm datalarını(Measures) tanımlar ve sınıflandırır . Ölçüm datalarının oluşturduğu noktalar forma sokularak kenarlar oluşturulur. Boyut hiyerarşileri isteğe bağlıdır ancak OLAP sistemlerde yaygındır. Bir hiyerarşi bu analiz amacıyla birlikte boyut üyeleri gibi mantıksal bir yapıdır. Bir boyutun yapısı, ebeveyn-çocuk ilişkilerine dayalı hiyerarşik olarak düzenlenir. Bu ilişkiler, çocuk değerlerden üst değerlere düzeyleri arasında gezinme işlemlerini sağlar.
Cubes, benzer verileri aynı boyutta toplamak için uygun bir yol sağlamaktadır. Elbette ki tüm veriler ayn şekle sahip değiller, ayrıca her veriyi kendine uygun şekillendirmek de akıllıca değil. İşte bu noktada OLAP veri modelini çıkartabilmek için küplere ihtiyaç duyulacak. Küpler, benzer verileri doğru boyutlar altında tutmaya yarayacaktır.
BI tool unu Yönetim Kurulu ve Genel Müdür lerin hızlıca raporlamalara ulaşabilmeleri, bütçe planlamaları ve stratejik kararları verebilmeleri için Kokpit projesinde kullanılması amaçlanmıştır. Geliştirdiğim uygulamanın ürettiği veriler de proje kapsamında bulunduğundan küp üzerinde olması gerekmektedir.
Öncelikle, bu verileri çekecek ve küplere doğru şekilde yerleştirebilmek için verinizin ve veri yapinizin anlaşılır, tutarlı olması çok büyük önem taşımaktadır. Veritabanında tablolarda PK – FK yapısının kuvvetli ve standardizasyonlarla constraint lerin düzgün yapılandırılmış olması beklenmektedir. Uygulama geliştirme ekibi olarak BI uzmanlarının istediği formata uygun biçimde veri sağlayacak sorgu view ları hazırlanır, küplere bu sorguların kullanılması anlatılır ve veri tutarsızlığı varsa bu import tan önce kontrol edilmelidir. Bu sebeple şunu belirtmekte fayda var ki BI araçlarının kurulumundan önce düzgün verilerin hazırlanması önemlidir, aksi halde ilerlemek mümkün olmayacaktır.