Dag König

Flash och Web Services

Flash är ett program som jag under en längre tid verkligen har velat lära mig. Jag är mycket imponerad över saker som görs i det programmet. Tyvärr tror jag att jag aldrig kommer att få tid till det.

För några år sedan var det mycket prat om att man även skulle kunna bygga gränssnitt till affärsapplikationer i Flash. Men jag har inte snubblat över speciellt många än. Om man ändå är intresserad av att bygga sådana applikationer bör man ta en titt på Flex.

I veckan stötte jag på ett blogginlägg som väckte mitt intresse igen för Flash. Det var ett inlägg om hur man konsumerar webbtjänster i Flash. Det verkar vara superenkelt. Tänk om man fick leka med det någongång? Kolla gärna in inlägget, speciellt om du jobbar med Flash.

Consuming a Web Service with Flash

Microsoft Office 12 och Xml

Det finns fortfarande inte mycket information tillgängligt om nästa version av Microsoft Office. Men en sak är säker och det är att den inslagna vägen emot mer och mer stöd för Xml fortsätter.

Detta säger Jean Pauli, som är Senior Director of XML Arcitecture, i följande artikel.

Paoli indicated that customers can expect closer ties between server and Office desktop Microsoft products. Databases--such as the forthcoming Microsoft SQL Server 2005 and those from IBM and Oracle--will be able to save data in XML format, he said.

Men mer viktigt än att kunna spara sina dokument i xml är att kunna behandla informationen i dem, utifrån innehållet, på ett intelligent sätt. (Ofta är dagens dokument, speciellt worddokument, egentligen väldigt dumma. De är endast en stor binär klump med data.)

Office is also getting a bigger dose of XML. Upcoming versions will make it easier for people with little training to automate multistep jobs, or work flows, such as processing an insurance claim. Many of these document-driven jobs today require software programmers to write code.

In general, the work flow business is going to use a lot (of XML), and there will be more simplicity for more users because the actual document is richer.

Jag kan knappast vänta. Det finns många av mina kunder som skulle behöva de här möjligheterna.

 

Första intrycket av Microsoft Application Designer

I det här inlägget vill jag dela med mig några korta erfarenheter av att arbeta med "Application Designer" i Microsoft Visual Studio 2005, Beta 2. Observera att detta inte är en färdig produkt, vilket innebär att saker kan ha ändrats tills den verkligen släpps.

Nedan ser ni ett helt system, Lexia, beskrivet med hjälp av "Application Designer". Detta är ett system som jag håller på att bygga för att testa ett flertal SOA-lösningar i. Systemet är en internetbokhandel.

Som ni ser kan det snabbt bli lite oöverskådligt, speciellt när man jobbar på mindre skärmar. Tyvärr blir inte utskriften något bättre. Det går i dagsläget att endast skriva ut på ett sätt, vilket innebär att hela den här skissen kommer ut på ett flera sidor, som man sedan får klistra ihop.

Nedan kommer en detaljbild ifrån hela skissen.

Det är mycket lätt att börja skissa, vilket är viktigt. Jag tycker också, personligen, att skissen blir rätt snygg, speciellt de tonade boxarna med rundande hörn.

En sak som jag dock irriterade mig över när det gäller boxarna, är att både en Webbapplikation och en Webbtjänst ritas ut på exakt likadant sätt. Se Bookshop och OrderProcessService i exemplet. (Jag vet att det är samma tekniska lösning för båda typerna, men jag skulle ändå vilja kunna se skillnaden.)

När vi ändå pratar webbtjänster, så tycker jag att man skall kunna rita ut tjänster utan att behöva binda dem till en teknisk implementation, i det är fallet en webbtjänst. Teorin med DSL tycker jag om, men jag skulle nog vilja kunna vara snäppet mer abstrakt när jag skisserar systemet.

Att skapa "end points", alltså de påhängda figurerna på boxarna, är mycket enkelt. Det är också enkelt att sedan koppla ihop olika end points med varandra. Utritningen av kopplingarna sker relativt väl, men det kan ibland bli väl många "broar".

