SOA, palveluarkkitehtuuri ja Amazon

Törmäsin hiljattain kiintoisaan artikkeliin koskien Amazonin SOA arkkitehtuuria. Aiheestahan on kirjoiteltu jo kyllästymiseen asti kaikenlaisia näkökulmia, ja teoreettisia kehitelmiä ja pelisääntöjä pelaa. Toisaalta joskus voi olla yksinkertaisempaakin:

  1. All teams will henceforth expose their data and functionality through service interfaces.
  2. Teams must communicate with each other through these interfaces.
  3. There will be no other form of interprocess communication allowed: no direct linking, no direct reads of another team’s data store, no shared-memory model, no back-doors whatsoever. The only communication allowed is via service interface calls over the network.
  4. It doesn’t matter what technology they use. HTTP, Corba, Pub-Sub, custom protocols — doesn’t matter. Bezos doesn’t care.
  5. All service interfaces, without exception, must be designed from the ground up to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
  6. Anyone who doesn’t do this will be fired.

Täytyy todeta: yksinkertaisuudessaan nerokasta.  Tämä ei tietenkään toimisi ellei mandaatti olisi peräisin kaverilta nimeltä Steve Bezos, Amazon nimisen pikkupuljun toimitusjohtaja. Governanssissa täytyy olla mukana johdon tuki, muuten asiat eivät onnistu. Eivät ne sittenkään välttämättä onnistu mutta jos on yksinkertaiset pelisäännöt joissa on takana vahva ja selkeä tuki, siinä on jo onnistumisen ainesta. Keskitytään olennaiseen. RESTful vaiko SOAP? Vai RMI tai DCOM? Corba? Ei mitään väliä, standardeita ja teknologioita tulee ja menee. Toimitusjohtajan kannalta niillä ei ole väliä, mutta avoimella palveluarkkitehtuurilla taas on suurestikin strategisessa mielessä väliä.

Luin jotain muutakin fiksua viime viikolla mutta ehkä palataan asiaan sen tiimoilta  myöhemmin 😉

Lähde: http://blog.yohanliyanage.com/2012/03/getting-soa-right-thinking-beyond-the-right-angles/

 

 

Mainokset

Eclipse 3.7 päivitykset ja download0/download1 virheet

Jep, tänään tuli törmättyä Eclipse 3.7 Indigo mallin bugiin yhdessä Java 7 kanssa. Päivitettäessä plug-inejä tai itse Eclipse alustaa, alkoi paukkumaan download0/download1 virheitä ja päivitykset epäonnistuivat. Pieni googletus paljasti syynkin:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=317785

Eli mikä korjaukseksi? No, joko lataa suoraan uusimman Indigo version http://www.eclipse.orgista 3.7.1:ssä pitäisi olla jo patchit paikallaan. Tai sitten avaat eclipse.ini tiedoston, ja lisäät sen pohjalle seuraava:

-Djava.util.Arrays.useLegacyMergeSort=true

Ja taas alkaa pelailemaan. Testattu ja toimivaksi havaittu 😉

Java EE 7 kypsymässä

Odotellessa Java SE 8 versiota mullistuksineen, seuraava mielenkiintoinen päivitys – jo tänä vuonna – on tuleva Java EE 7 ”cloud” standardi – eli JSR-342.

Kiintoisia osia tulee olemaan:

– JPA 2.1 ja multitenancy (JSR-338)

– JAX-RS 2.0 ja viimeinkin client API (JSR-339)

– Servlet 3.1 ja websockets, multitenancy, ja PaaS malli (JSR-340)

– EL 3.0 (JSR-341)

– JMS 2.0 ja viimein yksinkertaistettu API (JSR-343)

– JSF 2.2 ja pikkuparannusten ohella HTML 5 tukea lisää (JSR-344)

– EJB 3.2 pääjuttuina PaaS, Multitenancy tuet (JSR-345)

– CDI 1.1 (JSR-346)

– Bean Validation 1.1 (JSR-349)

– JCACHE – viimein standardi cacheille, YAY!! 😉 Tämä on kova juttu. (JSR-107)

– Java State Management – tilanhallinnan standardointia (JSR-350)

– Batch applications for Java -eräajostandardi osaksi EE:tä (JSR-352)

– Concurrency Utilities for Java – concurrency rajapinnat EE ympäristöön (JSR-236)

– Java API for JSON Processing – No REST:n mukana tulee tietystikin JSON (JSR-353)

Että on sitä jotain mitä odottaa. Pääalustoina tietysti JBOSS, Websphere, Weblogic, Glassfish, Tomee, mutta kiintoisaa tulee olemaan myös Oracle PaaS pilvipalvelu, ja se tuleeko esim. Google App Enginen tai Amazonin puolelta tukea uudelle standardille.

Levottomat Web Servicet

Jahas, nyt on taas uusi aihe työn alla: RESTful web services rajapinnat, ja etenkin JAX-RS. RESTful palvelut ovat kovastikin tuttuja itselle, niitä tuli oikeastaan tehtyä jo vuonna 1995, mutta nykyisessä muodossaan toki on enemmän automatiikkaa ja vähemmän tarvetta tehdä matalan tason koodauksella kaikki alusta alkaen itse.

Olen kovasti tykästynyt REST web serviceihin juuri siksi koska ne perustuvat vanhoihin hyviin periaatteisiin ja näin ovat kovin itsestäänselvän oloisia ja vankkoja, skaalautuvat hienosti ja vikasietoisuuskin pelaa. Oman firman sisäiset palvelut ovat olleet REST:iä jo nelisen vuoden ajan. Kaikki kunnioitus myös SOAP palveluille, mutta niistä alkaa tulemaan aika uskomattoman monimutkaisia ja monitahoisia, ne eivät ole niinkään koodaajan juttuja vaan konfiguroijan, ja kovasti palvelinspesifisiä. 

Hassu möhläys että JAX-RS 1 versiosta jäi uupumaan client rajapinnat, nyt tutkiskelen eri vaihtoehtoja toteuttaa fiksu client.