Business to business (B2B) communication - Integrering av system

Transkript

1 Business to business (B2B) communication - Integrering av system Jonas Liinamaa 20 november 2003 Department of Computer Science Åbo Akademi University, FIN Åbo, Finland jliinama@abo. URL: 1

2 Sammanfattning Denna uppsats berättar om olika alternativ till traditionella Electronic Data Interchange (EDI) baserade lösningar för kommunikation mellan olika aärssystem. Den problematik som är förknippad med kommunikationen mellan en diversitet av olika system förklaras samt analyseras. Moderna teknologier som XML, SOAP samt WebServices presenteras både i teorin samt genom exempel. 2

3 Classication: ACM classication: C.2.2 Network Protocols ACM classication: C.2.4 Distributed Systems ACM classication: C.2.6 Internetworking ACM classication: D.2.12 Interoperability ACM Special Interest Groups: SIGCOMM ACM Special Interest Groups: SIGSOFT 3

4 Innehåll 1 Grundläggande problematik vid B2B kommunikation Olika system är implementerade med olika teknologier Öppen källkod eller kommersiell produkt Traditionella lösningar Socketbaserad kommunikation RPC CORBA Kommunikation baserad på öppna standarder Drivande krafter samt fördelar HTTP XML SOAP WebServices Implementation av kommunikation mellan system 14 4

5 1 Grundläggande problematik vid B2B kommunikation En vid diversitet av system måste kunna kommunicera med varandra. Detta är ett grundläggande krav vid kommunikation mellan olika system, men inte alltid lätt att genomföra. Svårigheter uppstår till exempel av att olika system är implementerade vid olika tidsepoker, varje epok har haft olika teknologier som har varit hype, och därmed har implementationen också baserat sig på den teknologin. Mjukvara skrivet på olika tidsåldrar varierar därmed i implementationsspråk samt tankesätt från sekventiella- till objektorienterade språk. Hur ska man kunna hitta gemensama kommunikationsformer för denna mängd helt olika system? 1.1 Olika system är implementerade med olika teknologier Olika teknologier är ej nödvändigtvis skapade för att kunna kommunicera med andra system implementerade i andra teknologier, i sådana fall måste man hitta ett sätt att kringgå dessa begränsningar vid kommunikationen. Betrakta till exempel ett scenario var ett gammalt system hanterar data som ett nytt system behöver tillgång till. Det gamla systemet är implementerat i ett funktionellt språk som inte har understöd för TCP/IP baserad kommunikation. Systemet har understöd för ett annat nätverksprotokoll, X25. Det gamla systemet arbetar mot en databas som ej har blivit utvecklad eller underhållen på era år, därav nns det ej heller något understöd för den nya applikationen att accessera databasen direkt. 1.2 Öppen källkod eller kommersiell produkt System med källkoden tillgänglig ger utvecklaren en möjlighet att utveckla lösningar för datakommunikationen direkt i applikationen, medan ett system vars källkod man ej har tillgång till kräver andra lösningar, ibland till och med hårdvarubaserade lösningar. I system vars källkod man har tillgång till så kan man genom att utveckla adaptrar som omvandlar data från en intern representation av datan till ett annat generellt format, kommunicera mellan totalt olika system. Adaptern omvandlar data från applikationen till det generella, specierade formatet som förstås av båda parternas adaptrar. Det mottagande systemet tar emot meddelandet i det generella formatet och omvandlar meddelandets data till det mottagande systemets interna representation av datan. I system vars källkod man ej har tillgång till kan man oftast ej använda sig av det ovan beskrivna Adapter design-mönstret. Det krävs att systemet har någon form av gränssnitt som möjliggör en utvidgning av systements normala kommunikationsrutiner för att man skall kunna använda sig av Adapter mönstret. I annat fall är man tvingad till att bygga ett mellanliggande 5

6 system som kan utvinna datan ur det existerande systemet i en form eller annan, och via detta mellanliggande system sedan överföra informationen vidare till det mottagande systemet. Ett exempel på en sådan lösning skulle vara en schemalagd rutin som dumpar datan ur den bakomliggande databasen till text format och sedan omvandlar denna data till en generell representation som det mottagande systemet förstår. 6

