Som i de seneste år, at begrebet SOA og relaterede teknologier fremme udviklingen af standarder, SOA efterhånden accepteret af mange brugere, og i e-forvaltning og virksomhedsapplikationer, der bygger gradvist. Men med mange forskelligartede og komplekse SOA-relaterede tekniske standarder, IT-virksomheder i udviklingen af SOA-relaterede software products og kunder vælger at implement SOA, they ofte kunne ikke fortælle, hvilke tekniske standarder er, hvad de har brug for, og en betydelig del af SOA tekniske standarder positionering, der er en vis overlapning. Derfor er valget for SOA-relaterede tekniske standarder, som IT-virksomheder og gennemførelse af SOA-brugere har problemer. Nedenfor en kort del af SOA-relaterede tekniske standarder, og at foretage en simpel analyse.
1. SOA-relaterede tekniske standarder for klassificering
Standarder og normer lignende, men lidt anderledes, er den foreslåede standard er en standard dokument. Standarder, der generelt anerkendt af branchen standardiseringsorganer til at udarbejde og offentliggøre, og standard med flere udbydere eller standarder organisation for frigivelse. Denne artikel skelner ikke mellem dem, der kaldes standard uniform. Der er mange SOA-relaterede tekniske standarder for klassificering, papiret beskriver to.
1,1. Klassificering 1
En fremgangsmåde er at være opdelt i tre kategorier, nemlig standard sæt XML, webtjenester og SOA Reference Model standard sæt:
l XML standard sæt
Omfatte to typer, den ene tekst-baseret kodning, XML Information Set, XML Schema, XML Query og XSLT 2,0 og så videre. Den anden er at give uigennemsigtig binære data med traditionelle tekst-baserede kodningsteknikker sammen med tags. Optimal indkapsling protokoller såsom binær XML (XML-binary Optimeret Packaging, XOP), SOAP besked optimering (Transmission Optimization Metode, MTOM) og så videre.
XML-standarden, der er en top bidragyder til SOA udvikling, de fleste af dem er udviklet af W3C organisationen, og har været en række softwareleverandører og brugere til at støtte og bruge, såsom hvorvidt eller Java lejr. NET-lejren, samt andre softwareudvikling teknologi, for det meste til at give XML-standarden sæt værktøjer. SOA er ikke kun en standard sæt XML-data beskrivelse og behandling for de bedste varemærke, er det den anden SOA-relaterede tekniske standarder, såsom en webtjeneste standarder, er baseret på XML til at beskrive.
l webtjeneste standarder
Sæt Web Services standarder har taget form, der dækker transport lag, besked system, programmering model, service opdagelse og beskrivelse, pålidelighed, transaktionsbehandling, sikkerhed og ledelse. Såsom WSDL beskrivelse for den semantiske webtjenester, at WS-Policy beskrive Web service kapaciteter og strategier, WS-Security, SAML og andre webtjenester beskrive de relevante sikkerhedskrav, og så videre. I øjeblikket er de fleste webservices standarder fastsat af OASIS organisation, og nogle webtjenester standarder er ikke perfekt, bliver udviklet.
l SOA Reference Model
SOA udvikling tidligt, at forskellige leverandører fremme SOA referencemodel er forskellige, med de tekniske standarder i forbindelse med udviklingen af forståelsen af den gradvise harmonisering af de forskellige producenter. På nuværende tidspunkt har OASIS udviklet en reference model for SOA SOA-RM1.0 specifikation, det giver en helt abstrakt ramme, der bruges til at forstå den abstrakte SOA ramme for avanceret teknologi, serviceorienteret miljø i en vigtig måde at konvergens, er den standard ensartet af de vigtige udvikling trin for trin, og en service til støtte for detaljeret specifikation. SOA reference arkitektur, kan virksomheden SOA give en samlet plan skal være den overordnede ramme for de overordnede retningslinjer, men ikke i den virkelige gennemførelse af SOA til at give specifikke praktiske råd for.
Selv om SOA Reference Model allerede har den anbefalede standarder, men standarder organisationer og fabrikanter i SOA reference arkitektur, der ikke er ensartet.
1,2. Klassificering 2
SOA-relaterede tekniske standarder til en anden metode for klassificering er baseret på tekniske standarder i SOA's rolle og funktion, vil blive opdelt i tre hovedkategorier: service-niveau informationsudveksling standard, baseret på kommunikation standarder, metadata-standarder. Ifølge forskellige standarder og normer i rollen som SOA-systemer kan opdeles i syv lag SOA stack, vist i figur 1. Nedefra, herunder transport lag, besked lag, præsentation lag, ledelse, service sammensætning lag, det lag, der ud over ebXML og e-handel-relaterede tekniske standarder (som f.eks ressource registrering ebRS, siger kilder ebMS, arrangement af den eksterne tjeneste ressourcer WS-CDL osv.), de fleste i landet har været betydelige applikationer, såsom East gennem anvendelse af teknologi integration og applikationsserver produkter TongIntegrator TongWeb, webtjenester støtte nogle af de relevante tekniske standarder. Transport Layer protokol som traditionelle, i SOA-teknologi gennemførelse, fortsætter med at spille en vigtig rolle; information lag har en webtjeneste SOAP meddelelsestransmission vektor af forbrugernes valgmuligheder; Web Service Description standard WSDL, men ikke i det semantiske beskrivelse af perfekt, men at det har været overvældende flertal af producenter og brugere accepterer og brug i forvaltningen af relevante tekniske standarder, er også under udvikling, indenlandske praktiske anvendelser fortsat ikke fælles sikkerheds-krav, såsom WS-Security, pålidelige transmission krav såsom WS-Reliability, brugere og producenter er begyndt at overveje at bruge; service sammensætning lag, der er allerede mange kommercielle og open source organisationer, der bygger på BPEL standard at udvikle en Business Process Management software; sagde lag standarder såsom JSR168 og WSRP , hovedsageligt til Portal Software.
Figur 1.SOA protokol stack hierarki
2. SOA-relaterede tekniske standarder for sammenligning viser
Fordi alt for mange SOA-relaterede tekniske standarder, gjorde figur 1, og ikke fuldt ud en liste over alle de SOA-relaterede tekniske standarder. Nu på den del af SOA-relaterede standarder, der svarer sammenligning viser, at for SOA udvikling, der kan vælges baseret på forståelse af viden.
2,1. WSDL og OWL-S
W3C standarder organisationer Web Services Description Language WSDL, dens niveau fra syntaktiske funktioner Web Service Description, herunder 4 forskellige størrelse: datatypen (datatype), message (Message), metode (Operation), og adgang port (PortType). Dette er kun at give en webtjeneste interface beskrivelse, adfærd tjenester attributter beskrive de begrænsninger og manglen på yderligere støtte.
OWL-S er en semantisk markup sprog til webtjenester standarder, det er bedre end den WSDL service at tilbyde brugerne forståelig beskrivelser af ressourcer i form af anbefalinger til at forbedre nøjagtigheden af udvælgelses-og service. Semantisk Web Services ontologi vigtigste metode er at bruge til at beskrive webtjeneste, så beskrivelsen af semantisk information med webtjenester for at opnå service indset automatisk opdagelse, påkaldelse og sammensætning. Semantisk web og semantisk web-tjenester, webtjenester er de to store støtter teknologi. OWL-S er en bro, der forbinder de to teknologier, det nuværende Semantiske Web Services Markup Language er den vigtigste organisation DARPA organisation, fremlagde sit forskergruppe OWL Services Coalition Semantiske Web Services Markup Language OWL-S (original DAML-S).
Semantisk web-tjenester og dermed forbundne standarder (OWL-S, etc.) for web-og webtjenester applikationer, uddybning af stor betydning, men også har gode muligheder for udvikling. Den nuværende OWL-S semantisk web service-relaterede standarder såsom programmet stadig primært forskning, eksemplarisk.
2,2. XML Web Services og ebXML
SOA i den service, de nuværende Web Services-teknologi til at opnå mere og fortolkning af de traditionelle webtjenester og related aftaler er baseret på XML som grundlag for ekspansion, så vi kaldte det XML webtjeneste. Faktisk, før XML Web Services, har ebXML opstået betragtning af kompleksiteten og forbedre denne standard, så det er i den traditionelle området elektronisk handel, brug bredere. På specifikt indhold og placering, er de to helt forskellige.
1) meddelelsestransmission teknologi
XML Web Services og ebXML bruger SOAP som meddelelsestransmission teknologi, XML Web Services, men definitionen af løst koblede tjenester protokol stack, stakken af pålidelig transmission (WS-Reliability) og sikkerhed (WS-Security) sammensætningen af de forskellige specifikationer, og ebXML alle disse funktioner i deres egne messaging standarder og ebMS ind for at bruge hybridteknologi.
2) Beskrivelsen af den tjeneste og opdagelse
XML Web Services ved hjælp af WSDL og UDDI standarder, henholdsvis er UDDI registreringssystem baseret på den mappe arkitektur, herunder registrering af tekniske modeller og forretningsmodeller, kan deres registrering forlænges, men det er ikke nok indhold og beskrivelse af en rig og fuldstændige, figur 3 UDDI datamodellen og diagram.
Den ebXML service beskrivelse og opdagelse mekanismer vil svare til de to standarder, en for registreringsoplysninger model ebRIM, to er et registreret service specifikation ebRS. ebXML UDDI registrering mekanisme til at berige og perfekt end den mere omfattende brug af sit registreringssystem, der kan repræsentere en bred vifte af data genstande, herunder xml model, business process beskrivelser, ebXML Core Component, UML model, generel handelspartner information og software gruppe stykker. At støtte en sådan række af data ved hjælp af en veldefineret information model snarere end i kataloget, vil ebXML Registry designet til at være mere som en database, Figur 2 for ebXML oplysninger i registreringsdatabasen model ebRIM organisationsplanen.
3) business process samarbejde
Web-baseret samarbejde og business proces tjenester, service orkestrering, der WS4BPEL, WS-CDL, XPDL workflow baseret på XML, osv., som er baseret på XML og webtjenester standarder er forholdsvis uafhængige af hinanden, eller endda forskellige organisationer til at udvikle.
ebXML standarder omfatter kollaborative business process standarder, såsom ebCPPA, ebBPPS.
Kort sagt, ebXML er en uafhængig standard sæt funktioner en indre sammenhæng, og ikke afhængig af nye standarder og normer, og dens brug Zhuyao positionering 电子商务 i en særlig anmodning, på nuværende tidspunkt, har ebXML Pi bestemt som GB anbefales, Ansøgningen skal se efter et stykke vej at gå. Den XML Web service på grund af dets relativt simple og let teknologi, en protokol stack, der svarer til den koblede relativt løst, så anvendelsen af SOA i opbygningen af mere og mere udbredt.
Figur 2.ebXML registreringsoplysninger model (ebRIM)
Figur 3.UDDI graf datamodel og dens
2,3. SCA / SDO og JBI / JDO
SCA (Service Component Architecture), at den service komponentarkitektur giver en programmeringsmodel, der kan understøtte implementering af applikationer baseret på SOA. SCA er en model, der kan understøtte opnåelsen af service komponenter teknologier, for at tilslutte diverse adgang metode service komponenter. For komponenter. Herunder ikke blot forskellige programmeringssprog, herunder anvendelse af rammerne for disse sprog og miljø SCA syntese proces for at få adgang metoder til at støtte en bred vifte af kommunikations-, service adgang teknologier, såsom: WS, MQ, RPC. SCA specifikationer herunder Saml Model og Client Model af to dele. Den tidligere aftalte, hvordan heterogene komponenter (Java klasse, BPEL, Web Service) samles og frigøres i SOA-tjenester, den største træk er SCA og centralt begreb, sidstnævnte er enige om, hvordan man kalder i heterogene sprogmiljø SOA service. Disse to dele af specifikationen, kan vi løse hele service fra service til kunden inter-sprog, på tværs af miljø. Figur 4 SCA service komponenter til samling model.
Service Data Objects (SDO) er designet til at samle og forenkle den måde ansøgninger håndtere data, så brug SDO, anvendelsen programmører kan bruge den samme metode i driften af heterogene datakilder, herunder relationelle databaser, XML datakilder, webtjenester og virksomhed informationssystemer.
JBI er Java Business Integration (Java Business Integration) for korte. JBI's beslutningstagere mener, at de traditionelle EAI og B2B-løsninger ved hjælp af ikke-standard-teknologi, som giver brugerne mulighed tendens til at være låst til en bestemt program og produkt-udbydere, samtidig er der ingen enkelt udbyder, og kan dække EAI B2B-området af alle problemerne. Så de rejste standard med henblik på at løse dette problem. Denne standard definerer en standard arkitektur giver tredjepart komponenter i infrastrukturen på standard, og selv om disse komponenter har forskellige udbydere, kan de også være en slags forudsigelig og pålidelig måde til hinanden operation. Fra højt niveau perspektiv definerer JBI plugin-komponenter kan være fremstillet af det integrerede system arkitektur, til interaktive elementer i denne struktur via brug en besked-systemet til udveksling og udveksling af meddelelser model er baseret på WSDL 2,0 eller WSDL 1,1 af. Figur 5 viser sammensætningen og strukturen af JBI miljø.
Figur 4.SCA Service Component samling model
Figur 5.JBI sammensætning og struktur af miljøet
JDO, reddede Java Data Object, der definerer klasser og JDO vedholdenhed forholdet mellem runtime environment. JDO er designet til at blive brugt bredt til at støtte forskellige data-kilder, selv generelt ikke anses for at være kilden til databasen. Så bruger vi "datalagring" (Datastore) at få adgang udtrykket refererer til den underliggende datakilde JDO.
På grundlag af ovenstående analyse af mening / SCA SDO definerer en bestemt teknologi og relaterede tjenester komponent montage model og adgang til data struktur mellem tjenester på den måde, SCA's holdning, hovedsagelig finkornet komponenter og tjenesteydelser bestilt. SCA / SDO for teknisk uafhængighed og deltagelse af mange virksomheder, de har støtte fra de fleste producenter. Den JBI / JDO, som er baseret på Java teknologi, JBI busforbindelse mere som Java standard definition, dens størrelse end SCA, og at mere kommunikation mellem service og montage transportformer, JDO er en Java-baseret dataobjekter, at så de bruger den begrænsede rækkevidde af den nuværende støtte fra mainstream fabrikanter er ikke mange, men stadig forholdsvis åben source implementering af en relativt mere.
2,4. WS4BPEL og WS-CDL
WS4BPEL, Web Service Business Process Execution Language for korte, Web Services Business Process Execution Language, der er en eksekverbar sprog, lette automatisering af forretningsprocesser med en række af edb-systemerne kompatible. Web-tjenester, etablering, ved hjælp af illustrative (ikke programmatisk) gav udtryk for efterspørgslen efter webtjenesten sammensætning. Denne standard er hovedsageligt bruges til Business Process Management inden for organisationen og service orkestrering, BPM produktet i øjeblikket stigende erkendelse baseret på denne specifikation.
WS-CDL, Web Services Koreografi Definition Language, Web service orkestrering definition sprog, der er defineret som antallet af formelle forbindelser mellem handelspartnere, kræver det ikke alle, der skal integreres endpoint (endpoints) har en web-tjenester infrastruktur. Denne specifikation mere for tjenester uden for organisationen og processen planlægning, er ikke almindeligt anvendt nu i landet.
Desuden kan XPDL anvendes for tjenester, planlægning og kombination, men det er hovedsageligt anvendes i traditionelle workflow definition, nu er det også vigtigt at opnå BPM produkt tekniske standarder.
2,5. JSR168 og WSRP
JSR168 er java specifikationer (java specifikation anmodning, JSR) forkortelsen for etablering af standarder for etablering af portlet'en api, det er at opnå porltet, java-baseret web portal servere og andre interoperabilitet mellem applikationer udviklet. JSR168 vigtigste værdi er, at det er uafhængige softwareleverandører (ISV) er meget udbredt. Forud for vedtagelsen af JSR168, erhvervspolitik applikationsudviklere nødt til at støtte alle de forskellige portlet-udviklere at indstille portalen til at understøtte multiple portal portlet andet sæt udviklere i lignende forretningsoplysninger, content management, hentning og analyse af sådanne områder er meget hovedpine. Brug JST168 specifikation, som nu støtter en portlet udviklere behøver kun at indstille. I øjeblikket JSR168 Portal baseret på Java-teknologi udvikling produkter har fået stor opbakning, men begrænset til Java-teknologi.
WSRP, Web Services for Remote Portlets akronym, der definerer, hvordan man bruger SOAP-baserede webtjenester anvendelse i portalen for at generere mærket fragmenter af specifikationen. Ved at definere et sæt fælles grænseflader, giver WSRP portaler at vise den side i deres distance løb portlet, portal udviklere uden programmering. For slutbrugeren er de disse porlet på og kører i deres lokale portaler på samme, men i virkeligheden kører en fjern portlet fra portlet'en container, og samspillet er gennem udveksling af SOAP-beskeder for at opnå. I en serviceorienteret arkitektur med WSRP vil være en stærk kombination, således at portlet'en for den foreliggende begæring kan findes til genbrug uden yderligere udvikling og implementering aktiviteter. Udviklet af OASIS WSRP organisation har modtaget støtte fra de fleste producenter i betragtning af det er baseret på webtjenester standarder og teknologi uafhængigt, så med en gradvis forbedring af denne standard, jeg tror mere og mere fremstillingsvirksomheder Portal vil støtte denne standard.
3. Resumé
SOA på den del af den tidligere sammenlignende analyse af de relevante tekniske standarder, kan ikke dække alle de SOA-relaterede tekniske standarder, såsom SOA reference arkitektur, Web services stakken sammenligning analyse. Formålet med denne artikel, håber at håbe at forstå de tekniske standarder og SOA-teknisk standarder valg, som sammenblandingen af udviklere, softwareleverandører og brugere osv. til at give nogle reference med henblik på at fungere som en stimulans.