För WebServiceEndpoint kan man sedan definiera metoder och parametrar på ett enkelt sätt. Tyvärr har jag haft problem att definiera parametrar som inte är någon av de grundläggande typerna. Jag använder mig nämligen av dokumentorienterade parametrar, vilket innebär att jag har en avancerad typ, som en parameter, vilket sänder alla information. (Men jag kanske bara inte förstår hur man skall göra?)

Jag skulle också vilja ha möjligheten att rita in andra saker i skissen. Jag skulle vilja kunna ritar linjer och boxar, skriva text. Tyvärr går detta ännu inte att göra.

En spännande funktion är att man kan implementera systemet och dess tjänster genom att välja "Implement All Applications". Det gör att det skapas stubbar för alla delarna. Tyvärr verkar det inte sedan som skissen och applikationerna är synkroniserade, även om de är i samma solution. Jag kan, exempelvis inte, lägga till en metod till en webbtjänst och sedan se att den metoden har kommit upp i skissens end point. (Nu vet jag inte om det skall fungera överhuvudtaget?)

Sammanfattning
Jag kommer säkert att använda mig av det här sättet att skissera ett system. Det går fort. Tyvärr saknas vissa bitar för att göra det fullständigt. Vi får se vad som kommer att finnas i den slutgiltiga produkten.

OneNote:s flaggfunktion

Jag vet inte hur många av er som använder OneNote. Jag använder det stundom själv. Det finns flera funktioner som är rätt häftiga i det programmet.

En sak som jag inte har upptäckt förut är hur användbart flaggorna i programmet är. Inte bara att man kan skapa egna typer av flaggor, utan att man också kan få en summering över de flaggar som man har i en sektion och annat också.

Det var ett inlägg ifrån Chris Pratley som lärde mig allt detta. Är du intresserad, så surfa dit, och kolla in den.

En rolig KB ifrån Microsoft

Inte visste jag att man kunde ställa sådana här frågor till dem. Man kunde kanske också fråga varför det ibland är likadant hemma hos mig och mina gäster. Finns det någon patch?

Här är ett utdrag ur KB:n. Det fullständiga finns här.

Guests are not happy in Zoo Tycoon

SUMMARY

Guests in Microsoft Zoo Tycoon want to sit when they are tired, to buy food when they are hungry, and to use the restrooms when it is necessary. Guests become unhappy when their requirements are not met. If the buildings and objects are not conveniently located or if the buildings and objects are facing the wrong way to be accessible, the guests cannot use them. The Zoo Tycoon update prevents issues in new zoos, but it does not fix zoos that are already in use. Some third-party facilities may cause similar issues that you can fix by removing Zoo Tycoon, deleting the original folder, and then reinstalling Zoo Tycoon.

SYMPTOMS

When you are playing a game of Zoo Tycoon, you may experience the following symptoms:

•	Your guests are hungry, unhappy, and want to use the restrooms.
•	You have restaurants, snack stands, and restrooms built, but none of the guests are using them.
•	Your guests stand next to benches and picnic tables, but do not sit down even when they are tired.

Ajax och ASP.NET

Ajax är något som troligtvis kommer att röra på sig i år. Ajax står för Asynchronous JavaScript and XML och är en teknik att anropa en webbserver ifrån en webbsida utan att hela sidan behöver postas. Den här tekniken är inte alls ny. Jag skrev själv en artikel om det för över ett år sedan. Men den har ändå inte varit så känd, på grund av att den kräver rätt goda javascriptkunskaper för att man skall våga sig på det.
Varför tror jag att det kommer att röra på sig senare i år om nu tekniken har funnits en längre tid. Inom .NET-världen kommer vi med ASP.NET 2.0 få sådan här funktionalitet. Det kallas då "client callbacks". Det blir då enklare att implementera sådana här funktioner.

