Cross Domain Mashup January 18, 2010 19:07 7 months ago
For at forstå værdien og forholdet mellem virksomhedens SOA løsninger og mashups er det nyttigt først at forstå hvorfor vi i det hele taget har brug for mashups!
- mashups give dig hurtigere svar
- mashups forbedre din ressourceforbrug (af både personale og bløde/hårde computing ressourcer)
- mashups hjælpe dig med at tage fat på nye forretningsmuligheder ved at lade brugerne sammensætte data i en opportunistisk måde
For en SOA enable virksomhed ligger det lige for at bygge og udstille et mashup lag mellem den interne SOA arkitektur og deres kunder. Det vil indkapsle de meget forretnings orienterede services og udstille et klient venligt allotment data lag. Det er forørigt en god måde at holde sine klient publicerede interfaces konstante mens den interne SOA protokol sikkert udkommer i flere nye versioner.
Set i forhold til SOA og alle de komplekse “Entreprise” løsninger er mashup mere:
- Collaborative. Mashups er designet til at blive mærket/søgba/deles med andre.
- Focused on ‘pack’. Mashups er typisk skabt et lille antal selekterede beslægtede individer.
- Tidsfølsomme. Brugernes behov for data er nu. Mashups har normalt nær real-time levering krav. WWW er real-time.
- Noninvasive. Der skal ikke indføres ny infrastruktur eller faglige forbindelser.
- Limited cleansing. Mængden af data og behov normalisering bør sammenlignes med størrelsen at et Excel ark.
- Have a face. Mashups har normalt et ansigt som en widget.
Mashup applikationer eller mashup widgets lever godt med et SOA endpoint som backend og vil betrakte SOA akitekturen som en service cloud.
Det vil hjælpe med til at fragmentere infrastrukturen på en mere hensynsfuld måde fremfor at SOA løsningen både skal sig af tunge forretningsmæssige ting og samtidig henvender direkte til enkelte kunder. Det er her mashup kommer ind i billedet. Et mashup kan bidrage til at skabe en ny, dynamisk, og potentielt stor gruppe af forbrugere til dine tjenester. Og det er derfor en SOA-arkitekt skal bekymre sig om mashups: Mashups kan blive en uvurderlig direkte sammenhæng mellem en SOA og erhvervslivet i en organisation.
Der findes flere typer af mashups eller arkitektoniske stilarter. Normalt kan man kalde en webside for en mashup når den benytter data og funktionalitet fra mere end den server hvor den kommer fra. Ofte vil der også være langt mellem de adrætte kunde relaterede projekter og de afdelinger som skaber services.
- Klient Mashup er den mest almindelige stil og den er målrettet til at eksisterer hos klienten i form af HTML/CSS og Javascript. En fordel er at man delegere datafangst til ud til klienten dermed væk fra serveren.
- Data Mashup er mindre kendt idet den kombinere samme type af media og information fra flere forskellige kilder i en enkelt repræsentation. Denne stil er server-baseret og samler interne og eksterne data til en enkel ny repræsentation.
- Enterprise Mashup er i fremgang og fokuser på at repræsentere forskelligformede data i en mere enkelt form og fordeler dermed arbejde mellem forretningen, udvikling og ikke mindst hardware. Denne type virker specielt godt i forbindelse med sande adrætte udviklingsafdelinger der hvor krav til “time to market” og iterativ udviklings proces er et issue. Enterprise Mashups er sikre, visuelle rige web applikationer der eksponere handlingsrettede information fra diverse eksterne og interne informationskilder.
Mashups synes at være en variation af et Design Pattern Facade. En forskel er dog at snitflade/interfacet mellem de enkelte systemdele er mere tydelig og afgrænsede. Facade pattern er en interproces kommunikation mens mashups er fysiske adskilte grænsefladesnit over HTTP.
Mashups kan med fordel bruges med software as a service(SaaS). Mange mainstream virksomheder kan drage fordel ved brug af mashups til at forenkle deres integration mod interne og eksterne serviceorienterede arkitekturer(SOA) ved at gøre dem tilgængelige til mashups. Med standardiserede protokoller skabes en ensartet metode til at få adgang til oplysninger udfra et bredt sæt af platforme, operativsystemer, programmeringssprog og applikationer. Selv disse kan igen genbruges til at levere helt nye tjenester og applikationer på tværs af organisationer. Det giver virksomhederne fleksibilitet. se OIORest.
Mashups er velegnet til at skabe rige applikationer med stor udnyttelse af klient tilstand eller state i form af “hateoas”(Hypermedia As the Engine of Application State). Fordi mashup fordre mere tilstand væk fra serveren opnås mange fordele. En server med stateless tilstand er en billig server. Man behøver ikke replikere tilstand i server farmen. Hvis det er ligemeget hvilken server man rammer er det muligt at skabe skalerbare løsninger billigt.
Javascript kan kun kalde den server hvorfra den kommer. Denne sikkerhedsmodel hedder Same Origin Policy(SOP). Hvis javascript kunne kalde servere med ondsindet program stumper kunne man lave “Man-in-the-middle” angrep mellem bank og kunde. Dette er meget komplekse problemstillerer men for specielle applikationer kan man kontrollere denne trafik. Man kan overvinde SOP ved at indsætte et dynamisk scriptelement i websiden
Moderne browsere understøtter kommunikation mellem klient og server og er den vigtigste bestanddel af nye såkaldte Web 2.0 applikationer. Data hentes uden er reloade websiden ved hjælp af XMLHttpRequest objektet der lader Javascript etablere HTTP-forbindelser til en ekstern server. Denne form for kommunikation er basen i mashups.
Resultatet af en asynkront kald fra en browser er data i JSONP format. Mashups bruger JSONP til at lave et lille trick på klienten så koden kan kalde tredieparts services uden om SOP. Som regel vil man gerne have overført data i JSON format fordi JSON er valid Javascript pakket ind JSONP formatet. JSONP har en præfiks der angiver input som argument for data selv. Navnet på dette præfiks er typisk en javascript callback funktion men det kan også være en variabel. JSONP gør brug af script-tags og dette åbner verden.
Mashups kan publicere en mængde forskellige Web syndication formater som RSS og Atom, REST og SOAP, WSRP kompatibel, blogs, Atoms til mobiltelefon. Netop fordi mashups kan blive eksponeret som REST, WSDL og JSON baserede tjenester ser de ud og føles som en rigtige SOA baseret tjenester for de udviklere der ønsker at forbruge dem mens de bliver mere af en “bag kulisserne” kerneydelse.
Mashups versus portaler
Mashups og portaler er sammenlægning teknologier men alligevel helt forskellige. En Portal samler en masse funktionalitet mens en mashup er et fragment, en “portlet”, og flere mashups kan samles i en enkelt webside. Portal er klassificeret som en traditionel web-server-model med en veldefineret strategi mens mashus er mere løst definerede “Web 2.0”-teknik. Det siges at en Portal er som en “Salatbar” mens mashup er en “smeltedigel”. Portal styre sit state gennem en event-model defineret gennem et portlet API mens mashup selv har sit interne state og benytter REST baseret CRUD arkitektoniske principper ligesom mashup bruger base standarder som XML, REST og Web Services, RSS og Atom.
Mashups
Jeg er ikke i tvivl om at mashup applikationer vil vinde indpas over de næste år. Desværre er især store virksomheder i Danmark utrolig konservative med hensyn til nye teknologier og der vil sikkert gå adskillige år inden de helt åbenlyse fordele ved mashup slår igennem. For mig er fordelene åbenlyse.
Små startup virksomheder vil kunne når deres mål hurtigt og effektivt og lade allerede indkøbt infrastruktur håndter ting som development, caching, scaling, clientstate, osv. Alle ting som Enterprise verden bruger oceaner af tid og resource på.
Utroligt at helt enkelte beslutninger kan resultere i kæmpe fordele.
By Frank Vilhelmsen - 2 tags: rest mashup - Add comment