Category: Public

SpringBoot ile Rest ve Soap Api Örneği

SpringBoot Nedir?

SpringBoot, hızlıca deploy edilebilir yeni nesil web uygulaması oluşturmaya yarayan güzel bir spring implementasyonudur. Çalıştırılabilir jar dosyası çıkartarak web uygulaması ya da servis yazılabilir. Ben bu alt yapıyı kullanarak bir servis yazmak istedim.

Uygulamanın Amacı Nedir?

Servisimde “Poi” adında bir entity’yi crud işlemlerine tabi tutarak, “spring ile nasıl soap api yazılır“, “spring ile nasıl rest api yazılır” sorularına çözüm göstereceğim. Asıl amacım poi’nin hangi property’sini işlediğim değil, spring ile onu nasıl kullandığım olacak.

Servisimi yazarken, Spring’i de yeni öğreniyor oluşumdan dolayı spring’in annotation’larını doğru kullanmaya ve neden kullandığımı da açıklamaya özen göstereceğim. Ayrıca core, webService ve business lojiklerini doğru kullanmayı hedeflediğim güzel bir alıştırma projesi olacak.

Neler Anlatacağım?

Kodları yazı içinde paylaşmak yerine github’ı kullanacağım. Burada anlatacağım şeyler ise, yazılma amacı ve nasıl çalıştığı olacak.

https://github.com/sefersezer/SpringRestSoapApiExample


Proje kaynaklarını anlatmaya öncelikle maven dependencylerinden başlayacağım.

lombok: Compile time’da pojo’lardaki getter, setter, default constructor vb şeyleri otomatik oluşturan, kod kirliliğini azaltmayı sağlayan bir eklenti. Lombok, başka bir makalede detaylıca anlatılabilir.

spring-boot-starter-web: Uygulama web projesi olarak ayağa kalkıp bir portu kullanılabilir sunacak. Ayrıca ws paketinde spring boot web annotationlarını da kullanacağız.

spring-boot-starter-data-mongodb: Veritabanı olarak mongodb kullanacağım. Mongodb bağlantısını da spring yetenekleriyle kuracağım.

spring-boot-starter-ws: Spring web service annotationları için kullanıyorum. Mesela @Endpoint annotation’u soap (ve rest) actionlarını işlemek için projeyi otomatik tarayarak geçtiği sayfadaki @ResponsePayload’lı methodları kullanılabilir kılacak.

wsdl4j: soap api için xsd şablonundan wsdl generate etmeye yarayacak. Örneğin servis endpointi sonuna .wsdl koyarak şablona erişebiliyor olacağım.  (localhost:9000/ services /poiservice.wsdl )

modelmapper-spring: Core package ile Web Service package’larının bağımsız olacağından bahsetmiştik. Hedef pojo’m olan Poi için Web Service katmanında PoiEntity objesi oluşturdum. Bunların her bir property’sini manuel maplemek yerine modelMapper kullanacağım.

jackson: Serializabled objelerimi json, xml setlere dönüştürüp, büyük angaryadan kurtaran muhteşem dependency. #tambiraltinbilezik 🙂

jaxb2-maven-plugin: xsd şablonunu oluşturduktan sonra servis katmanındaki objeler için elle uğraşmayacağım heralde! mvn clean generate-sources ile deploy ettiğimiz zaman belirtilen dizine otomatik generate edilecek. (Artık javada pojo oluşturmak angarya iş olarak gözüküyor. Örneğin eclipse’de Telosys Tools ile pojo, dta, dto, testler vs birçok şey generate edebiliyorsunuz.)