Vad kan man använda det till?
Det första som jag tänker på är att kunna underlätta formulärhantering i webbsidor. Där kan det bland annat användas till att uppdatera, i bakgrunden, olika fält beroende på vad användaren har skrivit in i. Användaren skriver exempelvis in Sverige och Ajax använts för att direkt hemma alla städer just i Sverige.
Ett annat sätt skulle kunna vara att rapportera, med ett popupfönster, när en ny rapport har kommit. Förfrågan om nya rapporter sker i bakgrunden utan att användaren behöver göra någonting.

Det är en spännande teknik. Det är dock viktigt att man tänker sig för innan man börjar att implementera denna, speciellt om man skall stödja flera typer av webbläsare.

Några inlägg om detta. ==1==, ==2==

Refactoring för Visual Basic 2005

En av de saker som jag verkligen skulle sakna i Visual Basic 2005 är refactoring. Men nu behöver jag inte göra det längre. Microsoft kommer att skicka med en produkt ifrån Developer Express i Visual Studio.

Refactor! for Visual Basic 2005 Beta 2 is a free plug-in from Developer Express Inc. that enables Visual Basic developers to simplify and re-structure source code, making it easier to read and less costly to maintain. Refactor! supports more than 15 individual refactoring features, including operations like Reorder Parameters, Extract Method, Encapsulate Field and Create Overload.

Det går redan nu att ladda ned en version som fungerar för Beta 2. Varsågod! 

Replikeringsmekanismer för SOA

En kollega till mig, Ulf Landgren, har skrivit en intressant artikel som jag gärna vill dela med mig till er. Det handlar om hur man skall hantera data i en SO-Arkitektur.

Varsågod Ulf:

Bl.a. problemet att göra join:ar vid SOA-arklitektur uppmärksammas ofta. Problemet har sin grund i att varje tjänst ska vara suverän och inte direkt (på annat sätt än genom meddelanden) tala med gemensamma databaser samtidigt som man vill ha separata SOA-tjänster för olika saker t.ex. order, artiklar och kunder.

En lösning är införandet av en typ av referensdata som är en sammanställning av data från flera källor. Sammanställningen är alltså mindre normaliserad. För att ajourhålla sammanställningen behövs någon form av replikeringsmekanism så att ändringar i källorna införs i sammanställningen.

Jag har funderat lite på olika sådana mekanismer. Vill renodla de olika alternativen så lång det går. Nedan är några förslag. Tacksam för kommentarer och tillägg!

När jag skrev det här första gången för någon veckor sedan frågade jag om det finns några vedertagna metoder eller standarder för detta. Jag tänkte då inte i form av produkter, men en bekant har sedan dess påpekat att olika integrationsprodukter gör just vad jag efterfrågar, men ofta med en centraliserad arkitektur. Antagligen är Microsoft Message Queuing (MSMQ) ett val man kan göra om man vill implementera mekanismerna. En standard inom området är tydligen WSA .  Där WSE är Microsofts implementation?http://www.codeproject.com/useritems/SOA_PublisherSubscriber.asp 

Scenario för nedanstående mekanismer

Man har en SOA-tjänst A som är informationsägare av data i en databas i A och ett antal B1, B2, B3 etc. som är prenumeranter och som håller egna kopior på information från databasen i A (och antagligen från andra källor.)
Endast A äger rätt att ändra databasen. B:na håller kopior på information i A:s databas.

1. Push-mekanism

A ansvarar för att B:na är uppdaterade. Vid varje ändring skickar A ut ett ändringsmeddelanden med all information nödvändig om ändringen till B:na. Ändringsmeddelandet innehåller alla ändrade rader (id på borttagna rader) och databasens versionsnummer (som stegas upp för varje ändring). B:na svara med ett kvitteringsmeddelande som innehåller versionsnumret. B:na köar internt upp inkomna ändringsmeddelanden och behandlar dem i nummerordning. (Ex. så behandlas inte meddelande 18 förrän meddelande 17 tagits emot och behandlats.) A skickar om meddelanden som inte kvitterats inom en viss tid. A håller en lista på alla utestående ändringsmeddelanden d.v.s. meddelanden som prenumeranter inte kvitterat.

Variant: A skickar inte ändringsmeddelanden med en gång utan skickar ut dem t.ex. en gång per dygn eller tidigare om tillräckligt många ändringar har ackumulerats.