7 2 Traditionella lösningar Traditionellt sett så har kommunikations lösningar baserat sig på binära protokoll med vars hjälp man antingen har överfört data eller också anropat rutiner direkt på det mottagande systemet med den data som skall överföras. Dessa lösningar fungerar bra så länge det är relativt likadana system som kommunicerar, speciellt om dessa system är implementerade med samma teknologi, samt om de är sammanlänkade med ett pålitligt samt snabbt transportmedium, till exempel ett lokalt nätverk. Ett problem med dessa metoder är att data överföringen sker binärt genom komplicerade strukturer samt en strikt grammatik. Detta kan även ställa till med problem vid integration med ny teknologi, för om överföringen är enligt ett binärt och oftast slutet protokoll så krävs det en implementation av tolken för denna grammatik till den nya teknologin. Ifall det använda protokollet är underhållet och vidareutvecklat så har det med stor sannolikhet skrivits en adapter för protokollet till den nya teknologin, men oftast är specikationerna för dessa protokoll kommersiella och kostar stora summor vilket betyder att en tolk även kostar mycket. Ifall teknologin har förtvinat och om inga specikationer över protokollet nnas mera tillgängligt så är situationen katastrofal med avseende för framtida utveckling. Dessa protokoll för dataöverföring samt anrop av funktionalitet på externa system följer vanligtvis en client-server modell. 2.1 Socketbaserad kommunikation Socketbaserad kommunikation följer en vanlig Client-server modell. En klient tar kontakt med en server och sänder ett meddelande till servern som tolkar det samt eventuellt sänder ett svarsmeddelande. Denna kommunikation sker vanligtvis över TCP/IP baserade nätverk samt är kompatibel med de esta operativsystem samt programmeringsspråk. Ett vanligtvis eget denerat protokoll anger vad olika delar av meddelandet innebär samt hur meddelandet skall tolkas. Detta protokoll är vanligtvis ej standardiserat utan parterna i datakommunikationen har själva denerat protokollet. Om protokollet är dåligt dokumenterat blir vidareutveckling samt vidare integration med andra system svårt. Protokollens låga nivå på meddelanden som överförs ställer begränsningar på den funktionalitet man kan erbjuda med socket-kommunikation. Transaktioner över era anrop blir omöjliga att hantera, även tillståndshanteringen i applikationerna kan bli komplex. Då applikationen vidareutvecklas och aärslogiken sväller så stiger komplexitetsgraden för meddelandehanteringen mångfallt, det krävs en stor mängd kod för att utföra mera komplicerade anrop över sockets. Det nns till exempel ingen automatisk hantering eller markering av varken klientens eller serverns bitordning, detta måste beaktas samt byggas in i det egna protokollet. Den låga nivån dessa meddelanden hanteras på ger dock en bra prestanda så länge man 7

