PHP z Javą (jak pies z kotem czy...?)

Adaptacja PHP w korporacyjnym środowisku jest coraz większa. Powoduje to konieczność skorzystania z istniejących w tym srodowisku komponentów napisanych J2EE w Javie . Dla przykładu weźmy WebSphere Application Server jako zaplecze oraz front w postaci Zend Platform (z uwagi na PHP/Java Bridge - służący do wywoływania komponentów Javy z kodu PHP ). Są dwa sposoby współpracy:

• Web Service - usługi webowe, narzędzia do tworzenia i pobierania ich są wbudowane w PHP 5 (korzysta z przeładowania metod)
  
• most PHP/Java Bridge - middleware wbudowany w Zend Platform do manipulowania obiektami Java jakby to były obiekty PHP.

Na podstawie artykułu: Achieve J2EE-PHP Interoperability

Mydełko czyli SOAP

Co guru Leyman sądzi o wyborze nośnika WS: "REST is a possible style to implement a SOA. Especially if your application deals with large messages, or will benefit from caching, or has to render results immediately to end users, etc then a REST-based SOA does make a lot of sense. If you need to expose application specific interfaces, if you need message security along a message path with varying transport protocols, if you need choreography etc etc the WSDL/SOAP/... based SOA is preferable." Profesor Frank Leyman opublikował nawet mapę drogową dla SOAP.

Inny badacz Mark Baker jest znanym człowiekiem skłaniającym się jednak ku REST (REpresentational State Transfer) krytykujący wprowadzanie do WS standardów ignorujących potrzeby usług i niepotrzebnie komplikujacych ich implementację. Wywodzi się on z obozu DCE i Corba. Twórcą i pionierem tej technologii jest Roy Fielding który jest współzałożycielem protokołu HTTP 1.1 (udostępnia swoje interfejsy poprzez raz zdefiniowane i zafiksowane na stałe metody GET i POST, podobne ale bardziej rozwiniete idee są w REST. W SOAP jest to bardziej eleastyczne, opis interfejsu jest zawarty w WSDL) i autorem definicji REST. Co daje stały interfejs do usług?

Trzy zalety: prostota (liczba punktów swobody jest niewielka), skalowalność i niezawodność.

Każdy protokół wymiany powinien mieć cztery właściwości (wg. pracy dysertacyjnej Fielding) zapewniających:

1. Identyfikację zasobu ->URI
2. Działanie na zasobach ->GET, PUT, POST, DELETE
3. Samopisywalność komunikatów
4. Hypermedia jako transport stanu semantycznego

Więcej na ten temat: RESTwiki z resources section + tutorial