Uygulamanın modüllerini (paketleri) ve sınıf isimlerini aşağıdaki gibi verdim:

  • config
    Spring'in Mongodb bağlantısını sağlamak için özel bir dependency eklemiştik.
    Bu dependency @EnableMongoRepositories annotation'ı sağlıyor. Mongodb
    repositorylerinin bulunduğu paketi göstererek (bir nevi) register ediyoruz.
    Ayrıca bağlantı kurarken host, port, db parametrelerini de
    AbstractMongoConfiguration sınıfını extend ederek set edebiliyoruz.
    
    Burada kullandığım Environment değerleri ise /resources/application.properties
    dosyasından geliyor.
    • MongoConfig.java
  • model
    Uygulamada Poi.java ve PoiEntity.java adında aynı gözüken ama 2 farklı amaca
    hizmet eden pojo bulunuyor. Ben her ne kadar bu projede extreme işlem yapmasam
    da modüllerin bağımsızlığının sağlanması gerektiğini gösterebilmek adına bu
    iki pojo'yu oluşturdum.
    
    Poi.java, uygulamanın core tarafındaki model entity'm olacak. Core tarafındaki
    işlemlerde bunu istediğim gibi manipule edeceğim; complex type olarak kullanıp içine istatiksel veriler vs ekleyip, gerekirse başka yerden
    implemente edilmiş özellikler vs kullanıp istediğim gibi kullanabileceğim.
    Servis tarafındaki PoiEntity.java ise, Poi.java'daki implementasyonlarımın
    çıktısı olacak. Kullanıcıya göstermek istediğim şeyleri en yalın haliyle
    oraya atacağım. Kullanıcı benim arka planda ne yaptığımdan, core'daki
    bağımlılıklarımdan haberdar olmayacak, sadece bu çıktıyı alıp kendi işine
    bakacak.
    
    Mapper, poi ile poiEntity'deki gerekli property'leri birbirine map ettiğim
    mapping servisim. Sınıfı incelediğimizde, normalde daha çok karışık olması
    gerekir ama bu uygulamada bişey yapmadığımdan ModelMapper dependency'sini
    kullanarak direkt mapping sağladım.
    
    repository/ dizinindeki poiRepository ise, mongodb'deki collection'a ulaşmamı
    sağlayan mongoDbRepository örneğim. FindAll, save, delete default işlemlerini
    mongoDbRepository sayesinde yapabiliyorum. Spesifik sorgularım için ise
    namedQuery denilen spring özelliği ile yazdığım methodlara uygun ismi ve dönüş
    tipi vererek crud işlemimi gerçekleştirebiliyorum. Detaylar için şu adrese
    bakabilirsiniz.
    • repository
      • PoiRepository.java
    • Mapper.java
    • Poi.java
  • service
     (acıklama)
    • endpoint
      • PoiRestEndpoint.java
      • PoiSoapEndpoint.java
    • PoiRepositoryService.java
  • ws
     (acıklama)
    • model
       (acıklama)
      • PoiEntity.java
      • ServiceResponse.java
    • rest
       (acıklama)
      • EntityService
      • EntityServiceImpl
    • soap
       (acıklama)
      • dao
        • DeletePoiRequest.java
        • GetPoiRequest.java
        • GetPoiResponse.java
        • ObjectFactory.java
        • package-info.java
        • SavePoiRequest.java
      • SoapWebServiceConfig.java
  • Application.java
    Uygulama bu sınıf ile ayağa kalkıyor. Sınıfa SpringBootApplication annotation
    ve diğer annotationları vererek, springBoot uygulaması olmasını, servis olarak
    çalışmasını, konfigurasyonları okumasını vs söylüyorum; ilk kıvılcımı buradan veriyoruz.
  • resources
     (acıklama)
    • application.properties
    • poiservice.xsd

 

Blog Başlıkları

Merhabalar,

Aklımda yüze yakın sayıda blog konusu var. Bunları yazmak isterim ama tipik Y kuşağı insanı olduğumdan hiçbirşey yapmamak daha cazip geliyor.

Tabi, o kadar da değil; yazıcam bu blogları. Buraya aklımdaki blog başlıklarını not etmek, ilerde de yazdıkça burada üzerini çizmek istiyorum.

Listeye şöyle başlıyorum:

  • Arduino İle Digital Port Dinlemek
  • Maven Parent <> Dependency Versiyon İlişkisi
  • Maven Deneyimlerim
  • Jenkins Hakkındaki Yorumlarım
  • Docker Hakkındaki Yorumlarım
  • Coordinate Clustering (DBSCAN Algorithm)

Apache Web Server, Load Balance & Clustering ve Site Routing – Bölüm 2

Konu 2: Load balancing yönetimi sağlayan bir yapı tasarlamayı düşünüyorsunuz.