8 inte utvecklar alltför komplexa meddelandestrukturer som kräver mycket processering samt tunga bakomliggande operationer. Socket-kommunikation är mest lämpad för överföring av strömmar med data över ett snabbt och tillförlitligt nätverk. 2.2 RPC Remote Procedure Calls (RPC)[RPC-S1995] kan programmatiskt ses som vanliga funktionsanrop, dock med en stor skillnad dold bakom gränssnittet. Funktionsanropen riktas mot en server som utför funktionen samt eventuellt returnerar ett resultat. Anropen följer en clientserver modell samt är traditionellt synkrona, även om specikationerna lämnar möjligheten öppen för asynkron kommunikation. Faktumt att klienten väntar på svar från servern förrän exekveringen fortskrider ställer krav på nätverket som förbinder klienten samt servern. Implementationer användande RPC-protokollet har som hjälpmedel extended Data Representation (XDR) för att automatiskt transformera (marshall / de-marshall) information till och från en representation som lämpar sig för att sändas över nätverket. Med hjälp av detta deneras gränssnitten för kommunikationen.[ms2000] RPC erbjuder en abstraktion från den låga nivå som dataöverföringen sker på samt erbjuder utveklaren ett enklare tankesätt helt i linje med lokala funktionsanrop. Protokollet är dock relativt gammalt och utvecklingen av distribuerade arkitekturer har framskridit. 2.3 CORBA Common Object Request Broker Architecture (CORBA)[OMG] denerar en standard för distribuerade objektbaserade applikationer som tillåter kommunikation mellan komponenter oberoende av operativsystem, maskinarkitektur eller implementeringspråk. CORBA är ett massivt skelett (framework) som erbjuder ett objektorienterat system olika tjänster genom denerade gränssnitt. Abstraktionsnivån för utvecklaren är på en hög nivå vilket underlättar utvidgning av olika tjänster. Tjänsternas gränssnitt besrivs med Interface Denition Language (IDL), detta medför att gränssnitten är denerade på ett programmeringsspråksoberoende sätt. Fördelen med det är att parterna som medverkar i kommunikationen mellan system har väldokumenterade gränssnitt att utveckla klienter emot. IDL tillåter förutom att kompileras till skelett även en tolkning av gränssnitten i realtid, det vill säga att fastän gränsnittet har ändrat så kan applikationen dynamiskt anpassa sig till situationen. För att använda en CORBA-baserade tjänst så behöver man ej nödvändigtvis veta på vilken server objektet existerar, en Object Request Broker tar hand om förfrågningen och vid behov dirigerar anropet vidare. Komponenter kan existera utspridda över era servrar, med andra ord distribuerade. Komponenter kan även registrera sig till en tjänst som erbjuder ett register över tjänsterna som nns i systemet. 8

9 Som ett exempel på CORBA:s tillämpningar kan GNOME nämnas. Man kan säga att GNOME:s ryggrad bildas av CORBA. 9

10 3 Kommunikation baserad på öppna standarder 3.1 Drivande krafter samt fördelar Dataöverföring mellan en ospecierad mängd av system som potentiellt är implementerade med olika teknologier käver standardisering av protokollen samt de meddelanden som överförs. En öppen standard av reglerna samt meddelanden som överförs i ett läsbart samt öppet format är förutom enkelt att läsa för människan, utvecklaren även enkel att bearbeta för datorn. Dessa meddelanden är dessutom läsbara i framtiden eftersom meddelanden är överförda i klartext som motsats till binära protokoll samt binära meddelanden. Fördelen med meddelanden som överförs i klartext istället för i binärt format kan illustreras med hur svårt det är vara att öppna och få ut information ur en l som har blivit skapat för femton år sedan med ett program som varit populärt då. Först måste man försöka få tillgång till applikationen som kan läsa len, sedan måste applikationen kunna läsa samt tolka len med rätt version av l-formatet. Detta kan jämföras med enkelheten i att öppna och läsa en l i text-format som inte är i binärt fomat. Meddelanden som sänds i klartext ger med andra ord en garanti för att dessa meddelanden kan läsas samt tolkas även i framtiden. Dataöverföringen mellan system har således antagit en högre abstraktions nivå jämfört med binära protokoll. Överföringen av meddelanden tar vanligtvis inte längre ställning till varken transportprotokoll eller bitordningar vid överförseln av meddelanden, de meddelanden som utbytes behandlas på ett maskinoberoende samt språkoberoende sätt på en högre nivå än binära protokoll. 3.2 HTTP Protokollet HTTP[RFC 2616] bildar grunden för dagens informationsforum, Internet. Protokollet denerar en simpel modell för interaktion mellan klient och server genom begreppen request samt response. Arbetet på HTTP protokollet startades 1991 men den versionen kunde ändast beskriva ett fåtal dokument samt inget annat än HTML. Protokollet utvecklades enkom för att kunna publicera HTML dokument över internet. Från version 0.9 har HTTP i dagens läge mognat till version 1.1. Den nya standarden innehåller förbättringar bland annat angående eektiviteten av dataöverförsel samt utvidningar av olika cache-kontrollerande headers. I dagens läge används HTTP-protokollet till vitt åtskillda saker: transport av HTML sidor, kommunikation mellan system samt till och med till tunnling av andra protokoll. 10

