Jersey Examples

Jersey Nedir?
Ornegimize gecmeden once jersey nedir ondan bahsedelim kisaca.
Jersey, RESTFul web servisin sun tarafindan gelistirilen implementasyonudur. Kullanmak icin yapmamiz gereken cok kucukseyler var. Bunlardan bir tanesi, web.xml icerisinde servlet jersey`in destekledigi servlete tarif etmek, Ama bu servlet bisey istiyoruz bizden, oyle bir class yazacaksiniz ki, resources`leri dahil ettiginiz class applicationu extend etmelidir. O application extend ettikden sonra hangi resources var ise onlari bunun icine yazmalisiniz.. Bunun kolay yolu resourcesi / yapip otomatik aratabiliriz. ornegimizde gorecez.

Example-1
Oncelikle bir tane class yaratip, bunu RESTFul web servis yapalim, RESTFul web servis olmasi icin tek yapmamiz gerekn,
@Path("/helloworld")
annotationu ile gostermemiz.
Simdi classimizin icini doldurmaya baslayalim.

HelloWorld.java

import javax.ws.rs.Path;
import javax.ws.rs.GET

@Path("/helloworld")
public class HelloWorld{

@Path("sayHello")
@GET
@Produces("text/plain")
public String sayHello(){
return "Merhaba Dunya";
}
}

web.xml

GOALS - NONGOALS(Avantaj-dezavantaj)

Bir onceki makalemizde RESTFul web servislerin ne oldugunda nasil calisdigindan bahsetmisdik, bu makalemizde ise goals-nongoals( avantaj- dezavantaj)`larinda bahsedecegiz.

GOALS(Avantaj)
-POJO-Based;
POJO tabanli olacak, cok fazla complex arayuzler(interface) kullanmaya ihtiyacimiz olmayacak

-HTTPCentric;
Http merkezli olacak, yani baska protocolleri desteklemeyecem cunku basit olmali.

-Format indenpendece;
Formattan bagimsiz olam, yani biz bugun web arayuzleri nasil MIME tipini gosterebliyorsak ayni sekilde kullanabilmek.

-Container indenpendice;
Contanierden bagimsiz olma, (Application server)

-inclusion in Java EE;
JavaEE specifikasyonunu kullanimi


NONGOALS(Dezavantaj)
-support for java version prior to J2Se 5.0;
Yani j2se 5.0`dan onceki surumler desteklenmez.

-Description, registration and discovery;
WSDL, UDDI, vb. kullanilmamasi(tabii bu dezavantajmi :) )

-Client API;
Istemci APIs spesifikasyonu disinda

-data model/format classes;
Yani model bicimden uzak duracagim, Cunku onlari implemente ederken HTTP stock buyuyor.


Terminology
Resource classes;
WebServisi adi altindan uzaklasiyorum, bu yuzden neyi sunuyorsam onun adina resources diyecem.

Root Class;
Root sinifinin uzerinde path olmali, ve bu URL`de olacak.

Request method designator;
Http biz method annotationlarindan hangisini dinleyecegi


Provider
Yani biz MIME tiplerinden bagimsiz bir veri sundugumuz icin, yani MIME tiplerine bagimli olmasin, muhakkak xml olmasin, muhakkak json olamsin vs.
Peki bizim istedigimizi bu MIME tiplerinden hic biri saglamiyor ise, bu durumda provider annaotationu ile providerleri tarife etmemiz gerekiyor. Yani ben sana bir nesne gonderiyorum, bunun icin detaylari kullanmak icin bu provider class`ini kullanmaliyiz.
NOT: Ilerki makalelerde ayrinliti bir sekilde gorecegiz, ve orneklerle anlatmaya calisacagiz
Mesala bir uygulamamiz var, ben buna bir @Path("sirket") annotationu vermisim,
-@Path annotationlarini hem metodlarda, hemde class seviyesinde rahatlikla kullanabiliriz.
Peki hem class`da hem metodda kullanirsak ne olacak? ozmanda, su olacak, once class uzerinde path daha sonra metod uzerindeki path, yani

http://localhost:8080/webapp/resources/sirket/calisan
burada,
webapp - Bizim web.xml icindeki uygulamamizin adi,
resources - Servlet kaynagi
sirket - Bizim classimizin adi
calisan - Sirket class`imizin icindeki metod adi