Variant: Publisher Subscriber-modellen. D.v.s. B sätter själv upp sig som prenumerant på ändringar från A. Om A ska acceptera nya prenumeranter så måste a spara eller kunna återskapa gamla ändringsmeddelanden.

2. Pull-mekanism

B:na ansvarar var och en för att hålla sina databaser i synk med A:s. När varje B finner det lämpligt så frågar den A efter uppdateringar. A sparar ändringsmeddelanden som B:na kan hämta. B skickar meddelande till A när B:t lyckats uppdatera till en ny version. A behöver inte spara ändringsmeddelanden efter det att alla prenumeranter har uppdaterat. (Förutsatt att man inte ska stödja att nya B:n kommer till.)

3. Cache-mekanism (form av Pull)

B:na cashar posterna i sin databas. B hämtar posterna från A om de inte finns i B:s egen databas. Om de finns där så frågar B A om det finns en nyare variant (versionsnummer för databasposten). A svara antingen nej eller ja + ny data. Svarar A nej så använder B data från sin egen databas, Svara A ja så används data från A och så läggs det in i B:s cache (databas).

4. Blandade modeller

Förutom de mer renodlade modellerna där A eller B:na ansvarar för att B:na är uppdaterad kan man tänka sig att de delar ansvaret. T.ex. kan B ansvara för att varje gång som B går online meddela A detta och sedan är det A som push ar ut ändringarna till B.

/Ulf

Tetris regerar på mobiltelefonen

Jag gillar enkla spel mer och mer, även om jag fortfarande kan fastna i ett RPG ibland. Mobiltelefonen börjar äntligen bli en plattform där man kan hitta sådana här enkla spel. BBC har en intressant artikel om vilka spel som är mest populära och vilka som inte verkar att funka på en mobiltelefon. Det verkar bland annat som porteringar av konsolspel inte funkar speciellt bra. Det är en annan målgrupp som spelar dem och dessa spelare har mer tid och är intresserade av att hålla på länge.

Att Tetris är en favorit kan man förstå. Läs vidare här.

Är Wsdl och Xsd det bästa sättet att beskriva en SOA-tjänst?

[Ursäkta det långa inlägget.]

Enligt tekniken "Contract First" skall man beskriva kontraktet på en tjänst innan man implementerar denna. (Detta kallas också top-down.) Rekommendation för att beskriva dessa kontrakt brukar ofta Wsdl och Xsd. (Jag har själv gjort detta ett flertal gånger.) Men min fundering är om det egentligen är det bästa sättet?

Nackdelar
* Wsdl och Xsd är svårt att jobba med om man skall skriva den själv.
* Det finns inga bra produkter än så länge som hjälper utvecklarna på ett effektivt sätt hjälper till med Xsd och Wsdl. Det finns vissa produkter som är duktiga på att göra en viss del, men ingen som klarar av helheten.
* Wsdl och Xsd är hårt knutna till Webbtjänster, vilket inte alltid är bra.

Fördelar
* Är en standard.
* Är textbaserat.
* Flera leverantörer har stöd för att generera kod ifrån Xsd och Wsdl.

En tjänst, alltså en SOA-tjänst, inte en webbtjänst, har inga tekniska krav kopplade till sig. SOA är ett sätt att strukturera en organisations systemlandskap. Hur tjänsten sedan implementeras är en helt annan fråga. De två viktigaste aspekterna vid implementation av en tjänst är: 1) Hur den skall kommunicera 2) I vilken miljö som den skall köras.

Hur skall den kommunicera
Den främsta kommunikationstypen som idag framhålls är webbtjänster. (Detta av flera goda skäl. Men om man likställer SOA och webbtjänster kan man låsa in sig i ett hörn, där man egentligen inte behöver vara.) Men det kan också vara CORBA, COM/DCOM eller någon form av meddelandebaserat system. (Det finns flera andra.)
Kommunikationen brukar också delas upp i synkron respektive asynkron överföring.