11 3.3 XML Extensible Markup Language (XML)[XML] är en standardisering av dokument och dess struktur, även kallat XML-dokument. XML kan kallas ett metaspråk därför att det är en uppsättning av standardiserade regler som beskriver hur ett XML-dokument ser ut och vad det består av. Ett XML-dokuments regler deneras i en Document Type Denition (DTD) som även används för att validera XML-dokumentet, detta innebär att XML-dokument kontrolleras för korrekthet vilket ger en viss garanti för att XML-dokumentet är korrekt. Även XML scheman [XML schema] kan användas istället för DTDn, ett schema kan i motsats till en DTD även speciera regler om ett elements data och datans form samt typ. XML är en delmängd av Standard Generalized Markup Language (SGML)[SGML] och gemensamt har de struktur, korrekthet samt utvidgningsbarhet. XML är dock betydligt simplare än SGML, vilket också var ett av design målen. XML är kompatibel med SGML samt HTML. XML utvecklades redan under år 1996 av W3C:s XML working group, men dess genomslag har kommit först under slutet av 1990-talet då J2EE samt kommunikation mellan olika system blev vardag. De drivande krafterna bakom utvecklandet av XML var att få en standard för informationsutbyte över internet samt andra vitt åtskillda system, till exempel distribuerade system utspridda över ett stort nätverk. XML var även svaret på det ökande behovet av ett utvidgat HTML-språk, HTML var och är ett språk för att presentera information för människor, inte för andra system eller processer. Designmålen för XML krävde att språket skulle vara exibelt samt icke komplext i motsats till SGML.Till designmålen hör även kravet att XML skulle vara i klartext i motsats till binärt format, detta för att det är enklare att modiera, läsa samt bearbeta information i klartext både nu och i framtiden. XML denerar med andra ord ett metaspråk som används för att representera data. Det verkar ju användbart för kommunikation mellan olika system. 3.4 SOAP Simple Object Access Protocol (SOAP) [SOAP] erbjuder en simpel och lätt mekanism för utbyte av strukturerad samt typad information mellan parter i en distribuerad omgivning. Protokollet är baserat på XML, alla meddelanden är XML kodade. Protokollet specierar dock inte hur datan ska transporteras, utan använder sig av dentliga protokoll som transportmedel. Protokollet består av tre delar: ett skal som denerar vad som nns i meddelandet samt hur det ska processeras, regler för hur applikationsspecika datatyper, eller objekt, uttrycks i meddelandet samt en konvention för hur man representerar RPC-anrop samt dess returvärden. 11

12 Detta medför att SOAP kan användas både för meddelandeöverföring samt för RPC anrop, det vill säga att anropa metoder i externa system och returneras resultat från anropen. SOAP använder sig vanligtvis av HTTP(S) för transport av meddelanden mellan parterna men även andra protokoll är möjliga. SOAP utnyttjar HTTP-protokollets request - response modell på ett naturligt sätt. I likhet med XML så är SOAP designad med simplicitet samt utvidgningsbarhet i baktanke. Självklart är SOAP plattformsoberoende samt språkoberoende, helt i linje med XML. Exempel på ett SOAP request över HTTP: POST /StockQuote HTTP/1.1 Host: Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:soap-env=" SOAP-ENV:encodingStyle=" <SOAP-ENV:Body> <m:getlasttradepricedetailed xmlns:m="some- URI"> <Symbol>DEF</Symbol> <Company>DEF Corp</Company> <Price>34.1</Price> </m:getlasttradepricedetailed> </SOAP-ENV:Body> </SOAP-ENV:Envelope> TODO : WebServices Webbtjänster (Web Services) [] binder samman en stor mängd lösa teknologier och är i processen att få en standard till stånd. En webbtjänst denierar ett gränssnitt för sina tjänster genom vilket klienter kan nå de metoder som denieras. Metoderna kan ha parametrar och returnera svarsresultat, precis som vid anrop av vanliga metoder eller anrop med RPC. Enda skillnaden är att anropen görs över Internet och med SOAP som budbärare. 12