Bir uygulamanız var. (seferOver v2.0) Bu Tomcat veya JBoss Application Server altında çalışıyor. Bir gün stabil çalışmayacak hale gelene kadar (memory leak – genellikle geliştirici hatasından kaynaklanan overflow error | https://plumbr.eu/  bir göz atın.) çok istek geldiğini gördünüz, uygulama çok trafik yükü altında kaldı ve dikey yükselmenin (bandwidth genişletme, yeni trafik alanı satın alma, memory upgrade, cpu upgrade) yetersiz olduğunu, yatay yükselmeye ihtiyacınız olduğunu farkettiniz.

Uygulamanının içinde session yönetimi yapılmalı ve bearer token kullanmıyor / kullanamıyorsunuz (http://en.wikipedia.org/wiki/OAuth) (Bu durumda MemCache veya EhCache kullanılmalı)

Yatay genişleme için birden fazla (vm veya dedicated fark etmez – Artık bizim için dedicated sunucu ayırımı yok. Hepsi aynı.) sunucuya sahipsiniz. Uygulama sunucunuzu ve uygulamanızı her birine kurup eşit veya isteğiniz oranlarda istek yükü paylaşımı yapmak (process yükü değil, request – response yükü) istiyorsunuz.

Uygulamanız sadece servis ve arayüz olarak değil dosya – lisans üretme yeteneğine sahip ve her istediğinizde her makineden doğru yanıt gelmesini istiyorsunuz… (bunun anlatacağım konuyla direkt olarak ilgisi yok. Bu konu için memcache veya ehcache kullanılmalı.)

Gereken Malzemeler:

  • Birden fazla server (test için aynı server üzerinde de yapabilirsiniz)
    Internal Lan Ip’leri 10.11.12.{13 , 14 ve 15} olan makineleri kullandım.
  • Apache Web Server (10.11.12.13)
  • Apache Web Server için mod_jk.so
  • Birden fazla Tomcat (tomcat1: 10.11.12.14 ve tomcat2: 10.11.12.15)
  • Bir uygulama. (uygulamanız kendi içinde tomcat veya jboss taşıyabilir halde de olabilir. Bu durum için farklı bir konfigurasyona gerek duyulmamaktadır.)

Uygulanan Ortam:

  • Centos 64 bit server (test amaçlı olduğu için önce 1 server üzerinde çalıştım. Sonradan farklı makinelerde test için workers.properties dosyasında localhost değerlerini internal lan IP’leri ile update etmem yeterli oldu)
  • text editör olarak nano,
  • iptables servisi,
  • Apache web server’ın yönetimi ele alması için SELinux ayarlarına erişim ve
  • Sistemi restart edebilmek için root kullanıcı yetkisi.

ve gelelim Yapılan İşlemlere:

  • Apache web server 80 portunda çalışacak. Bunda sorun yok.
    service httpd start | restart | stop ile yönetebiliyoruz. ok
  • Tomcat1‘ in conf/server.xml dosyasında aşağıdaki parametreyi http protokolü ile bu tomcat’e erişilmesini istemediğimden comment içine aldım.
<!-- <Connector port="8081" protocol="HTTP/1.1"
 connectionTimeout="20000"
 redirectPort="8443" />
 -->
  • Şimdi ajp protokolünü devreye sokalım. Tomcat1 için 8081 portu kullanılsın. Burda redirectPort parametresine karışmadım. Sadece port parametresini değiştirdim. Tomcatimiz apache’ye bu port üzerinden ajp protokolü ile haberleşecek. http üzerinden direkt tomcat’e erişme imkanımız, yukarıdaki blok comment’e alındığından mümkün değil. Eğer http de açık olsun isterseniz (test sürecinde) Http protokolü ile ajp protokolünü aynı porta vermemelisiniz.
 <Connector port="8081" protocol="AJP/1.3" redirectPort="8443" />
  • Aynı makinede 2 tomcat varsa ve birini kapatmanız gerektiği durumda diğerini etkilememesini – çakışmamasını istiyorsanız shutdown portunu da ayarlamanız gerekmektedir.
    Port değişimi:
 <Server port="8005" shutdown="SHUTDOWN">
  • Worker tanımlaması:Not: Eğer tomcat1 deki worker tanımlaması buna yapılırsa ağırlık ve istek önceliği bu sisteme verilecek. Hangisinin öncelikli yanıt vereceğini, hangisinin IDLE olarak bekleyeceğini jvmRoute parametresi belirliyor.
    <Engine name="Catalina" defaultHost="localhost" jvmRoute="worker1">
  • İçerik Tanımlaması:

Evet. Burası sıkıntılı. Şimdi ben uygulamamın adını myapp olarak ayarladım diyelim. Normal şartlarda tomcat’te “/myapp” veya “/”(root) path de çalıştırabilme imkanım var. Bunu zaten biliyoruz. Routing konfigurasyona geldiğimizde ise, sadece /myapp altında çalıştırma imkanım kalıyor. Ben root ‘ta çalıştırma imkanı bulamadım. Benim asıl uygulamam routing konfigurasyonunda yaptığım ayarlamalar ile root’ta çalışmadı. Belki de ben becerememiş olabilirim.

mod_proxy ile ve url redirect komutları ile /myapp dizinindeki uygulamayı root’ta göstermeyi de, virtual path yaratmayı da denedim. Belki de uygulamamdaki bir problemden kaynaklı olarak bunu becerememiş olabilirim. Çünkü küçükcük ufacık tefecik programlarla bunları becerebildim; benim kurmaya çalıştığım uygulama spring ile harmanlı olduğu için baharatları gaz yapmış olabilir (:

<Context path="/myapp" docBase="myapp" debug="0" privileged="true" />
  • Tomcat2 için yukardaki işlemleri tekrarlıyoruz
    jvmRoute=”Worker1″ konfigurasyonunu tomcat2 için yapmıyoruz. Ajp portunu aynı makinede ise 8082 yapabilirsiniz. Aynı makine üzerinde olacaksa port farklı olmalıdır. Farklı makine üzerinden apache web server’a request/response gönderecekse farklı port olmasına gerek olmamaktadır. Hatta bu durumda her ikisi de 80 bile olabilir yani.
  • Apache Web Server yüklenmiş olması gerekliliğini atlamış olabilir miyim – evet.
yum install httpd
  • Apache Web Server yüklemesinden sonra /etc/httpd/conf/httpd.conf dosyasında commentli olarak aşağıdaki yazıya benzer birşey bulunmaktadır. Onu pageDown ile gezerek bulup commentsiz olarak şunu yapıştırıyoruz
ServerName localhost:80
  • /etc/httpd/modules/ dizinine mod_jk.so dosyası kopyalandı
  • /etc/httpd/conf/httpd.conf dosyası içinde, diğer LoadModule işlemlerinin sonuna şu ayarlar yapıldı:

Burada Jk mount ayarlamalarım var. Eğer uygulamanızı root path’de çalıştırabiliyorsanız aşağıdaki gibi olacak. Eğer root path da çalışmıyorsa mecbur sonu yıldızlı isminin olduğu path’den çağırılacak. ” JkMount /myapp* myapp ”

#SEFER BEGIN
LoadModule jk_module modules/mod_jk.so
JkWorkersFile /etc/httpd/conf/workers.properties
#JkLogFile /etc/httpd/conf/mod_jk.log
#JkLogLevel info
#JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
JkRequestLogFormat "%w %V %T"
JkMount /status status 
JkMount /* myapp
JkMountCopy On
#SEFER END
  • Apache için /etc/httpd/conf/ dizinine yeni bir workers.properties dosyası oluşturuldu:
worker.list=loadbalancer,status
 worker.worker1.port=8081
 worker.worker1.host=10.11.12.14
 worker.worker1.type=ajp13
 worker.worker2.port=8081
 worker.worker2.host=10.11.12.15
 worker.worker2.type=ajp13
 worker.worker1.lbfactor=1
 worker.worker2.lbfactor=1
 worker.loadbalancer.type=lb
 worker.loadbalancer.balance_workers=worker1,worker2
 worker.status.type=status

Burada Tomcatler için tanımlanan portlar worker olarak girildi

lbfactor ile yük oranı 3:1, 4:2 tarzında (1:1) tanımlandı.

  • Centos sunucusu için SELINUX ayarı kapatıldı.

/etc/sysconfig/selinux dosyası için şu yönergeler izlenebilir.

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled. ***bununla değiştirdim.**
SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0

  • Sistem restart edildi
  • Httpd servisi başlatıldı, tomcatler çalıştırıldı.

İşlemler bu kadar. Yazının başında bahsettiğim ihtiyaçları karşılayabilecek yapıyı kurduk. Balance ayarlarını kullacağınız sistemlerin ağ ve donanım hızlarına göre ayarlayabilirsiniz. Tertemiz oldu. Hepsi bukadar.

Apache Web Server, Load Balance & Clustering ve Site Routing – Bölüm 1

Konu 1: Bir apache Serverda birden fazla farklı tomcat’ı çalıştırmak istiyorsunuz.

Bunlar farklı uygulamalar çalıştıran tomcat’ler ve biri durdurulursa diğeri etkilenmemeli.

Aynı domain veya IP altından internete çıkmalılar. Port numarası görmek istemiyorsunuz.
Örneğin developer.sefersezer.com/jira ve developer.sefersezer.com/wiki

Dışarıdan bu uygulamalara erişilmesini istemiyorsunuz. Direkt olarak tomcat1’in bulunduğu makineye istek gitmesin, apache web server bunu yönetsin istiyorsunuz.

Yönetimini sağlayan apache web server makinesi ile aynı veya farklı makineler altında olabilme esnekliğine ihtiyacınız var; yani web server’a birşey olma durumunda farklı web server altından bu tomcatleri dışarıya çıkarmayı istiyorsunuz.

Sen Neymişsin Be Java!

“Java biliyorum” diyebilmek için neler gereklidir? Yazılımsal ve fikirsel olarak nelere ihtiyaç vardır? Sadece teorik olarak JAVA dilini bilmek yeter mi yoksa insanın canından bezdiren kurulum aşamaları, linux, mvc disiplini, en az bir framework ve gerekli araçların da (artık bu saatten sonra teorinin yetmeyeceğini anlamışsınızdır) öğrenilmesi biliyorum diyebilmeye yetecek mi?

.net frameworkune aşina, webde 2-3 yıl asp.net olsun .php olsun javascripti olsun deneyimler kazanan insanlar javaya ne kadar alışabilir? Ve daha birçok soru var aklımda cevaplanmayı bekleyen…


01.01.2015
Geçtiğimiz yılda java dili ve ortamı için önemli adımlar attım. Biraz anlatmak kendim için de iyi olacaktır. Hemen başlıyorum,
Geçtiğimiz sene Spring Framework’un kabiliyetlerine göz attım. Bunun için internette yabancı kaynaklı birçok pdf var. Bunlara boş vakitlerde göz gezdirerek Spring ile neler yapılabilir, genel olarak bahsetmek gerekirse notasyon yönetimi ne fark ve fayda sağlar, Spring Framework hangi ortamlarda kullanılabilir, MVC managment’i nasıldır bunları gördüm.
Bir örnekle; android için, web ortamı ve desktop ortamı için yazdığınız kodu Spring ile yönetebilirsiniz. Veritabanı için hazır kütüphaneleri kolaylıkla kullanabilir, Spring mvc & hibernate ile kurumsal projelere ayak uyduracak kodlar yazabilirsiniz.
Gerçekten de etkilendim. Java ortamı, Spring Framework & Yeteneklerini kullanabilen geliştiricileri kendine bağlıyor. Java, üzerine uzmanlaşıp onunla ömür boyu yaşamaya değer bir dil ve ortam sağlamış. Kod yazmaktan zevk alan insan daha ne ister ki! Bu aşık eder insanı kendine.

“Kurumsal işleri için Java kullanılır” sözünü java ile geçirdiğim süre içinde değerlendirdiğimde her şeyin bu ortamda yıllar önce temelinin atıldığını, bir düzenin kurulduğunu gördüm. Zor işlerin java ile başarıldığını gördüğümde, Jvm’in yeteneklerini, jvm’in big data managment projelerinde sağladığı esneklikleri gördümde “işte aradığım bu” dedim.

Hani şu beğenmediğimiz 200 – 300 mb’lık Eclipse var ya, öyle yeteneklere sahip olabiliyor ki .Net Visual Studiodan daha eğlenceli olabiliyor! Projelerin çoklu geliştirici desteği, repository ve code history yönetimi, -her konuda- bağımsızlık, testler (testler çok önemli. Ayrı başlıkta bunun önemine değinmeyi planlıyorum), taşınabilirlik, kütüphane yönetimi, mocking, dakikalar içinde service yazmak gibi konularının önemli olduğu projelerde (kısaca kurumsal ve büyük projelerde 🙂 ) java ve ortamı kullanılmalı. .Net artık benim için bir alternatif. Bundan eminim. .Net ortamı için Microsoft Foundation Server ve Cloud Development için Azure (bunların registration süreci bile insanı boğuyor) gerekiyorsa JAVA tarafında da elbet bir karşılığı var ve kullandığımız ortam; yıllar önce okulda Java dilinde ekrana “hello sefer” yazıp kapattığımız Eclipse ortamı …

Bu beyni nasıl kullanıcam?

Konumuz beyin. Öncelikle bu makalenin artımlı olarak düzenleneceğini belirteyim. eksik ve kopuk olarak yazmış olabilirim; fikirler kelimeler hazır değil…

Normalde ‘kız beyni’ – ‘erkek beyni’, ‘tasarımcı beyni’ – ‘zeki insan beyni’ gibi ayrımlar yapılır. Peki karşıt özelliklerin bir insanda buluştuğu beyin nasıl tanımlanır? Buna combo mu desek mesela? Hybrid ya da…

900-Paint-Brain-l
Bir kategori uyduramadım, gerek de yok zaten. Çünkü ikisine de sahip olduğunda yaptığın işe, işinin bölümüne göre beyninin ‘tasarımcı’ olan sağını, ‘fikir adamı’ olan solunu kullanıyorsun. Diğer adı koyulmuş düşünce fikirleri de önyargılarını aştığında sende; içinde buluşuyor… Önemli olan önyargıları bırakıp da bir fikri somutlaştırırken; yaptığın işin doğru olduğuna önce kendin inanman ve yolundan şaşmaman..

Arkadaşın eğer bir fikir söylüyor da senin fikrini komple değiştirmene sebep oluyorsa sende ciddi bir hata var demektir. Fikrine fikir katsın bakış açını genişletsin ama direkt olarak etki etmesin. Olayın doğrusu bu. Kim ne derse desin.

Aslında olayların birçoğu önyargı ve kendine güvenmekle ilgili. Kendine güvenmeyen insan otomatik pilotu olan önyargısına güveniyor -> arkadaşı birşey söylüyorsa hemen true cevabını atıyor ve… işte boka sardı… sonrası felaket. Eğer önyargını kontrol edebiliyor, karşındakinin asıl amacını anlayabiliyorsan beynini kontrolden çıkarmıyorsun ve felaketten o an içinde kurtulmuş oluyorsun.

Ek: özellikle de kurumsal bir şirkette çalışmaya başladıktan sonra bunların ciddi konular olduğunu gördüm.

Konuya dönüyorum, beyin yoğun durumlarda veya sakinlik içinde kendini hardcore çalışmaya veya rolantiye almaya müsait yapıda. Tek tek bunları yapıyorsan sorun yok. Ya işin her ikisini de aynı anda kullanmayı gerektiriyorsa!? İşte o duruma  ‘Yazılımcı beyni’ diye bir tabir buldum. Bu beyin tiptronik vitese sahip mercedesler (hem otomatik hem de manuel olarak vites değiştirebildiğin vites kutusu) gibi çalışır. Uygulamanın tasarımını yaparken beynin sağını, bitirdin kodu yaz solunu, kodu tasarıma uyarla sağını, test et solunu, bakış açını değiştir her iki tarafı da… Bunu yapabilen çok fazla insan göremedim. Yapabildiğini sandığım insanları da uzun süre sonra tekrar gördüğümde önyargılarına bağlandıklarını – bağımlı olduklarını gördüm; acıdım. Yazık.

Artık bu yazının devamı için örnek vermem gerekiyor. Hangisini versem bilemiyorum. Yazacağım….

Gelecek.

Github ile gizli yeteneklerini ortaya sermek

Github ile gizli yeteneklerini ortaya sermek

“Ben bunu düşünmüştüm” anlarından biri daha… Sene 2008 – 2009; daha lisedeyim. Projelerimi word e açıklamalı bi şekilde yazıp bi de bişey olmasın diye pdf formatına dönüştürüp flash belleğimde taşırdım. Gerektiğinde de oradan ilgili kodu bulup yerinde kullanmaya çalışırdım… İlerde internet sitem olursa oraya da koyarım gibisinden düşüncelerim beyin fırtınalarım vardı. Var da. Ama durun! Github daha iyisini, daha gelişmişini düşünmüş yapmış. Hemen okuyalım ne olduğunu.

(İşte bunlar hep deneyim. Öyle yok Yunanlar öğle aralarında uyuyor, yok İspanyollar 13:00te güne başlıyor diye diye yatıp uyursanız hiçbirini takip edemez, öğrenemezsiniz… Bi de yok mu okulu bitirme yıllarına gelmesine rağmen ben şunu öğrenicem ben bunu öğrenicem diyenler… Geç bile kaldınız!)

Doğum günümde Alınacaklar Listesi

Böyle bir listeyi en çok istediğim şeyleri yazmak için oluşturdum. Biri bunları almazsa kendim de almayacağım. Bunlara sahip olmamı istemiyorsanız almamanız yeterli. 😦

  • ilginç renkli pilot kalemler
    beautiful_1x
  • Macbook Pro
    macbook
  • 7 Mart ’14
    Benimle çektirdiğiniz bir fotoğrafı doğum günümde -çerçevelettirmeseniz de olur- hediye olarak vermeniz benim için çok anlamlı olur. Çok sevinirim.
    Polaroid-camera
  • IPod Touch-5     (01.01.2015) (Doğum günüm yarın)
    new-ipod-touch-32-go-blue-generation-5

SOA Nedir?

Yazılım dünyasında birçok şeyi bildiğimi zannediyorum. Bilmediğim diğer şeylerin ise aslında bana çok da uzak olmadıklarını SOA ile gördüm… CV’lerde, iş ilanlarında hep birşeylerin kısaltması yazılır. Ben bunların isimlerini (kısmen) bilmiyorum. Ama yaptıkları iş; evet onları biliyorum. Bunlardan biri SOA.
Serkan Yazıcıoğlu kaynaklı bir tanım buldum, sizlerle paylaşıyorum… Sizin de bu tanımı bildiğinizi, kullanıdığınızı, sadece adının ne olduğunu bilmediğinizi varsayıyorum değerli yazılımcı rakiplerim =)
SOA (Service Oriented Architecture) birbirlerinden farklı servislerin daha karmaşık yapılar oluşturabilmesi için bir harmoni içerisinde beraber çalışabilmesi yaklaşımıdır. Dolayısıyla servis tabanlı mimari yaklaşımı ile tasarlanmış bir sistemin alt sistemi ise doğal olarak servisin ta kendisidir. Servisler ise birbirleri ile iletişime geçebilen yapılardır.

Detaylar:

Klasik mimari bize katmanların birbirleri ile konuşmasını ve üst katmanın alt katmanı çağırmasını söylemektedir. Katmanlı mimari dediğimiz bu yapının oluşturulabilmesi için belirli işleri yapan katmanların bölünmesi ve düzgün bir hiyerarşi ile birbirleri ile konuşabilmeleri şarttır. SOA ise en basit haliyle bu katmanların servis olarak oluşturulmasıdır. Tekrar basit mantık ile devam edecek olursak normal şartlarda oluşturduğumuz data katmanını bir servis haline getirdiğimiz taktirde aslında bir servis yapısına adım atmış oluruz. Bu sayede data katmanımız sadece tek bir uygulamaya değil içeriden ve dışarıdan birden fazla uygulamaya hizmet verebilir hale gelir. Anlıyacağınız üzere SOA bir framework veya kütüphane gibi elle tutulabilir bir altyapı değil, mimari bir yaklaşımdır.

SOA’nın S’si

İlk başta “servis tabanlı mimari” yaklaşımının tanımına bakıldığında servis kelimesinin web servisler (XML Web Services, WCF vs.) ile bağdaştırılması çok olası olmakla birlikte hatalı bir düşüncedir. Tabi ki özellikle WCF teknolojisi SOA yaklaşımı için çok uygun bir altyapı olsa da sadece IIS üzerinde host edilmediğini düşünmemiz gerekir. Örnek vermek gerekirse bir WCF servisini Windows servisi üzerinde host edebildiğinde ve tcp üzerinden connection kurulduğunda makinenin hiçbir internet veya intranet bağlantısı olmayabilir. Sadece windows servislerinin kullanılması da farklı bir yaklaşımdır. Bus servis olarak tasarladığınız bir windows servisi veritabanındaki kayıtları devamlı kontrol ederek işlem yapabilir. Veya hiç windows veya WCF servislerine girmeden direk MSMQ altyapısı da bu yaklaşım için kullanılabilicek bir diğer teknolojidir. Saydığım teknolojiler tabi ki hep MS ürünleri, bir de işin MS olmayan kısmı var ama buranın üzerinde şimdilik çok fazla odaklanmayalım.

Neden SOA?

Tekrar Kullanılabilirlik

Sebeplerden ilkine ve belki de en önemlisine aslında az önce değinmiş olduk. SOA’nın temelinde birden fazla uygulamaya veya kullanıcıya (client) ulaşabilme ihtiyacı bulunmaktadır. Yani tanımlama yapmak gerekirse amaç tekrar kullanılabilirliktir. Biraz işin pratiğine bakalım. Örnek olmak gerekirse bir adet ASP.NET web sitesi geliştirildi fakat müşteriden bir de IOS uygulaması talebi geldi. Bu isteğin ardından IOS için web servisler yazılır ve bundan sonra yapılacak tüm güncellemeler iki taraf için de ayrı ayrı yapılır. Sonuç olarak tekrar kullanılabilirliği göz ardı etmiş, geliştirme maliyetini ve hata çıkma ihtimalini de ikiye katlamış olduk. Bu gibi sıkıntılara yol açmamak için baştan servis mimarisine uygun bir tasarım işlerimizi çok kolaylaştıracaktır.

SOA1

Benzer bir durumda sizin kontrolünüzde geliştirilmeyen (3rd Party) uygulamaların sisteminize entegre olma isteğidir. Bu gibi durumlarda önceden yazılmış servisler işimizi kolaylaştıracaktır.

SOA2

Heterojen Sistemleri Bağlayabilme

Günümüz yazılım dünyasında ortak bir altyapının oluşması mümkün değildir. Sistemlerin teknolojisinin farklı olabileceği gibi aynı teknolojide farklı versiyonda sistemler ile de karşılabiliriz.

Bağlılığı Azaltma (Loose Coupling)

Servisler birbirlerine sınıflar ile değil şema ve kontratlar ile bağlıdırlar. Dolayısıyla da bağlılık azdır. Bir servisin yerine aynı şemaya uyan başka bir servis çok daha rahatlıkla getirilebilir. Örnek vermek gerekirse bir Java servisininin yerine .NET servisi konulabilir veya aynı şemada ama farklı bir iş akışında başka bir servis ile değişiklik yapılabilir.

Ayrıca bağlılığı azaltmak sistemde oluşabilecek darboğazları da azaltır. Örnek vermek gerekirse E-mail gönderme servisindeki bir hatadan dolayı iletişim sayfası yavaşlamaz.

Basitleştirme ve Gizleme (Facade)

Karmaşık yapıların ve karmaşık servislerin daha basit bir arayüz üzerinden sunulması için bu tarz bir mimari kullanılabilir. Bu tarz bir yaklaşım daha çok farklı yazılımcılara servis açtığınızda teknik karışıklıktan ve iş akışlarından uzak tutmak için tercih edilir. Arka taraftaki sistemlerin ve kullanılan teknolojilerin neler olduğu gibi kapsamlı bir bilgilendirmeden ziyade sadece servis hakkında bilgilendirme tüketici (consumer) için yeterli olacaktır. Burada tüketiciden kastım servisi kullanan diğer sistem, servis veya uygulamadır.

Bazı durumlarda tüketcinin rolüne, yetkisine vs. göre farklı verilerin gösterilmesi gerekebilir. Bu gibi durumlarda servis üzerinde filtrelenmiş bir veri iletimi ideal güvenliği sağlayacaktır. Bkz: DTO

Soyutlama

Her servis kendi işinden sorumludur. Şifreleri üretmesini istediğiniz servisiniz sadece şifreleri üretirken login işlemini yapan servis sadece kullanıcı adı ve password bilgilerini kontrol eder. Her bir parça birbirinden ayrı ayrı tasarlandığı için uygulama daha basit parçalara bölünmüş olur. Bu da kodun okunabilirliği arttırırken, bakım süresini kısaltır.

SOA Yaklaşımı Nerelerde Kullanılmalı

SOA yaklaşımı daha çok heterojen, birden fazla sistemin (işletim sistemi gibi), tüketicinin (consumer), uygulamanın (client) yer aldığı yapılarda tercih edilmelidir. Aksi taktirde fazladan bir esneklik sağlamanın karşılığı fazladan bir maliyet olarak karşımıza çıkacaktır. Basit, tek client üzerinden çalışan uygulamalarda klasik katmanlı mimari tercih edilmeye devam edilebilir.
Teşekkür ederim.

Api Oluşturmak

Öncelikle api nedir bunu bir anlayalım.
Api, Application Programming Interface kelimelerinin baş harflerinden oluşan bir kısaltmadır. Uygulama Programlama Arayüzü anlamına gelen Api, herhangi bir uygulamanın belli işlevlerini diğer uygulamalarında kullanabilmesi için oluşturulmuş bi modüldür. Google translate api, twitter api, instagram api, facebook gibi örnekleri vardır.

Soru: Ben nasıl yapacağım?
Cevap: Şimdi şöyle bir problemim vardı, kendi yöntemlerimle çözdüm. Sonra baktım ki ben burada api yazmışım ve kullanıyorum! Biraz daha açıklıyorum;

Android uygulamamda kullanıcı metin kutusuna bir yazı yazıyor, butona tıkladığında o metin birkaç ‘karakter replace’ işleminden geçtikten sonra (burada encode işlemi yapıldı) JSON ile http://www.siteadi.com/get_data.php sayfasına POST ediyorum. Ardından sunucuya gelen metin tekrar ‘replace’ ediliyor (burada decode işlemi yapıldı). Bu metin birkaç ‘php işleminden’ geçiyor, veritabanına kaydedilip POST cevabı olarak farklı bir metin veya değişken olarak ve de SUCCESS değişkeni ile android uygulamama geri dönüyor. Ben gelen metni farklı amaçlara hizmet etsin diye kullanıyorum ve işlem tamamlanmış oluyor.

Yukarıdaki senaryoda android tarafında sadece bir link gördüm. Bu linke metin post edip cevabını aldım. İçeride neler dönüyor neler bitiyor {android tarafında} hiç bir şey görmedim. Bu sunucu üzerindeki yapı API oluyormuş. Eğer bu linklin sonuna http://www.siteadi.com/get_data.php?API_KEY=DRstH36RPrdp1qrkahc3t yazsaydım ve o keyi sunucu üzerinde kontrol etseydim public olarak değil de bir kullanıcıya yönelik işlem yaptırmış olurdum. Ve o key sayesinde kullanıcıyı kısıtlamış, izlemiş ve loglamış olurdum…

Not: Durumlar henüz olgunlaşmadığı için site adını, yapılan işlemlerin detaylarını, metin gönderip alma olayının sebebini – ne işe yarayacağını şimdilik yazamıyorum. İnanın ki süper birşey oluyor….
Yakın zamanda herşeyi resimlerle ve dil seçenekleriyle açıklayacağım.

Şunu da inceleyin, ben hemen geliyorum. https://developers.google.com/google-apps/app-apis