I vilken miljö som tjänsten exekveras
Om man bygger webbtjänster med .NET så exekveras webbtjänsten inuti ASP.NET. Men det är inte den enda miljön, eller motorn, som kan användas. Det kan exempelvis vara i någon applikationsserver eller liknande.

Dessa båda saker brukar kallas "Service Bus" och kan på ett sätt efterlikna en hårdvarubus i en dator. Det viktiga här är att se att vi aldrig kommer att få en Service Bus som endast består av en teknik för kommunikation och exekveringsmiljö. Vi bör ha en Service Bus som är mer generell och som ger oss möjligheten att koppla in nya typer.

Hur ser en tjänst ut ifrån detta perspektiv?
För det första skall egentligen inte en tjänst innehålla någon kodning för kommunikationen. Den läggs på utanför själva tjänsten som stubbar. Dessa stubbar kan man skriva själv eller, och som är bäst, få hjälp med det på något sätt. Ett vanligt sätt idag är att använda sig av kodgeneratorer, vilka genererar stubbarna. Om man använder sig av Wsdl och Xsd, tillsammans med .NET, finns det program som skapar dessa stubbar så att det går att anropa tjänsterna med hjälp av webbtjänster. (Det finns liknande system inom Java.)
Kommunikationssättet och exekveringsmiljön påverkar varandra. Viss typ av kommunikation är bättre lämpad i viss exekveringsmiljö. En annan viktig fråga när det gäller exekveringsmiljö är hur typ säkerhet fungerar. Hur för man exempelvis över ett "context" mellan DCOM/COM och en webbtjänst?

Varför kan det vara problem att använda Wsdl och Xsd för definiering av kontraktet?
Wsdl och Xsd använts uteslutande, gäller speciellt Wsdl, för att beskriva webbtjänster i dagsläget. Det innebär att det "generella" språket att beskriva kontrakt tyvärr pekar emot en speciell typ av teknisk implementering.

Vad kan vi göra istället?
Både MDA (Modell Driven Architecture) och "Software Factories" diskuterar att beskriva dessa kontrakt på en ändå mer generell nivå. MDA förordar att man använder UML, medan "Software Factories" lutar sig mer på Mircrosofts Visual Studio Team Systems (DSL - Domain Specific Languages) sätt att beskriva.
Båda dessa system tror jag redan idag har stöd för att generera Wsdl-filer. (Jag har inte kunnat verifiera detta, men tror att det är så.)

Hur skulle det så ut om vi gjorde på det här sättet?
* Vi skulle använda ett grafiskt verktyg för att definiera tjänsterna, dess metoder och meddelanden. Sättet att beskriva datatyperna måste klara av allt som Xsd kan. (Där tror jag att UML har en begränsning. Jag vet inte heller om Microsofts DSL-initiativ har denna funktionalitet?) Beskrivningen av datatyperna måste klara av att hantera olika namespaces och också hanteringen av generella typer, vilka återanvänts på flera ställen.
* Denna grafiska modell skall generera Xsd-filer. Dessa filer skall kunna läggas i biblioteksstrukturer som är möjliga att själv bestämma. Vidare skall de olika Xsd-filerna länkas samman, genom (<xsd:include> och <xsd:import>) på ett bra sätt.
* Wsdl-filerna skall också skapas utifrån den grafiska modellen.
* Både modellen och filerna skall vara synkroniserade med varandra. Det innebär att vare sig man ändrar i modellen eller i någon av filerna skall det omedelbart och automatiskt synkroniseras med varandra.
* Eventuellt skall också kodgenereringen kunna skötas av systemet.

Avslutning
Det här är endast några funderingar som jag har. Jag har inte riktigt tänkt färdigt. Det innebär att jag kommer att använda mig av Xsd och Wsdl tills jag hittar något bättre, vilket jag inte kan se finns idag.
När man diskutera kontrakt hamnar man ofta i den här delen av kontraktet, alltså hur man beskriver det mer formella gränssnittet. Ett kontrakt innehåller mycket mer. Men detta kommer jag att ta upp i ett annat inlägg.