@Path("sirket")
public class Sirket{

@Path("calisan")
public ..... calisan(){
...
...
}
.....
.....
}

@Path annotaionunlarini metodlarda kullaniyorsam, ozellikle hagi HTTP metoda karsilik geldigini belirtmem gerekiyor. Yani(GET`mi, POST`mu vs.). Biz belirtmezsek, default olarak @GET calisir
Mesala bir metodun

@GET

@Path("message")

public Srting getMessage(String mess){

-- - - - - -- - - -- -

- -- - -- - - - -

}

bu nasil calisacak

http://localhost:8080/webapp/resources/Clasname/message/Merhaba_Dunya

Burada en sonda belirtigimiz merhaba dunya, metodumuzun parametre degeri yani mess` deger gondermis oluyoruz. Bunlari ilerki makalelerde cok daha ayrintili bir sekilde gorecegiz

NOT: Bir method birden fazla requesti kabul ediyor olabilir. Yani ayni zamanda hem GET`i hem POST`u kabul ediyor olabilir.

Jersey(RESTFul Web service)

Genel olarak islerimizi insan-makina olarak, yapariz, yani bilgisayarda bi e-posta okuma, gonderme vs. gibi isler. Biz bu isler gibi diger islerimizide makina-makina arasinda yapma sansimiz vardir.? Diye dusundugumuzede iste tam bu noktada RESTful web servisler devreye giriyor. Bunlari kullanirkende, Web servislerdeki butun protocol isteklerini WSDL, UDDI, WDAL, gibi servislere gerek kalmadan yapabilmek icin RESTFul web servislerini kullanabiliriz. Biz web`de kulladigimiz URL ile bir takim verilere ulastigimizda isler gayet guzel isliyor.

Mesala bir url ile bir kaynak belirtip

http://www...../..../.../odev.pdf

diye cagirdigimiz zaman sistemde bana o kaynaktaki veriyi cikarip veriyor. Acaba butun bu uygulamalari bu sekilde uygulayabilirmiyiz diye dusundugumuzde iste tam bu noktada RESTFul web servisler devreye giriyor.

Yani ben gidip bir metodu tetiklemeyeyim, yada bir belgeyi burdan gondermeyeyim vs. Ama bir takim metodlarla resourceler(kaynaklar) yaratayim. Web uygulamanin icersinden o kaynaklarada hep URL`lerle yada URI` ler ile erisebileyim.

RESTFul web servisler bu noktada basiliyor, ne oldugu anlasiliyor diyebiliriz. Peki bu oldugunda ne olacak,? Bu oldugunda, aslinda insan maikna arasindaki haberlesme nekadar basitse, yani web`de sorf email okuma vs. Peki benim ayni seyi, makina-makina arasinda yapma sansim varmi? diye cikmis bir protocoldur. Bunu yaparsam, diger WEB serivislerde oldugu gibi,

WSDL, UDDIm vs gibi arabetimler kullanmaya gerek kalmacaktir.

Peki kullanmam icin bana neler lazim ?

1- Birtane URL

2- Bir tane browser, (daha dogrusu browseri dusunmeden tcp uzerinden akan)

bukadar basit yapacagimiz seyler.

Her uygulama icin mutlaka bir URL yaratiriz, bunlari yarattigimizda, zaten http protocolunun icinde 4-5 tane komut var(GET, POST, PUT, DELETE vs.) bunlar vasitasi ile ben islemlerimin cok buyuk kismini %80`i yapabilirim.

Bu makalemiz giris niteliginde bir makeledir. REST ful webservislerin neler oldugundan bahsetmis olduk. Asagidaki linkte RESTFul web servisler icin 50 sayfalik bi pdf dokuman var sun sitesinde, orada daha ayrintili bi sekilde gorebilirsiniz.

Diger dersimizde, avantajlarindn, dezavantajlarinda,vs bahsedecez ve ornek projeler ile daha ayrintili bi sekilde anlatmaya calisacaz, umarim faydali bir yazi olmusdur.

https://jersey.dev.java.net/

JAAS (Java Authentication and Authorization Service)