13 Webtjänstens gränssnitt deneras med hjälp av Web Services Description Language (WS- DL) [WSDL] som beskriver de tillgängliga tjänsterna samt dess parametrar. WSDL erbjuder en utvidgningsbar mekanism för att denera grundläggande parametrar samt metadata gällande webtjänsten. WSDL beskriver tjänsten på ett abstrakt sätt vilket inte tar ställning till transportprotokoll och liknande. WDSL kan beskrivas som ett XML-språk som beskriver tjänster som en mängd kommunikations-ändpunkter, eller portar, kapabla att utbyta meddelanden. WDSL är fortfarande i utkast-stadiet (Working draft in development), men redan nns det en viss koncensus angående standarden. Det nns dock ett par saker att uppmärksamma avgående Webbtjänster. Det nns ej än någon standard över hur transaktioner skall skötas över Web Services, detta innebär att de tjänster som erbjuds i form av Web Services bör vara tillståndslösa (stateless). Det nns ej heller någon standard än över hur autentikering samt kryptering ska ske över Web Services, detta innebär att det kommer att nnas en djungel av olika implementationer. 13

14 4 Implementation av kommunikation mellan system Den grundläggande frågan att ställa vid design av system som skall kommunicera med andra system samt eventuellt använda tjänster från andra system är, den nästan klassiska frågan, vad vill vi uppnå? Om vi designar ett system som ej ska kommunicera med era än ett specikt system, som även det är designat enkom för ändamålet, samt om den kommunikation som försegår emellan systemen är simpel så klarar man sig bra med socket-baserad kommunikation. Om man däremot designar ett större system med komplexa datastrukturer samt komplicerad logik så erbjuder SOAP eller Web Services fördelar i form av ökad återanvändbarheten av koden, enklare logik eftersom koden som skrivs är väldigt specialiserad samt en sund grund varifrån det är enkelt att vidareutveckla samt underhålla systemet. Web Services har understöd av stora företag som till exempel Oracle, Microsoft, IBM samt Sun. En ytterligare fördel med Web Services är att dess arkitektur påtvingar en sund objektorienterad design samt en ren implementation av systemet. Låt oss ta en fallstudie av vad som krävs vid designen av ett system som använder sig av Web Services för att tillåta kommunikation med andra system. Vi önskar ett system som ska tillåta förfrågningar av dagens pris på en produkt. Klienterna som utför förfrågningen är implementerade i en mängd olika språk. Som implementations språk för tjänsten har Java blivit valt, vi kommer alltså att designa ett J2EE-system för att hantera den logik som krävs av tjänsten. Vi designar systemet att vara tillståndslöst, vi använder Stateless-EJBn som erbjuder de grundläggande tjänsterna inom systemet som till exempel auktorisering, data hämtning samt systemets logik. En facade i formen av en Stateless-EJB representerar applikationen, den dirigerar och koordinerar logiken i applikationen. Vad uppmärksammar vi då? Jo, att vi har ett system som vi enkelt kan använda genom ett Web-interface, en thin-client eller via Web Services. För att erbjuda tillgång till applikationen via Web Services så är det ända som krävs att vi implementerar ett gränssnitt på vår facade (eller på en annan facade som använder sig av vår facade). 14

15 Referenser [IETF] Internet Engineering Task Force (IETF), [RPC-S1995] RPC: Remote Procedure Call protocol specication version 2, R.Srinivasan, Sun Microsystems, August 1995, RFC [MS2000] Professional Linux Programming, N. Matthew, R. Stones, WROX [OMG] CORBA [RFC 2616] RFC 2616: Hypertext Transfer Protocol HTTP/1.1, ftp://ftp.isi.edu/innotes/rfc2616.txt [XML] Extensible Markup Language, [SGML] SGML ISO8879 [XML schema] XML schema, [SOAP] SOAP, [Web Services] Web Services, [WSDL] WSDL,