JAAS java uygulamalari icin kimlik dogrulama ve yetkilendirme islemlerini portatif bir sekilde yapilmasini saglayan bir API`dir. JAAS`i kullanarak kendimiz sisteme giris yapmayi ve uyetkilendirmeyi saglayabiliriz. JAAS`i her hangi bir guvenlik sisteminde kullanabiliriz. Ornegin, bir uygulama sunucusu kimlik dogrulamayi bir dosyadan okuyarak yapiyor olabilir. yada bir veritabanindan sorgulatarak yada bir LDAP sunucusuna baglanarak yapiyor olabilir.

JAAS ile bu ortamlara ayak uydurmak hic sorun degil. Cunku JAAS interfacelerle olusur ve siz interfaceleri implemente edersiniz. JAAS ejb guvenliginde siklikla kullanilir. Sun, JAAS`i EJB guvenliginde standart olarak kullanmaktadir.

Genelde JAAS modullerinin kullanimi ile ilgili iki tip senaryo vardir.

-Bir desktop uygulamamiz var ve bu uygulamamiz uzak bir uygulama sunucusuna baglanip sisteme giris yapacaktir. Sisteme giris saglandikdan sonrada sistemde hangi modullere erisip hangi modullere erisemeyecegi belirlenecektir. Bunun icin desktop uygulamamiz JAAS ile kullanicinin giris bilgilerini uygulama sunucusuna iletir. Uygulama sunucusuda bu bilgileri kullanarak sisteme giris gerceklestirip kullanicin rollerini olusturur, Bundan sonraki EJB metodlarinin cagrilmasinda kullanicinin rollerine bakilir.

- Bir web tarayici araciligi ile sisteme giris yapabilirsiniz. Burada kullanicinin giris bilgileri JSP/Servlet `e aktarilir. Jsp/Servlet`de bu bilgileri kullanarak sisteme girisi gerceklestirir. Tarayici giris bilgilerini asagidaki yontemleri kullanarak aktarir.

-Basic authentication

-Form-Based authentication

-Digest authentication

-Certificate authentuication

Dekstop uygulamalari gibi web uygulamasindada sisteme giris gerceklestiginde, istemci EJB metodlarini kullanici yetkileri izin veridigi olcude cagirir.

JAAS`in calisma mantigina bakarsak asagidaki maddeler cikabilir

1- Istemci yeni bir LoginContext nesnesi olusturur. Bu class JAAS tarafindan sunulmustur ve kimlik dogrulama surecinden sorumludur.

2-LoginContext nesnesi bir Configration nesnesi alir, bu nesnedeki kimlik dogrulama isleminin hangi LoginModule ile yapilacagi bildirilir. Ornegin bir sitem kullanici adi ve sifre isterken baska bir sistem hem kulanici adi-sifre hemde certifica bazli dogrulama isteyebilir.

3-LoginContext Configration nesnesine kimlik dogrulama mekanizmalarin neler oldugunu sorar.

4-Configration nesnesi kimlik dogrulamalarindan olusan mekanizmalardan olusan bir liste dondurur. Bu mekanizmalarin her birine LoginModule denmektedir.LoginModule JAAS`in sundugu bir interfacedir. LoginModule kimlik dogrulama isleminin yapildigi birimlerdir.

5-LoginContext LoginModule siniflarindan birer nesne olusturur.

6-LoginContext olusturulan LoginModule nesnelerini iliskilendirir.

7-Istemci kodu LoginContext nesnesi uzerinden login() metodunu cagirir.

8-LoginContext login islemlerini loginModule nesnelerine devreder. Cunku kimlik dogrulama islemlerinin nasil yapilacagini bu moduller bilmektedir.

9-Sizin tarafinizdan yazilmis LoginModule nesneleri kimlik dogrulama islemini gerceklestirir.

10- Islem sonucunu olusturan bilgiler Subject class`indan olusturulmus bir nesnenin icinde saklanir. Bu nesneyi guvenli islemler gerceklestirmek icin kullanirsaniz.

11- Bundan sonra istemci kodu EJB metodlarini cagirir ve sistem giris bilgisi bu metod cagiriminda otomatik olarak iletilir. Boylece uygulama sunucusu ile bu bilgileri kullanarak kimlik dogrulama ve yetkilendirme islemlerini yapar.

Asagida yukaridaki yapinin resim olarak cizilmis halidir.