NO20003652L - Utvidbart og distribuert system for applikasjons-integrering for bedrifter - Google Patents

Description

Oppfinnelsens fagfelt

Foreliggende oppfinnelse angår generelt det som har blitt kjent som «mellomvare» (eng. middleware), og mer spesifikt et utvidbart distribuert system og fremgangsmåter for å anvende disse for å integrere applikasjoner av typen som vanligvis anvendes i en bedrift med et datanettverk.

Tidligere teknikk

Ifølge en observatør, dersom blodet for dagens forretninger er informasjon, er deres arterier «interapplikasjons-grensesnittene», som forenkler det å sende av data rundt omkring i forretningsbedriften. Dette har i det senere blitt kjent som et «applikasjonsnettverk».

For den typiske organisasjon har applikasjonsnettverket vokst til en samling av ad-hoc programmer for applikasjons-integrering. Dette menasjeriet har hatt en sterk innflytelse på forretningene idet det øker tiden det tar å implementere nye applikasjoner, forhindrer den øverste ledelsen fra å få en klar oversikt over bedriften og, kort sagt, tetter forretningens arterier. Til tross for det faktum at applikasjonsintegrasjon har blitt vital for den konkurrerende bedrifts overlevelse, har det ikke desto mindre i den tidligere teknikk vært akseptert å tråkle, eller «hacke» inn spesialtilpasset kode for slike formål. Dette medfører enorme kostnader for bedriften i et langsiktig perspektiv. Likeledes har langsiktige avgjørelser vedrørende applikasjons-integrering blitt tatt på lavest mulig nivå og kun basert på kriterier for det enkelte prosjekt. På grunn av den definitivt vanskelige naturen til slike problemer, er det enda ikke funnet en effektiv applikasjons-integrering for bedrifter (EAI).

Fremveksten av Internett, klient/tjener applikasjoner, fusjonering av og nyerhvervelser i bedrifter, globalisering og omorganisering av forretningsprosesser, har sammen tvunget informasjonsteknologi (IT)-avdelinger i bedrifter til kontinuerlig å finne frem til nye, og ofte manuelle, måter å få forskjellige systemer til å snakke med hverandre — uavhengig av hvor gamle noen av disse systemene måtte være. I det resulterende kaoset har inadekvate kommunikasjonssystemer hatt en svekkende effekt på IT-ens muligheter til å utvikle seg så fort som forretningene trenger at den gjør.

Nyere trender innenfor IT har kun forsterket dette problemet ved å øke -- ofte med en størrelsesorden — mengden av nødvendige grensesnitt mellom applikasjoner for å støtte dem. I det aller siste har bedriftsapplikasjoner utført slike funksjoner som drift av datavarehus og bedriftsressursplanlegging (ERP) og forenklet elektronisk handel. En kort gjennomgang av disse tre teknologiene vil derfor være til hjelp til å forstå det lenge følte, men enda uløste, behovet for

EAI.

Teknikker for drift av datavarehus krever at store volumer av rene historiedata flyttes, på regulær basis, fra mange operasjonelle systemer til varehuset. Kildedataene er vanligvis strukturert for on-line transaksjonsprosessering (OLTP), mens det typiske datavarehus også har støtte for data formattert for on-line analyseprosessering (OLAP). Derfor må kildedataene gjennomgå en utstrakt mellomlagring og omformattering mens de sendes til varehuset.

Et typisk datavarehus ifølge tidligere teknikk fylles i fire trinn: (a) ekstrahering av kildedataene; (b) rydding av slike data; (c) lagring av de ryddede, ekstraherte dataene i et antall dimensjoner; og (d) oppfylling av varehuset. Hver varehuskilde krever at det bygges en spesifikk data ekstraherings-, ryddings-, lagrings- og oppfyllingsrutine. Forrester Research estimerer at en middels stor bedrift har omtrent fire datavarehus. Om to år er det ventet at dette tallet vil øke til seks. Den gjennomsnittlige mengden av data inneholdt i hvert datavarehus er også forventet å bli fordoblet i den samme perioden - fra omtrent 130 gigabyte til omtrent 260 gigabyte.

Problemene assosiert med slike store mengder data som vokser med en stadig økende rate forsterkes av dårlig kvalitet på kildedataene. Ifølge et studium gjennomført av META-gruppen, lastes et typisk datavarehus opp med omkring 20% data av dårlig kvalitet. Det samme studiet indikerer at omtrent 70% av dets respondenter anvendte ekstraherings-, ryddings- og lastingsprosesser som var kodet for hånd. Med hensyn på de nødvendige aggregeringsprosessene, avslører anekdotiske beviser at det kan være nødvendig med så mye som 50 timers databeregningstid for å gjennomføre denne funksjonen alene. Det er åpenbart at det vil kreve betydelige ressurser å vedlikeholde programmer skrevet på denne måten.

På den annen side er typiske ERP systemer (så som R/3 bedriftsapplikasjonen utviklet av SAP AG i Walldorf, Tyskland, så vel som de utviklet av PeopleSoft, Oracle og Baan) essensielt store, integrerte pakkede applikasjoner som støtter kjerne-forretningsfunksjoner, så som lønningslister, fremstilling, generell bokføring og menneskelige ressurser. Store bedrifter finner det spesielt attraktivt å kjøpe slike programvareløsninger fra én enkelt kilde, siden det kan koste mellom 10 og 20 ganger mer å utvikle den samme funksjonaliteten selv enn å kjøpe den. Å implementere et ERP system kan imidlertid av mange grunner være en enorm prosess.

Først og fremst kjøper bedrifter et produkt, og bygger ikke en løsning. Dette betyr at forretningsenheter innenfor bedriften må tilpasse seg produktet og hvordan det virker, og ikke omvendt. Videre kan ikke dagens ERP systemer erstatte alle spesialtilpassede løsninger i en bedrift. De må, derfor, kommunisere effektivt med eksisterende systemer. Til sist er det ikke uvanlig for en bedrift å anvende mer enn ett og fullstendig forskjellig ERP system fordi en enkelt forhandler kan vanligvis ikke dekke alle organisasjonsmessige behov.

Som et resultat utelukker mulighetene for å transportere data inn og ut av et ERP system kjente metoder anvendt for drift av datavarehus. Hvert ERP system har sin egen datamodell som kontinuerlig forbedres av produsenten. Det å skrive ekstraherings-, eller opplastingsrutiner som manipulerer slike modeller er ikke bare komplisert, men frarådes også av produsenten siden det er sannsynlig at en omgår datavalidiseringen og forretningsreglene som følger med bedriftsapplikasjonen. I stedet krever ERP-systemene interaksjonen på forretningsobjekt-nivå som håndterer spesifikke forretningsenheter så som generell bokholding, budsjetter eller kontoer som skal betales. Ytterligere detaljer angående implementasjon og anvendelse av et velkjent og ålment akseptert ERP system kan finnes i Special Edition Usina SAP R/ 3 (andre utgave), ISBN: 0-7897-1351-9, ved Que Corporation (1997).

Elektronisk handel i en eller annen form har funnet sted i mange år. Den fikk essensielt sin start med elektronisk datautveksling (EDI). EDI tillot bedrifter å kommunisere sine kjøpsordre og regninger elektronisk, og forsatte og utvikles slik at dagens bedrifter benytter EDI for styring av leverandørkjeden. Ikke før den senere eksplosive bruk av on-line websider for å kjøpe, selge og til og med auksjonere bort, interessante produkter har det imidlertid vært et slik skrikende behov for robust og effektiv EAI. Se f.eks. U.S. patentet 5,627,972.

Applikasjoner utvikles for å oppnå et spesifikt forretningsmål innenfor en gitt tidsramme. I en vanlig stor organisasjon utvikler typisk forskjellige lag med mennesker, som benytter et bredt spekter av operativsystemer, DBMS-er og utviklingsverktøy, hundrevis av applikasjoner. I hvert tilfelle tilfredsstilles de spesifikke kravene uten tanke på integrasjon med andre applikasjoner.

Mange viktige faktorer driver markedet for applikasjonsintegrasjon. For eksempel har betydelige utviklinger innen peer-til-peer nettverksdrift og distribuert prosessering gjort det mulig for bedrifter bedre å integrere deres egne funksjonelle avdelinger så vel som å integrere med deres partnere og leverandører. Den ovennevnte eksplosive økningen i lnternett/«intranett»/«ekstranett» øker også etterspørselen etter en ny klasse av «menneske-aktive» applikasjoner som krever integrasjon med eksisterende bakliggende (eng. back-end) applikasjoner. Den enorme veksten over hele verden i bruken av programvarepakker for bedriftsapplikasjoner (f.eks. SAP R/3) krever også integrasjon med eksisterende bakliggende applikasjoner. Til slutt har meldingsorientert mellomvare (MOM) - produkter så som IBM<*>s MQSeries køsystem for meldinger - blitt mer og mer populært. Når kundene oppdager fordelene med en enkel en-til-en applikasjonskonnektivitet med MOM, øker deres interesse for mange-til-mange applikasjonsintegrasjon betydelig.

Mens forretningenes behov for integrasjon øker, øker antallet IT-kroner som anvendes til applikasjonsintegrasjon raskt. Ifølge forskjellige industrianalytikere vil behovet for integrasjon av «oppdragskritiske» applikasjoner gi det kombinerte markedet for MOM og «meldingsformidlere» en vekst fra 2,7 milliarder kroner ($300 millioner) i 1997 til over 6300 milliarder ($700 millioner) i 1999. Ifølge en IBM undersøkelse av store kunder, består nærmere 70% av all kode som skrives i dag av grensesnitt, protokoller og andre fremgangsmåter for å etablere linker mellom forskjellige systemer. IT sjefer som ønsker å senke kostnadene kan klart se besparelsene som kan oppnås ved å finne raskt tilgjengelig programvare som tilfredsstiller så mye av dette kravet som mulig.

En meldingsformidler er en programvare-hubb som lagrer og styrer kontraktene mellom de som publiserer (dvs. sendere) og abonnenter (dvs. mottakere) av meldinger. Når det finner sted en forretningshendelse, vil applikasjonen publisere meldingen(e) som svarer til den forretningshendelsen. Formidleren går gjennom sin liste over abonnenter og aktiverer levering til hver abonnent for den typen meldinger. Abonnenter mottar kun de dataene de abonnerer på. En melding publisert av en applikasjon kan abonneres på av flere abonnenter. Tilsvarende kan en applikasjon abonnere på meldinger fra mange publiserende applikasjoner.

Før applikasjoner kan publisere eller abonnere på meldinger må de melde sin interesse for meldingsformidleren. Det er to grunnleggende og forskjellige måter for applikasjoner å registrere sin interesse for en type meldinger - emnebasert adressering og meldingsinnhold-filtrering. Ved emnebasert adressering anvender formidleren emnet for å identifisere og rute meldingen til alle som har meldt sin interesse for det emnet. Emnet er et ord som anvendes for å beskrive meldingens innhold. For eksempel kan et emne med innholdet «hr. ans. ny», benyttes til å distribuere informasjon (f.eks. navn, adresse, ansatt nr., etc.) om en nyansatt. Ved ruting basert på meldingens innhold på den annen side, abonneres det på grunnlag av innholdet i felter i meldingen. Abonnering kan baseres på typen melding og/eller spesifikke utvalgskriterier med hensyn på et felt innen meldingen. For eksempel kan en låneinnvilgingsapplikasjon abonnere på alle kjøpsordre på mer enn 900 000 kr ($100000).

En fordel med å ha to publiserings-/abonneringsparadigmer er at en unngår behovet for å adressere meldinger til individuelle abonnerende applikasjoner. I tillegg kan nye abonnerende applikasjoner legges til uten at det foretas endringer av den publiserende applikasjonen.

Den typiske publiserings-/abonnerings-formidleren anvender en robust leveringsmotor for den faktiske distribusjonen av meldinger mellom applikasjoner. Da oppdragskritiske meldinger sendes over en kombinasjon av eksterne og interne nettverk, sikrer systemprogramvaren at meldinger aldri tapes eller dupliseres ved sammenbrudd i nettverket. Mer regelen enn unntaket er at det forefinnes en asynkron meldingsleveringsanordning som anvender lagre-og-videresend meldingskøing. I denne paradigmen foregår kø-til-kø overføringen i kvasi sanntid når den abonnerende applikasjonen er tilgjengelig. Dersom den abonnerende applikasjonen ikke er tilgjengelig, lagres meldingen i en persistent kø for å bli levert senere.

For å være virkningsfull må motoren for meldingslevering inkludere en koordineringsfunksjon for forretningstransaksjoner. En forretningstransaksjon utgjøres vanligvis av mange arbeidsenheter. Hver og en av arbeidsenhetene må fullføre for at transaksjonen skal skje. Selv om bare én arbeidsenhet ikke fullfører, gjennomføres ikke transaksjonen, og alle arbeidsenheter som har fullført må da reverseres. Disse transaksjonene bruker lang tid og krever meldingsbaserte oppdateringer av mange databaser. Koordineringsfunksjonen for forretningstransaksjoner utfører denne styringsfunksjonen.

To andre viktige komponenter er den regelbaserte motoren og komponenten for datatransformasjon. Forretningsregel-motoren gjør det mulig for organisasjoner å prosessere meldinger basert på de unike kravene fra deres forretning. Forretningsregel-motorer frembringer typisk et visuelt frontgrensesnitt for å unngå å innføre behov for programmering i et prosedyreorientert språk. Med denne fleksible fremgangsmåten kan endringer i forretningsprosesser enkelt reflekteres i en modifisert regelkonfigurasjon.

Datatransformasjonskomponenten anvendes for å utvikle applikasjonsspesifikke adaptere. Disse adaptrene konverterer dataformatene og applikasjonssemantikken fra avsenderapplikasjonen til mottakerapplikasjonen. Det er mange krav til denne konverteringen. Disse varierer fra transformasjon av grunnleggende data til å løse inkompabilitetene som finnes mellom strukturen (dvs. syntaksen), betydningen (dvs. semantikken) og klokking av informasjonen som må deles.

Det er to hovedstrategier for applikasjonsadaptere ifølge tidligere teknikk. En strategi er å konvertere alle kildedataene og synkronisere (eller «synke») applikasjonene til en standard kanonisk form. Meldinger sendes fra kildeadapteren til synkadapteren på denne standard formen. Ved synkadapteren konverteres meldingene til synkapplikasjonens format.

Den andre strategien for applikasjonsadaptere er å automatisk konvertere formatet og semantikken fra avsenderapplikasjonen og mottakerapplikasjonen i et trinn, uten å anvende mellomformater. Ved denne fremgangsmåten er det kun nødvendig med én adapter for at to applikasjoner skal kunne kommunisere med hverandre og den kan integreres med hvilken som helst av applikasjonene.

Den regelbaserte motoren og datatransformasjonskomponenten samarbeider for å avstemme forskjellen mellom applikasjonene. Før, for eksempel, to applikasjoner kan integreres rundt en ordre, må forretningsreglene angående prosesseringen av ordre være definert i hvert system. Innenfor applikasjon «A» kan en ordre være sammensatt av en samling data fra mange filer og databaser; mens innen applikasjon «B» kan en ordre eksistere som en individuell melding lokalisert i en lang fil med forretningstransaksjoner. Den vanskelige utfordringen er å løse inkompabilitetene mellom struktureringen av data og det underliggende innholdet av en ordre som definert innen hver applikasjon.

Meldingsformidling frembringer et antall potensielle forretningsfordeler. Først og fremst den enkle applikasjons-integreringen. Med meldingsformidlere kan integrasjonen av nye applikasjoner med eksisterende egne eller tredjehåndsapplikasjoner utføres på kortere tid. Integrasjonen kan gjøres uten at det er behov for å forstå den interne strukturen og designet av hver applikasjon. Ved å fokusere på grensesnittet som meldinger, kan eksisterende applikasjoner integreres med minimalt inngrep.

Støtte for elektronisk handel er en andre fordel som frembringes av meldingsformidling. Når forretninger begynner å automatisere varetilførselskjeden fra sine leverandører og partnere, er det et behov for at deres uavhengige applikasjoner skal kunne kommunisere på en løst koplet måte. Dette er eksakt essensen og styrken ved meldingsformidling. Meldingsformidleren kongruerer fullstendig med forretningsbehovet.

Sist, men definitivt ikke minst, er meldingsformidlingens støtte for fortsatt heterogenitet. Mens ny teknologi utvikles, er det utviklet nye arkitekturer og heterogeniteten øker med tiden. En metodologi så som meldingsformidling er laget for å imøtekomme dagens heterogenne verden og vil være nyttig i fremtiden. Nye, forskjellige applikasjoner kan legges til over tid som enten publiserere eller abonnenter, uten endringer på de eksisterende applikasjonene i meldingsformidleren.

Som et sammendrag har meldingsformidlere potensiale til å frembringe en minste fellesnevner-fremgangsmåte for integrasjon av heterogene applikasjoner innenfor en bedrift. Brukere kan velge den beste teknologien for hver individuelle applikasjon enten det er Java® (registrert varemerke fra Sun Microsystems Inc., Mountain View, California, USA), Active X®(et registrert varemerke fra Microsoft Corporation, Redmond, Washington, USA) eller CORBA® (et registrert varemerke fra Object Management Group, Inc., Framingham, Massachusetts, USA), uten bekymring for hvordan den applikasjonen vil integrere med andre applikasjoner i foretaket. Meldingsformidlere bygger med dette en bro over kløften mellom fremtidens applikasjoner og de vesensforskjellige og komplekse produktene og teknologiene som nå eksisterer i dagens applikasjonskataloger.

Selv om det er mange fordeler ved å benytte en

meldingsformidlingsstrategi, må en huske på at det også et potensielle feller. Den store styrken for meldingsformidling med hensyn til fleksibiliteten ved den løse koplingen, kan også være dens største svakhet. Programvare for meldingsformidling, som angitt ovenfor, er veldig generalisert. Fordi den er konstruert for å håndtere så mange forskjellige forhold, er en fullstendig testing av alle mulige ende-til-ende kodegrener nærmest umulig. Dersom det eksisterer uoppdagede feil i programvaren, kan meldinger bli mistet, sendt flere ganger eller forsinket. Skaden ved slike «uhell» vil være størst i bedrifter hvor meldingsformidlerne anvendes for å integrere oppdragskritiske transaksjonsprosesserende applikasjoner. Ved finansielle transaksjoner, for

eksempel, kan leveringen av en enkelt melding være verdt millioner av kroner, mens på den annen side tap eller forsinkelse av denne meldingen kan resultere i milliontap.

En andre risiko ved implementasjon av en meldingsformidler er muligheten for at uvedkommende applikasjoner kan introdusere uautoriserte meldinger for formidleren. Dette kan også resultere i tap. Foreksempel kan det i bankindustrien publiseres falske meldinger som fører til uttak fra eller underslag av kontoer.

En tredje risiko ved implementasjon av en meldingsformidling er den klassiske, «enkeltpunktsfeil». Meldingsformidlere ifølge tidligere teknikk er vanligvis implementert i en «hub and spoke» arkitektur. Dette betyr at hoveddelen av meldingstrafikken passerer gjennom noen få sentrale hubber. En midlertidig stans av eller en fysisk skade på en av disse hubbene, kan gjøre at gjennomføringen av oppdragskritiske operasjoner for en bedrift går i stå.

Et annet problem med distribuerte hubber er vanskeligheten med å styre meldingsformidlerkomplekset. Fordi en meldingsformidler integrerer så mange forskjellige forretningsapplikasjoner til noen få konsoliderte hubber, kan det være umulig å få tak i den nødvendige kompetanse og ekspertise for å styre meldingsformidlerkomplekset.

Den potensielle eksponering for risiko er alltid stor når teknologi anvendes for prosessering av oppdragskritiske transaksjoner innen et foretak. Et problem for meldingformidling er at den manipulerer oppdragskritisk informasjon. Relativt sett er meldingsformidling nokså nytt. Selv om noen bedrifter som tidlig begynte med meldingsformidling har hatt stor suksess med dette, er det imidlertid mye mer som trengs før meldingsformidlere og EAI kan bli vanlig blant bedrifter.

På 1980-tallet fokuserte utviklingen av programvaresystemer på muligheten for heterogene systemer til å kommunisere med hverandre. Dette var, i hovedsak, på grunn av fremveksten av interne kommunikasjonsprotokoller. Ethvert nyutviklet system måtte enten være kompatibelt med den applikasjonen og de dataformatene som eksisterte for de systemene det skulle forbinde seg til eller kommunisere med, eller det måtte frembringe en slik applikasjonsspesifikk oversettelse. All programvare var derfor i en mer eller mindre grad spesialtilpasset.

I dagens raskt endrende miljøer fokuserer tusenvis av utviklere over hele verden på å utvikle et system som tilfredsstiller det behovet som vesensforskjellige applikasjoner har for å kommunisere med hverandre, uten at det er nødvendig å integrere mange spesialtilpassede applikasjonsspesifikke oversettingsskjemaer. Dette foreløpig ikke dekkede behovet har sitt opphav i kravene fra den globale økonomien.

Oppsummering av oppfinnelsen

Sett i lys av det ovennevnte er det et generelt mål ved foreliggende oppfinnelse å frembringe systemer og fremgangsmåter for å integrere bedriftsapplikasjoner, som samtidig frembringer omfattende styring av slike bedriftsapplikasjoner, inklusive sentralisert overvåking, operasjon og konfigurasjon.

Det er et mer spesifikt mål ved foreliggende oppfinnelse å frembringe en agent-adapter arkitektur og et meldings-skjema som sammen forbedrer meldingssporing og -manipulasjon i slike systemer og fremgangsmåter.

Et annet mål ved foreliggende oppfinnelse er i slike systemer og fremgangsmåter å frembringe forbedrede sikkerhetsmuligheter, inklusive slike aspekter som autentifikasjon, autorisasjon, privathet, ikke-awisning og revisjon.

Nok et mål ved foreliggende oppfinnelse er å frembringe systemer og fremgangsmåter for integrasjon av bedriftsapplikasjoner som inkluderer anordninger for sammenbruddsgjenvinning, feilsikker overrulling, meldingsendring og to-steds logging.

Det er også et generelt mål for foreliggende oppfinnelse å forenkle hurtig og enkel integrasjon av ledende ERP-applikasjoner,

spesialtilpassede/gjenbrukte applikasjoner, pakkede applikasjoner og databaser. Mer spesifikt er det også et mål for foreliggende oppfinnelse å redusere eller i hovedsak eliminere behovet for kostbar spesialkoding som tradisjonelt er nødvendig for å integrere applikasjoner.

Et annet mål ved foreliggende oppfinnelse er å frembringe et EAI-system med en distribuert arkitektur som forenkler påliteligheten, skalabiliteten, fleksibiliteten og utvidbarheten på lang sikt, hvilket er nødvendig for dagens bedrifter.

Nok et mål ved foreliggende oppfinnelse er å frembringe et EAI-system som øker en bedrifts tilbakebetaling for investeringen ved å gjøre at bedriften kan balansere sine eksisterende IT investeringer, øke sin hastighet ut til markedet, implementere løsninger og realisere fordeler hurtigere og redusere sine operasjonskostnader.

Et ytterligere mål ved foreliggende oppfinnelse er å frembringe et EAI-system som gir raskere aksess til en bedrifts kunde- og faktureringsinformasjon slik at bedriften kan betjene sine kunder mer virkningsfullt og effektivt samt opprette sterkere og mer effektive relasjoner.

Et videre mål ved foreliggende oppfinnelse er å frembringe et AEI system med mange-til-mange integrasjonspunkter som i stor grad eliminerer ulempene ved konvensjonelle hub-and-spoke systemer og deres risiko for enkeltpunktssammenbrudd.

Nok et videre mål ved foreliggende oppfinnelse er å frembringe et EAI-system som forenkler en bedrifts IT-arkitektur ved å frembringe et sentralt integrasjonspunkt for så godt som alle applikasjoner og plattformer.

Enda et videre mål ved foreliggende oppfinnelse er å frembringe et EAI-system som gir en effektiv og kostnadsbesparende informasjonsdeling.

Fremgangsmåtene, apparatene og fremstillingsartiklene beskrevet her vil oppnå de ovennevnte og andre mål, fordeler og nye egenskaper ifølge foreliggende oppfinnelse, samtidig som de unngår problemene beskrevet ovenfor.

Ifølge et viktig aspekt ved foreliggende oppfinnelse omfatter

fremgangsmåten datamaskin-implementerte anordninger for å sende meldinger mellom en første datamaskin-applikasjon og en andre datamaskin-applikasjon. Fremgangsmåten inkluderer generelt trinnene med å: (a) frembringe en første melding med en første datastruktur fra den første datamaskin-applikasjonen; (b) publisere den første meldingen for å oppnå en første publisert melding; (c) konvertere den første datastrukturen i den første publiserte meldingen til en andre datastruktur for å oppnå en andre melding; (d) publisere den andre

meldingen for å oppnå en andre publisert melding; og (e) sende den andre publiserte meldingen til den andre datamaskin-applikasjonen.

Ifølge et annet viktig aspekt ved foreliggende oppfinnelse omfatter apparatet et system for å integrere et mangfold datamaskin-applikasjoner. Apparatet inkluderer generelt anordninger for å rute meldinger innen systemet; anordninger for å lagre et mangfold datatransformasjons-konfigurasjoner og et mangfold regler; anordninger for å anvende datatransformasjons-konfigurasjonene på meldinger; anordninger for å anvende reglene på meldinger; og anordninger for å rute meldinger mellom anordningene for å rute meldinger innen systemet og datamaskin-applikasjonene, og som har dedikerte anordninger for å rute meldinger for respektive datamaskin-applikasjoner.

Alternativt omfatter apparatet ifølge foreliggende oppfinnelse et system for å integrere et mangfold datamaskin-applikasjoner. Systemet omfatter generelt et meldingssystem for bedriter som sender meldinger mellom datamaskin-applikasjoner; et database-lagringssystem, koplet til bedrifts-meldingssystemet, som lagrer et mangfold datatransformasjons-konfigurasjoner og et mangfold regler; en integrasjonstjeneste, også koplet til bedrifts-meldingssystemet, som omfatter en datatransformeringsmotor som anvender datatransformasjons-konfigurasjonene som er lagret i database-lagringssystemet og en regelevalueringsmotor som anvender reglene som er lagret i database-lagringssystemet; og et mangfold agent-adaptere, videre koplet til bedrifts-meldingssystemet med hver agent-adapter koplet til en respektiv blant datamaskin-applikasjonene for å sende meldinger mellom bedrifts-meldingssystemet og den respektive datamaskin-applikasjonen.

Ifølge nok et viktig aspekt ved foreliggende oppfinnelse omfatter fremstillingsartikkelen et datamaskin-lesbart medium som inneholder kodesegmenter for å integrere et mangfold datamaskin-applikasjoner. Ikke-begrensende eksempler på et slikt «datamaskin-lesbart medium» i denne henseende inkluderer enhver: magnet-harddisk; diskett; optisk disk, (f.eks et CD-ROM, et CD-R, et CD-RW, eller enhver disk som er kompatibel med kjente DVD-standarder); magnet-optisk disk; magnetbånd; minnechip; bærebølge som anvendes for å bære datamaskin-lesbare elektroniske data, så som de som anvendes for å sende og motta e-mail eller når en aksesserer et nettverk, inklusive Internett, intranett, extranett, virtuelle private nettverk (VPN), lokale nettverk (LAN), og nettverk over større områder (WAN); eller enhver annen lagringsanordning som anvendes for å lagre data som kan aksesseres av en datamaskin. Ikke-begrensende eksempler på slike «kodesegmenter» inkluderer ikke bare segmenter av kildekode og segmenter av objektkode, men også dataprogrammer skrevet i ethvert språk, instruksjoner, objekter, programvare eller enhver anordning for å styre en datamaskin. Slike kodesegmenter inkluderer generelt: (a) et første kodesegment for å sende meldinger mellom datamaskin-applikasjonene; (b) et andre kodesegment for å utføre datatransformering i meldinger; (c) et tredje kodesegment for å anvende regler på meldinger; og (d) et mangfold fjerde kodesegmenter som hvert sender meldinger mellom de respektive datamaskin-applikasjonene og det første kodesegmentet.

Ifølge nok et viktig aspekt ved foreliggende oppfinnelse er systemene og fremgangsmåtene rettet mot en datamaskin. Ikke-begrensende eksempler på «datamaskin» inkluderer enhver: vanlig allbruks datamaskin; prosessorkort;

PC; nettleser; e-mail klient; e-mail tjener; nettverksfil eller meldingstjener; Internett anordning; trådløs telefon; sideleser (eng. pager); personlig digital assistent (PDA); faksmaskin; digitalt stillbilde- eller videokamera; digital lyd-eller bildeopptaker; digital kopimaskin eller scanner; interaktivt fjernsyn; hybridkombinasjoner av de ovennevnte beregningsanordninger og et interaktivt fjernsyn; eller ethvert annet apparat som omfatter en prosessor, et minne og mulighet for å ta imot inndata og å generere utdata.

Andre nye og like viktige aspekter ved foreliggende oppfinnelse vil fremgå klarere av den detaljerte beskrivelse av denne sett i sammenheng med de følgende figurer hvor:

Kort beskrivelse av figurene

Figur 1(a) viser et bedriftsapplikasjon-integrerings (EAI) -system ifølge foreliggende oppfinnelse, idet det er inkorporert i et miljø som inkluderer tidligere systemer, pakkede programvareapplikasjoner og systemer for styring av relasjonsdatabaser;

Figur 1(b) illustrerer et første tilfelle hvor systemet fra figur 1(a) anvendes for å integrere en bedriftsressursplanleggings (ERP) pakket programvareapplikasjon med eksisterende spesialtilpassede systemer; Figur 1 (c) illustrerer et andre tilfelle hvor systemet som er vist i figur 1 (a) anvendes for å integrere to eller flere totalt forskjellige ERP pakkede programvareapplikasjoner; Figur 1(d) illustrerer et tredje tilfelle hvor systemet som er vist i figur 1(a) anvendes for å integrere en eller flere front-ende (eng. front-office) pakkede programvareapplikasjoner med en eller flere bakliggende (eng. back-office) pakkede programvareapplikasjoner; Figur 1 (e) illustrerer et fjerde tilfelle hvor systemet som er vist i figur 1 (a) anvendes for å integrere datavarehus-programvareapplikasjoner ved anvendelse av to eller flere forskjellige relasjonsdatabase-styringssystemer (RDBMS) eller multidimensjonal database-styringssystemer; Figur 2 er et blokkdiagram over EAI-systemet som er vist i figurene 1(a)-(e); Figur 3 viser et adapterutviklingssett som anvendes i systemet vist i figur 2; Figur 4(a) illustrerer en grunnleggende agent-adapter arkitektur som er nyttig ifølge en første utførelsesform av foreliggende oppfinnelse; Figur 4(b) illustrerer en utvidbar agent-adapter arkitektur som er nyttig ifølge en andre utførelsesform av foreliggende oppfinnelse; Figur 4(c) er et blokkdiagram som illustrerer en nåværende foretrukket utførelsesform av et agent-adapter ifølge oppfinnelsen; Figurene 5(a) til 5(c) illustrerer design og integrasjonsobjekter som anvendes i systemet ifølge foreliggende oppfinnelse; Figur 6 illustrerer et meldingsskjema som anvendes i systemet ifølge foreliggende oppfinnelse; Figur 7 viser andre objekter ifølge foreliggende oppfinnelse; Figur 8 illustrerer en typisk transformasjonsprosess som anvendes ifølge foreliggende oppfinnelse; Figur 9 illustrerer ytterligere transformasjonsprosessen vist i figur 8; Figurene 10(a) og 10(b) illustrerer fordelen med meldingshubber ifølge foreliggende oppfinnelse; Figurene 11 (a) til 11(c) viser forskjellige operasjonsmiljøer hvor noder og tjenester ifølge foreliggende oppfinnelse administreres; Figur 12 er et blokkdiagram som illustrerer systemtjenester ifølge foreliggende oppfinnelse; Figur 13 er et flytdiagram som illustrerer trinnene som er nødvendig for å skape en melding ifølge foreliggende oppfinnelse uten å konvertere rå data; Figur 14 er et flytdiagram som illustrerer trinnene som er nødvendig for å skape en melding ifølge foreliggende oppfinnelse ved å konvertere rå data; Figur 15(a) illustrerer en fremgangsmåte for å gjøre om en melding fra en applikasjon til et meldingsobjekt ifølge en første utførelsesform av foreliggende oppfinnelse; Figur 15(b) illustrerer en fremgangsmåte for å gjøre om en melding fra en applikasjon til et meldingsobjekt ifølge en andre utførelsesform av foreliggende oppfinnelse; Figur 15(c) illustrerer en fremgangsmåte for å gjøre om en melding fra en applikasjon til et meldingsobjekt ifølge en tredje utførelsesform av foreliggende oppfinnelse; Figur 15(d) illustrerer en fremgangsmåte for å gjøre om en melding fra en applikasjon til et meldingsobjekt ifølge en fjerde utførelsesform av foreliggende oppfinnelse; Figur 16 er et første klassediagram ifølge foreliggende oppfinnelse; og Figur 17 er et andre klassediagram ifølge foreliggende oppfinnelse.

Detaljert beskrivelse av oppfinnelsen

Bedriftsens kiøremiliø ( eng. Computina Runtime Environment)

Med henvisning til figurene, hvor like referansetegn eller -nummer betegner like eller tilsvarende deler i hver av de mange synsvinklene, er det i figur 1(a) vist en forenklet oversikt over en bedrifts kjøremiljø 10. Typiske kjøremiljøer 10 anvender et mangfold pakkede programvareapplikasjoner inklusive «bakliggende» applikasjoner 20 for bedriftsressursplanlegging (ERP) og «front-ende» applikasjoner 30 for kunderelasjonsstyring (CRM), ett eller flere tilpassede eldre systemer 40 og ett eller flere multidimensjonal-/relasjons-databasestyringssystemer (RDBMS) 50.

Gjennom de siste tiårene har forretningsbedrifter designet eller kjøpt mange store enkeltformåls programvareapplikasjoner. Disse «eldre» applikasjonene anvendes fortsatt og var oftest designet for å utføre en spesifikk funksjon (f.eks. lagerføring, finans, regnskap, salgsressursautomatisering og menneskelige ressurser). I den senere tid er det også gjort betydelige investeringer av de samme bedriftene til prosedyrepakkede programvareapplikasjoner fra programvareutviklere så som SAP, PeopleSoft, Oracle og Baan. Hver av disse pakkede programvareapplikasjonene hadde sin individuelle styrke. Den typiske bedrift anvendte derfor to eller flere vesensforskjellige pakkede programvareapplikasjoner i det samme kjøremiljøet. Slike pakkede programvareapplikasjoner var ikke, i begynnelsen, designet for å dele informasjon mellom seg. Som et resultat av dette ble bedriftene tvunget til å integrere sine forskjellige pakkede programvareapplikasjoner med kostbar skreddersydd kode. Slike integrasjonsjobbertok ofte måneder, om ikke år, å gjennomføre.

Bedriftsapplikasjon-integrerings (EAI) -systemer, så som systemet 100 vist i figur 1(a), ble derfor en nødvendighet. Til forskjell fra EAI-systemer ifølge tidligere teknikk, omfatter systemet 100 imidlertid løsningsorientert mellomvare som gjør det enklere for sine brukere å modifisere og fullt integrere informasjon som befinner seg i forskjellige applikasjoner gjennom én enkelt, felles infrastruktur. Dette lar brukeren flytte informasjon sømløst, usynlig og raskt blant ansatte, kunder og leverandører, for å oppnå maksimal produktivitet.

På denne måten frembringer systemet 100 et pålitelig lagre-og-videresend meldingssystem, en solid meldingsfordelingsanordning og en sterk agent-adapter arkitektur for å integrere vidt forskjellige bedriftsapplikasjoner. Det er tilpasset å bli distribuert, og er designet for enkel administrasjon og styring. Det er ment å fullstendig oppfylle kravene fra et heterogent datamiljø i en stor organisasjon. Det linker forskjellige applikasjoner på en intelligent måte slik at de kan aksessere og dele informasjon. Systemet er mellomvare som tilpasser seg applikasjonene istedet for at applikasjonene må tilpasse seg det.

Systemet 100 løser de fleste EAI-problemer ved å la sine brukere sammenknytte ERP-applikasjoner 20, pakkede applikasjoner 30, spesialtilpassede og eksisterende eldre applikasjoner 40 og databaser 50 gjennom hele bedriften, med minimalt med tilpasningskode. Når den er fullt integrert, kan en bedrift raskt synkronisere globale forretninger og avdelinger og tilpasse seg den evig skiftende etterspørselen fra markedet. Med raskere aksess til kunde- og faktureringsinformasjon kan brukerens organisasjon betjene kundene mer virkningsfullt og effektivt, og således skape sterkere og mer effektive relasjoner. Systemet 100 er et forretningssentrert bedriftsintegrasjonsløsning, med et designmiljø for integrasjonsflyter som sikter mot forretningsanalytikeren. Analytikeren definerer problemet med hensyn på forretningen og produktet ordner de tekniske sidene.

For eksempel, som vist i figur 1(b), så krever det vanlige tilfelle med integrasjon av bedriftsressursplanlegging (ERP) -systemer med spesialtilpassede eksisterende systemer at organisasjonen innkapsler komplekse prosesser i standard ERP-implementasjoner på en skikkelig måte - en ikke helt enkel ting å gjøre. Mange bedrifter velger å implementere pakkede applikasjoner for standard forretningsprosesser så som lager- og ordrestyring. Pakkede applikasjoner blir imidlertid sjelden anvendt for mer uvanlige prosesser. For slike formål er systemet 100 ideelt. Det frembringer objektgrensesnitt for ERP-systemene 22, 24, 26 og 28, såvel som innpaknings-(eng. wrapper) generasjon teknologi for sammenknytting med de eldre systemene 44 og 48.

Utvidelsen av den globale leverandørkjeden krever også mellomvare som bygger en bro mellom to eller flere forskjellige ERP-systemer 22, 24, 26, 28. Som illustrert i figur 1(c) ser en enkelt at ingenting kan være mer viktig enn samarbeid mellom forretninger. Systemet 100 spiller således en nøkkelrolle ved å tillate at transaksjoner mellom ERP-systemer, hvor forretningshendelser i et system (f.eks. SAP systemet 22) kaller på tilsvarénde hendelser i et annet system (f.eks. Baan systemet 28), uten å eksponere detaljene i den underliggende teknologien.

Integrasjon av et foretak sin «front-ende» med dets «bakliggende» applikasjoner er en viktig funksjon som gjør at front-ende applikasjoner kan interaktere med kunden for å samarbeide med bakenforliggende produksjonsapplikasjoner. Foreksempel, og nå med henvisning til figur 1 (d), er det meget viktig at kundestøttesystemer samarbeider med ERP-lagermoduler. Systemet 100 forenkler således integreringen av beste valg blant front-ende og bakliggende applikasjoner sømløst og usynlig.

I tilfellet med et datavarehus, som vist i figur 1(e), må data fra forskjellige systemer sendes til et sentralt datavarehus eller oppbevaringssted. Det å sende sanntidsinformasjon fra mange ERP-systemer (ikke vist i figur 1 (e)) til en sentral relasjons- eller multidimensjonell database inneholdende et mangfold forskjellige databaser 53, 56, 59 er et eksempel på dette problemet. Utviklere av datavarehus kan imidlertid balansere dataoversettingstjenestene i systemet 100, som beskrevet i mer detalj nedenfor, for sanntids datalagring eller andre operasjoner. Med dette blir dataene oversatt til et forståelig og meningsfylt format.

Definisjoner

Som benyttet nedover i det følgende, skal følgende termer oppfattes av de med ordinære kunnskaper innenfor teknikken ifølge deres ordinære og tilpassede betydning. I den grad definisjonene som benyttes nedenfor avviker fra ellers konvensjonelle definisjoner kjent av de med ordinære kunnskaper innen teknikken, må en forstå at slike termer i det følgende klart beskrives på en slik måte at en med rimelige kunnskaper innen teknikken vil innse at søkeren mente å redefinere den termen.

En «aksessor» er en funksjon spesifisert i meldingsdefinisjoner som systemet 100 anvender for å aksessere data. Aksessorer identifiserer starten og slutten på applikasjonsdatafelter og systemmeldingselementer, og fjerner og setter inn markører.

«Adapterimplementasjoner» er kode, tilpasset for en spesifikk applikasjon, som kan ekstrahere og produsere systemmeldinger; motta systemmeldinger og oppdatere data; eller ekstrahere data som respons på anmodninger om dette. Når brukeren oppretter en adapter for anvendelse i en integrasjonsflyt, bygger brukeren den rundt en adapterimplementasjon. System-adapterimplementasjoner tilbyr grunnleggende avbruddshåndtering (exception handling) og kan håndtere enhver meldingsdefinisjon. En bruker lager tilpassede adapterimplementasjoner ved anvendelse av en ADK som definert og beskrevet mer i detalj senere i dette dokument.

«Adaptere» er integrasjonsflyt-objekter som interakterer med bedriftsapplikasjoner for å ekstrahere data eller legge inn, oppdatere eller slette data.

«Administrasjonskonsollen» er et grafisk brukergrensesnitt (GUI) hvor en systemadministrator kan konfigurere og styre nodene og tjenestene i systemet 100.

«Agent-tjenester» frembringer systemtjenester til adapterene. Det må finnes en agent-tjeneste ved enhver vertsmaskin som kjører en adapter.

«classpath» er en miljøvariabel som forteller den virtuelle Java maskinen (Java virtual machine) hvor den finner klassebibliotekene, inklusive brukerdefinerte klassebiblioteker.

«Klienter» er prosesser som fjernaksesserer dataserveres ressurser, så som beregningskraft og minnekapasitet. Typiske systemklienter er integrasjons-arbeidsbenk 120 og administrasjonskonsollen 160 (figur 2).

En «forbindelse» er et objekt som spesifiserer oppstarts- eller forbindelsesparametre for adaptere. For eksempel spesifiserer en RDBMS-forbindelse JDBC-driveren, databasens URL, brukernavnet og passordet.

Å «konvertere data» er en prosess hvor konvertere spesifisert i meldingsdefininsjoner konverterer en applikasjons interne datatyper til de Java datatyper systemet 100 støtter, og omvendt.

En «konverter» er en funksjon spesifisert i meldingsdefinisjoner som systemet 100 anvender for å konvertere data. På denne måten konverterer konvertere interne datatyper til Java datatyper som systemet 100 støtter, og omvendt.

«Skreddersydde adapterimplementasjoner» er kode designet for en spesifikk applikasjon som kan: enten ekstrahere data og produsere

systemmeldinger; motta systemmeldinger og oppdatere data; eller ekstrahere data som respons på anmodninger. Skreddersydde adapterimplementasjoner, laget ved anvendelse av ADK, kan forbinde seg til applikasjoner som systemet 100 på det nåværende tidspunkt ikke støtter.

Et «definisjonsobjekt» er et integrasjonsflyt-objekt som frembringer instruksjoner for en prosess som systemet skal implementere.

«Separatorer» er tegn eller markører som skiller datafelter i data fra bedriftsapplikasjoner.

Et «permanent abonnenment» er en egenskap ved systemets meldingshubber som sikrer at hubbenes destinasjonsobjekter mottar alle meldinger som er ment for dem. Dersom et destinasjonsobjekt blir inaktivt husker systemet hvilke meldinger dette objektet har mottatt. Når det igjen blir aktivt leverer systemet de meldingene destinasjonsobjektet enda ikke har mottatt.

«Bedriftsapplikasjoner» er applikasjoner fra hvilke adaptere ekstraherer data eller til hvilke adaptere sender data (f.eks. SAP R/3 eller MQSeries).

En «bedriftsmeldingstjeneste (EMS)» ifølge denne oppfinnelsen implementeres ved anvendelse av Java Messaging Service (JMS). Denne gjør det mulig for systemet 100 å anvende flere forskjellige meldingsmoduser, og støtter meldingshubber og muliggjør meldingspersistens.

«Bedriftsressursplanlegging (ERP)» applikasjoner frembringer komplette løsninger (f.eks. varehusstyring, administrasjon av menneskelige ressurser og materialstyring) for vanlige forretningsproblemer. Eksempler på ERP-produkter er SAP R/3, PeopleSoft og Baan.

En «EntireXBroker (ETB)» er tverrplattforms, meldingsorientert mellomvare ifølge denne oppfinnelsen som linker prosesorenhet (eng. mainframe), Windows NT- og UNIX-plattformer og komponenter, Internett- og intranett-klienter, og Active-X- og Java-konfigurerte arbeidsstasjoner.

«Filterdefinisjoner» er definisjonsobjekter som spesifiserer kriterier for å

skille ut meldinger fra integrasjonsflyter.

En «funksjonsvert» er en beregningsplatform, så som en Windows NT tjener eller arbeidsstasjon, eller OS/390 prosessorenhet.

«Hubber» er integrasjonsflyt-objekter som mottar meldinger fra kildeobjekter og holder meldingene inntil systemet 100 leverer dem til de spesifiserte destinasjonsobjektene. Hubber gjør det mulig for adaptere og transformatorer å utveksle meldinger asynkront. De er også nyttige for å konsentrere meldingsflyter; forskjellige objekter som produserer den samme typen melding kan alle sende disse meldingene til én meldingshubb, hvilket forenkler lenkene mellom objekter.

En «IDoc Ekstraherer» leser flatfiler produsert av SAP R/3 transaksjonen WE63 for å opprette implementasjonskonfigurasjoner og meldingsdefinisjoner og lagrer dem i systemets oppbevaringstjeneste.

«Implementasjonsinnstillinger» er kjøreparametre for adaptere (f.eks.

pollingsintervall).

En «integrasjonsflyt» er en serie av linkede systemobjekter som flytter

data fra en eller flere bedriftsapplikasjoner til andre bedriftsapplikasjoner.

«Integrasjonsobjekter» er integrasjonsflytobjekter som sender meldinger, mottar meldinger eller begge deler. Se f.eks. adaptere, hubber og transformatorer.

En «integrasjons-arbeidsbenk» er et grafisk brukergrensesnitt (GUI) hvor

en bruker designer integrasjonsflyter.

«Mellomdokumenter (Idocs)» er et SAP R/3 dataformat som anvendes av

R/3 for å utveksle data med andre R/3 systemer og med andre applikasjoner.

Et «felt-meldingselement» er et meldingselement som inneholder data.

Felter er det laveste nivået av meldingselementer i hierarkiet for

meldingsdefinisjoer. De kan ikke inneholde andre meldingselementer.

«Java Database Connectivity (JDBC)» er Javas API-standard for SQL-basert databaseaksess.

«Java Development Kit (JDK)» er et utviklingsmiljø for å skrive programvare-applikasjoner i programmeringsspråket Java.

«Java Message Service (JMS)» er et Java API spesifisert av Sun Microsystems, for meldingstjenester.

Et «Java Naming and Directory Interface (JNDI)» er et sett av API-er som hjelper til med grensesnittet mot flernavning og filkatalog-tjenester.

«Java Runtime Environment (JRE)» er et subsett av Java Development Kit som anvendes for å redistribuere kjøremiljøet bestående av den virtuelle Javamaskinen, Java kjerneklasser og støttefiler.

En «virtuell Java maskin (JVM)» er den delen av Java Runtime Environment som er ansvarlig for å tolke bitgruppe-koder.

«Linkemarkører» er tegn eller separatorer som separerer datafelter i data fra bedriftsapplikasjoner.

En «meldingsdefinisjonskategori» er en logisk gruppering av meldingsdefinisjoner.

«Meldingsdefinisjoner» er definisjonsobjekter som identifiserer om datasystem 100 skal ekstrahere fra eller sende til en bedriftsapplikasjon. Meldingsdefininsjoner definerer også hvordan systemet 100 skal konstruere systemmeldinger fra bedriftsapplikasjonsdata eller skape bedriftsapplikasjonsdata fra systemmeldinger.

Et «meldingselement» er et dataobjekt som utgjør meldingsskjemaet for en meldingsdefinisjon. Meldingselementer er arrangert i en hierarkisk struktur og kan være seksjoner, tabeller eller felter.

«Meldings-Orientert Mellomvare (MOM)» er programvare som anvender meldinger for å gjøre det mulig for applikasjoner på den samme eller en annen plattform å kommunisere. Kommunikasjonsprotokoller er skjult fra applikasjonene. Eksempler på MOM-er er MQSeries, EntireXBroker og JMS.

Med «meldingspersistens» menes at meldinger lagres i et gjenopprettbart medium. Systemet skriver hver melding det leverer fra ett integrasjonsobjekt til et annet til et stabilt lagringsområde som brukeren spesifiserer. Dersom det inntreffer et systemsammenbrudd mens en melding er i transitt, kan systemet 100 hente tilbake meldingen fra lagringsområdet når det kommer opp igjen og levere meldingen til dens adressater.

Et «meldingsskjema» er den delen av meldingsdefinisjoner som definerer hvordan en melding skal struktureres. Meldingsskjemaer kan inkludere seksjons-, tabell- og felt-meldingselementer arrangert i en hierarkisk struktur.

«Overvåkningstjenester» lagrer systemets kjøretidsdata, inklusive systemlogger og statistikkinformasjon.

En «node» er en fysisk prosess (eller virtuell Java maskin) som støtter ett eller flere systemer og applikasjonstjenester.

«Nodeverter» er programvare som lar brukeren konfigurere og kjøre noder på en maskin. Brukeren må installere en nodevert på hver maskin, bortsett fra nodeadministratoren, som skal vært vert for en node.

En «nodeadministrator» er et grensesnitt for styring av noder. Grensesnittet lar brukeren konfigurere, starte, pause eller stoppe en tjeneste. Nodeadministratorer starter og stopper også noder. Nodeadministratoren vedlikeholder tilstanden til alle tjenester som er distribuert til nodene. I tillegg opprettholder nodeadministratoren statusinformasjon (f.eks. nåværende tilstand eller aktivitetsnivå) for en node eller en tjeneste.

«Punkt-til-punkt meldingstjeneste» er en meldingsstil for hubber hvor systemet leverer hver melding som ankommer hubben til kun én destinasjonshubb (dvs. den første tilgjengelige).

En «primær inngangsmelding» er hoved-inndataene til systemtransformasjonsprosessene som er spesifisert i

transformasjonsdefinisjonene. Systemet tar inngangsdata, transformerer dem, og skaper de utgangsdataene som er nødvendige for

destinasjonsapplikasjoner.

«Publisér/abonnér meldingstjeneste» er en meldingsstil for hubber hvor systemet leverer hver melding som ankommer hubben til alle destinasjonshubber.

En «respondent» er et systemobjekt, så som et svaradapter, som fremskaffer data når transformatorene ber om det under

datatransformasjonsprosessen.

«Svaradaptere» er integrasjonsobjekter som svarer på anmodninger om data fra andre integrasjonsobjekter ved å ekstrahere dataene fra applikasjoner

og sende dem til de anmodende objektene. Anmodere sender systemmeldinger som inneholder data i nøkkelelementer i meldingene, og svaradapterne legger inn data i tilhørende meldingselementer og returnerer systemmeldingene.

En «oppbevaringstjeneste» er grensesnittet mot Java Native Directory Interface og lagrer konfigurasjoner for alle konfigurerte tjenester og integrasjonsflytobjekter.

«Rutingstjenester» gjør det mulig for systemet å rute meldinger gjennom systemet basert på en meldings innhold, inklusive filtrering av meldingsinnhold i henhold til brukerdefinerte kriterier. Rutingstjenesten støtter filtre.

En «systemmelding» er en melding, i et plattformuavhengig format, som systemet anvender for å flytte data fra applikasjon til applikasjon.

«Seksjonsmeldingselementer» er ikke repeterende grupper av meldingselementer som ikke inneholder faktiske data. De inneholder andre meldingselementer som inneholder data (dvs. de inneholder felter). Seksjoner kan inneholde enhver kombinasjon av forskjellige typer meldingselementer.

En «tjeneste» er en prosess som frembringer produktfunksjonalitet. Systemet utgjøres av system-, meldings-, integrasjons- og agenttjenester.

«Kildeadaptere» er integrasjonsobjekter som ekstraherer data fra bedriftsapplikasjoner, konstruerer systemmeldinger fra dataene og sender meldingene til andre systemintegrasjonsobjekter.

Et «kildeobjekt» er et integrasjonsflytobjekt som frembringer meldinger til andre objekter. Se f.eks. kildeadaptere, transformatorer og hubber.

«Støtte-inngangsmeldinger» er eventuelle ekstra inngangsdata til systemets transformasjonsprosesser, som spesifisert i

transformasjonsdefinisjoner. Transformasjonsprosesser anvender data i støtte-inngangsmeldinger som et supplement til dataene i de primære inngangsmeldingene. Systemet tar inngangsdata, transformerer dem, og skaper de utgangsdataene som er nødvendige for destinasjonsapplikasjonene.

Et «tabell-meldingselement» er en gruppe av seksjonsmeldingselementer, kalt rader, som kan repeteres et hvilket som helst antall ganger. Tabellelementer inneholder ikke faktiske data. Istedet inneholder de andre meldingselementer som inneholder data (dvs. de inneholder felter). Tabeller kan inneholde enhver kombinasjon av alle typer meldingselementer.

«Destinasjonsadaptere» er integrasjonsobjekter som mottar systemmeldinger fra andre integrasjonsobjekter, skaper applikasjonsdata fra systemmeldingene og sender dataene til destinasjonsapplikasjoner.

Et «destinasjons-integrasjonsobjekt» er et integrasjonsflytobjekt som mottar meldinger fra andre objekter. Se f.eks. destinasjonsadaptere, transformatorer og hubber.

En «Transaksjonsprosesseringsovervåker (TPM)» er et programvaresystem som er designet for å optimere bruken av beregningsressursene, så som lagring og applikasjoner, for mange brukere.

Det å «transformere data» er en prosess hvor transformatorer modifiserer data tatt fra en eller flere bedriftsapplikasjoner til data som er nødvendig for andre bedriftsapplikasjoner.

«Transformasjonstjenester» gjør det mulig for systemet å transformere meldinger, inklusive å splitte meldinger, kombinere meldinger og manipulere meldingens data. Transformasjonsanordningen støtter transformatorer.

Et «transformasjonstrinn» er en kommando som utgjør transformasjonsprosessen. Hvert trinn enten leser innsendte meldingsdata, transformerer og avbilder innsendte meldingsdata til utgangs-meldingsdefinisjoner, eller skriver transformerte data til utgangsmeldinger.

«Transformasjonsdefinisjoner» er definisjonsobjekter som definerer hvordan systemet skal transformere systemmeldinger ekstrahert fra en eller flere bedriftsapplikasjoner til systemmeldinger som kan leses av andre bedriftsapplikasjoner.

En «transformator» er et integrasjonsobjekt som implementerer transformasjonsdefinisjoner. Transformatorer samler meldinger innsendt av kilde-integrasjonsobjekter, transformerer innholdet i og formatet på dataene i meldingene og produserer og sender utgangsmeldinger til destinasjons-integrasjonsobjektene.

«Brukergrensesnitt-tjenester (UIS)» frembringer brukergrensesnittet for å kunne kjøre klientkomponentene (dvs. integrasjons-arbeidsbenken 120 og administrasjonskonsollen 160).

Nå med henvisning til figur 2, omfatter systemet 100 vanligvis et mangfold designkomponenter 110 og et mangfold komponenter for kjøretidsadministrering 150. Designkomponentene 110 omfatter i sin tur mer spesifikt en integrasjons-arbeidsbenk 120, et adapter-utviklingssett (ADK) 130 og en oppbevaringstjeneste 140. Komponentene for kjøretidsadministrasjon 150 omfatter i sin tur mer spesifikt en administrasjonskonsoll 160, en integrasjonstjener 170, som inkluderer en motor for bedriftsmeldingstjenestene 180, en nodetjenestekomponent 190 og et mangfold intelligente agent-adaptere 200.

Integrasjons-arbeidsbenken 120 omfatter generelt et grafisk modellerings-og konfigureringsverktøy for utvikling av integrasjonsprosjekter. Dette anvendes for å definere hendelser, meldingene assosiert med slike hendelser, integrasjonsflyter og forretningsregler assosiert med slike integrasjonsflyter, og for å identifisere hvilke agenter som publiserer og abonnerer på slike hendelser. I tillegg frembringer integrasjons-arbeidsbenken 120 diagnostikk for konsistenssjekking og testing av integrasjonsflyter.

ADK 130 anvendes for å konfigurere og generere spesialtilpassede intelligente agent-adaptere 200. Som vist mer i detalj i figur 3, så omfatter ADK 130 generelt et objekt-rammeverk som inkluderer klassebiblioteker 132, veivisere 134 og maler 136. ADK 130 genererer objekter som kan aksesseres fra konvensjonelle utviklingsverktøy. Selv om systemet 100 inkluderer et mangfold standard intelligente adaptere 200 for et bredt spekter av applikasjoner og ressurser, kan det finnes visse applikasjoner for hvilke det ikke eksisterer et slikt standard intelligent agent-adapter 200. I slike tilfeller tillater videre ADK at det kan bygges en spesialtilpasset intelligent agent-adapter 200 av utviklere som er familiære med de publiserte grensesnittene som tilbys av miljøet i den tiltenkte applikasjonen.

Oppbevaringstjenesten 140 omfatter vanligvis en relasjonsdatabase, som inneholder alle spesifikasjonene for systemet 100, metadata, tjenesteregler for meldingsformidleren og et grensesnitt mot relasjonsdatabasen.

Administrasjonskonsollen 160 anvendes for å konfigurere og styre kjøretidsmiljøet for systemet 100, og omfatter vanligvis en grafisk konsoll. Den tjener som et kontrollpunkt for systemkonfigurasjon, -vedlikehold, -overvåkning og -diagnostikk. Gjennom administrasjonskonsollen 160 styres hver av de individuelle komponentene i system 100, inklusive omfattende tjenester så som initiering og terminering av komponenter og distribusjon av innlagt programvare.

Integrasjonstjeneren 170 implementerer en intelligent meldingstjeneste ved å sette i gang og eksekvere integrasjonsflyter for å prosessere hendelser. Den eksekverer statiske og dynamiske kontekstsensitive regler som evaluerer, modifiserer og ruter hendelsesdata. Som angitt tidligere i teksten, inkluderer integrasjonstjeneren 170 meldingsmotoren 180 som omfatter et distribuert meldings-undersystem som administrerer alle data i forbindelse med hendelser. Den er, på den ene side, en nøkkelkomponent i systemet 100. På den annen side er den stort sett usynlig for brukerne av systemet 100, og opererer vanligvis bak kulissene. Den støtter full persistens, én-gangs meldingslevering og en i-minne modus for tilfeller med levering av ikke-kritiske meldinger med stort volum.

Komponenten for nodetjenester 190 administrerer datagjenvinningen ved start/stopp avbruddshåndtering og dynamisk konfigurering av systemet 100. Den tilbyr fasiliteter for automatisert systeminstallasjon og fjernstyring på tvers av alle deltagende klienter og tjenere. Den kan dessuten enkelt fjerninstallere og -oppdatere komponenter.

Som angitt ovenfor i teksten, inkluderer mangfoldet av intelligente agent-adaptere 200 ikke bare de standard intelligente agent-adapterne 200 som distribueres med systemet 100, men også de spesialtilpassede intelligente agent-adapterne 200 som er utviklet ved ADK 130. Hver slik intelligent agent-adapter 200, uavhengig av type, omfatter vanligvis en kjøretids grensesnittsmodul som forbinder én spesifikk av de eksterne applikasjonsressursene 300 til systemet 100.

For øyeblikket med henvisning til figurene 4(a) og 4(b), ser en at slike intelligente agent-adaptere 200, ifølge et spesielt viktig aspekt ved foreliggende oppfinnelse, kombinerer funksjonaliteten med autonome agenter med adapterteknologi. Agentkomponenten 210 er en uavhengig programvareprosess som er vert for en eller flere adapterkomponenter 220 (figur 4(a)), eller 222 og 224 (figur 4(b)). Den innkapsler sofistikert funksjonalitet så som lagre og videresend hurtigbufring, filtrering, ressurssamling og køstyring.

En primær fordel med denne agent-adapter arkitekturen er dens kapabilitet til å være vert for kompleks forretningslogikk for å opprettholde tilstand og forhandle om transaksjoner med applikasjonsressursene 300. Denne kapabiliteten kan betraktes som «konvensjonell modus prosessering», som er spesielt kritisk når en integrerer applikasjonsressurser 300 av transaksjonsnatur. Mer regelen enn unntaket er at dataelementer som kan være nødvendig for å formidle meldinger fra slike applikasjonsressurser 300 er dypt nestet gjennom under-transaksjoner. Disse dypt néstede dataelementene kan således oppnås kun ved å sette i gang en konversasjon med den transaksjonene applikasjonsressursen 300. Ellers «primitive» adaptere, som er blitt anvendt i den senere tid, adresserer ikke den komplekse oppførselen til transaksjonene applikasjonsressurser 300 på en adekvat måte.

Som vist i figur 4(a), inkluderer en typisk intelligent agent-adapter 200 ifølge foreliggende oppfinnelse en agentkomponent 210 og en adapterkomponent 220. På den ene siden av denne arkitekturen, er agenten 210 i overensstemmelse med en spesifisert hendelse og meldingsmodell for systemet 100. Adapter 220, på den andre siden av denne agent-adapter arkitekturen, anvender et internt grensesnitt for applikasjonsprogrammering (API) 510 for en spesifikk applikasjonsressurs 300, eller en annen passende publisert grensesnittmekanisme. Agent 210 og adapter 220 stemmer sammen av forskjellene i grensesnittsprotokoller og datastrukturer for å oppnå et uniformt, normalisert overblikk over forretningshendelsene som de publiserer og konsumerer.

Til forskjell fra tidligere løsninger for EAI, er den foregående agent-adapter arkitekturen utvid ba r. Den forenkler ikke bare kapabiliteten til sømløst å imøtekomme endringer i eksisterende API-er, men den muliggjør også fortsatt bruk av de eksisterende API-ene for eldre eksisterende systemer. Som klarere vist i figur 4(b), så omfatter denne utvidbare agent-adapter arkitekturen vanligvis en agent 210 som innkapsler en første adapter A'222 og en andre adapter A"224.

Adapter A'222 for eksempel, tilsvarer en applikasjonsressurs 300 som har et grunnleggende sett med API-er A'. På den annen side tilsvarer adapter A" den samme applikasjonsressursen 300, men med et nyere sett av API-er A". Brukere av en slik utvidbar agent-adapter arkitektur kan således velge samtidig å tilpasse seg begge grensesnittene A' og A". For eksempel kan det grunnlegggende settet av API-er A' tilsvare ett produksjonsmiljø, mens det nyere settet med API-er A" kan tilsvare et pre-produksjonsmiljø for en nyere versjon av en spesifikk applikasjonsressurs 300. Det nyere settet av API-er A" kan således bli testet «live» i system 100 samtidig som det grunnleggende settet med API-er A' vil bli anvendt for å opprettholde tidligere testet og verifisert funksjonalitet. På denne måten muliggjør denne utvidbare agent-adapter arkitekturen perfekt sømløs innkorporering av inkrementene endringer av applikasjonsressursen 300 i integrasjonsmiljøet.

Nå med henvisning til figur 4(c), er det vist en langt mer detaljert oversikt over en agent-adapter 200 ifølge en nå foretrukket utførelsesform av oppfinnelsen. I likhet med agent-adaptrene vist i figurene 4(a) og 4(b), anvendes agent-adapteren 200 vist i figur 4(c) for å kommunisere mellom systemet 100 og det interne API-et 510 for en bedriftsapplikasjon (ikke vist). Agent-adapteren 200 ifølge denne utførelsesformen inkluderer imidlertid tre adaptere 222, 224 og 226. Som beskrevet mer i detalj nedenfor, er adapter 222 av typen kildeadapter, adapter 224 av typen destinasjonsadapter og adapter 226 av typen svaradapter. En med ordinære kunnskaper innenfor teknikken ser imidlertid enkelt at agent-adapteret 200 ifølge denne utførelsesformen av foreliggende oppfinnelse ikke er begrenset til noe gitt antall spesifikt rettede adaptere som kan innkapsles av agent 210. For eksempel kan det anvendes en anmoderadapter 228 (ikke vist i figur 4(c)) av typen beskrevet i mer detalj senere i denne teksten i kombinasjon med eller i stedet for adapterene 222, 224 eller 226 som er vist.

Ifølge et annet spesielt viktig aspekt av foreliggende oppfinnelse omfatter videre agent 210 et mangfold objekter 230-240 som er nyttige for å utvide kapabiliteten til agent-adapteret 200. For eksempel omfatter objekt 230 på det nåværende tidspunkt et transformasjonsobjekt som forbedrer ytelsen for funksjoner for system 100 som ellers ville vært sentralisert lokalt i agent-adapteret 200 selv. Tilsvarende omfatter objekt 231 et feiladministrasjonsobjekt, objekt 232 et forbindelsesstyringsobjekt og objekt 234 et regeladministrasjonsobjekt. Ytterligere utvidbarhet av agent-adapteret 200 er bare begrenset av antallet tilleggsobjektér 235-240 som kan samlokaliseres med agent 210.

Det foregående er et spesielt viktig aspekt ved foreliggende oppfinnelse siden det forenkler desentraliseringen av de forskjellige sidene ved meldingsbehandlingen for systemet 100. Distribuert applikasjons-integrasjon for bedrifter er derfor sikret, siden agent-adapteret 200 ifølge denne utførelsesformen av foreliggende oppfinnelse kan assosieres med enhver node i systemet 100.

Måten systemet 100 deler data mellom bedriftsapplikasjoner bestemmes av integrasjonsflyter, hvilket vil bli forklart mer i detalj senere i teksten. Typiske integrasjonsflyter anvender en eller flere systemmeldinger. Hver av systemmeldingene omfatter vanligvis en kommunikasjon, i et plattformuavhengig format, som flytter utvalgte data fra en programvareapplikasjon til en annen. Integrasjonsflyter, i sin tur, utgjøres av et mangfold objekter og linker mellom disse objektene. Hvert av objektene utfører en spesifikk oppgave relatert til systemmeldinger som bærer data fra bedriftsapplikasjon til bedriftsapplikasjon.

For eksempel, og nå med henvisning til figurene 5(a) til 5(c), omfatter et objekt i en integrasjonsflyt 540 enten et definisjonsobjekt 510 eller et integrasjonsobjekt 530. Det er tre grunnleggende typer definisjonsobjekter 510 som kan anvendes ifølge foreliggende oppfinnelse: (1) en meldingsdefinisjon 512; (2) en transformasjonsdefinisjon 514; og (3) en filterdefinisjon 516. Definisjonsobjekter 510 kan anvendes mange ganger i enhver integrasjonsflyt 540. For eksempel må den samme meldingsdefinisjonen 512 tilordnes alle objekter 510, 530 som skal jobbe med systemmeldinger som er produsert ved anvendelse av den meldingsdefinisjonen 512. Videre kan den samme filterdefinisjonen 516 anvendes i mange seksjoner av en integrasjonsflyt 540.

Meldingsdefinisjonsobjektet 512 identifiserer hvilke data som systemet 100 skal ekstrahere fra eller sende til en bedriftsapplikasjon 541, 549. Det definerer også hvordan systemet 100 ikke bare skal konstruere systemmeldinger fra bedriftsapplikasjonsdata, men også opprette bedriftsapplikasjonsdata fra systemmeldinger.

Transformasjonsdefinisjonsobjekter 514 definerer hvordan systemet 100 skal transformere systemmeldinger som er ekstrahert fra en eller flere bedriftsapplikasjoner til systemmeldinger som kan leses av andre bedriftsapplikasjoner.

Et filterdefinisjonsobjekt 516 definerer hvilke kriterier systemet 100 skal anvende for å filtrere ut uønskede systemmeldinger fra integrasjonsflyter. I en integrasjonsflyt som for eksempel transformerer data om nye kunder til fakturaer, er et filterdefinisjonsobjekt 516 som ville være nyttig et hvor systemmeldinger vedrørende kunder som allerede har betalt blir filtrert ut.

Integrasjonsobjekter 530, av hvilke det er tre grunnleggende typer, utfører den faktiske sendingen eller mottaket av systemmeldinger. De tre grunnleggende typene av integrasjonsobjekter er 530: (1) et adapter 220; (2) en meldingshubb 518; og en transformator 520. Videre, og som kort beskrevet ovenfor i teksten, er det fire grunnleggende typer adaptere 220: (a) kildeadaptere 222; (b) destinasjonsadaptere 224; (c) svaradaptere 226; og (d) anmoderadaptere 228.

Et kildeadapter 222 ekstraherer data fra en kilde-bedriftsapplikasjon, konstruerer systemmeldinger fra disse dataene og sender meldingene til andre integrasjonsobjekter 530 (f.eks. en meldingshubb 518). Et destinasjonsadapter mottar systemmeldinger fra andre integrasjonsobjekter 530 (f.eks. transformator 520 gjennom filterdefinisjonsobjektet 516), skaper applikasjonsdata fra disse systemmeldingene og sender disse dataene til en destinasjons-bedriftsapplikasjon. Et svaradapter 226 svarer på anmodninger om data fra andre integrasjonsobjekter 530 ved å ekstrahere dataene fra applikasjonene og deretter sende dem til det anmodende objektet 530.

Vanligvis anvendes hubbene 518 for å motta systemmeldinger fra en eller flere kilde-integrasjonsobjekter 530 og for å ta vare på disse systemmeldingene inntil systemet 100 kan levere dem til ett eller flere destinasjons-integrasjonsobjekter 530.

Transformatorer 520 anvendes vanligvis for å implementere transformeringsdefinisjoner i tre trinn. Først samler de opp systemmeldinger fra kilde-integrasjonsobjekter 530 (f.eks. meldingshubb 518). Etter oppsamlingstrinnet transformerer de deretter innholdet og formatet til dataene inneholdt i slike systemmeldinger. Til slutt produserer og sender de ut systemmeldinger til destinasjons-integrasjonsobjekter 530 (f.eks. destinasjonsadapter 224).

Meldingsdefinisjoner 512 er de primære objektene som integrasjonsflyten 540ifølge foreliggende oppfinnelse er bygget opp rundt. Når en bruker skaper en integrasjonsflyt, tilordnes en meldingsdefinisjon til hvert objekt 510, 530 i den flyten. En meldingsdefinisjon 512 identifiserer ikke bare hvilken type systemmeldinger som objekt 510, 530 skal jobbe med, men den definerer også den hierarkiske strukturen eller skjemaet for den systemmeldingen.

For eksempel så må en meldingsdefinisjon 512 være tilordnet enhver kildeadapter 222 i brukerens integrasjonsflyt 540. Basert på hvilken meldingsmeldingsdefinisjon 512 brukeren har tilordnet den, vet hver kildeadapter 222 hvilken type melding den skal produsere. Adaptere 220, hubber 518 og filtre 516 håndterer kun én meldingsdefinisjon 512. Transformasjonsdefinisjoner 514 og transformatorer 520 på den annen side, kan håndtere mange forskjellige meldingsdefinisjoner 512 som inn- eller utdata.

Noen applikasjoner kan opprette de Java-datatypene systemet 100 støtter. I de tilfellene kan kildeadapteret 222 ekstrahere de datatypene som er spesifisert i sin meldingsdefinisjon 512 og lagre dem direkte inn i en systemmelding. Likeledes kan et destinasjonsadapter 224 hente ut datatypene fra en systemmelding og sende dem direkte inn i applikasjonen (f.eks. en destinasjons-bedriftsapplikasjon 549). Andre applikasjoner anvender et veldefinert meldingsformat for å beskrive layouten på sine interne data. I de tilfellene må meldingsdefinisjonen 512 for en kildeadapter 222 inkludere instruksjoner for å opprette Java-datatyper fra applikasjonsdataene. Tilsvarende må meldingsdefinisjonen 512 foren destinasjonsadapter224 inkludere instruksjoner for å skape applikasjonsdata fra systemets Java-objekter.

En spesiell type meldingsdefinisjon 512 anvendes av integrasjonsobjekter 530 for å be om data fra andre systemobjekter 510, 530. For eksempel kan meldingsdefinisjoner 512 også spesifisere kriterier for validering av meldinger. Systemet 100 anvender disse kriteriene for å bestemme hvorvidt systemmeldinger produsert av adaptere 220 og transformatorer 520 inneholder gyldige data (f.eks. når brukeren inkluderer en meldingsdefinisjon 512 som definerer meldinger som inneholder informasjon om ansattes lønn). Brukeren kan således forhindre at feilaktige lønnsdata kommer inn i systemet 100. Dersom for eksempel meldingsdefinisjonen 512 inneholder et felt «Lønn», kan brukeren definere valideringskriterier for dette feltet som sier at meldingen kun er gyldig dersom verdien i «Lønn» er et positivt tall. Brukeren kan organisere relaterte meldingsdefinisjoner 512 i logiske grupper kalt meldingskategorier. Anta for eksempel at brukeren integrerer tre applikasjoner ved anvendelse av systemet 100. Brukeren kan da gruppere meldingene i brukerens prosjekt i tre meldingskategorier, en for hver applikasjon.

Det skal her bemerkes at det spesifikke meldingsskjemaet 600 for en meldingsdefinisjon 512 utgjøres av dataobjekter, kalt meldingselementer, som er arrangert i en hierarkisk struktur som vist i figur 6. Vanligvis omfatter et meldingsskjema 600 en eller flere seksjoner 620, en eller flere tabeller 640 og ett eller flere felter 660. Enten en seksjon 620 eller en tabell 640 må finnes på toppen av meldingshierarkiet 600.

En seksjon 620 er en ikke-repeterende gruppe av meldingselementer. Slike seksjonselementer inneholder ikke selv faktiske data. Istedet inneholder de andre meldingselementer som inneholder data (dvs. de inneholder felter 660). Seksjonene 620 kan inneholde enhver kombinasjon av forskjellige typer meldingselementer.

En tabell 640 er en gruppe seksjonselementer, kalt rader, som kan gå igjen et hvilket som helst antall ganger. Tabellelementer inneholder heller ingen faktiske data. De inneholder andre meldingselementer som inneholder data (dvs. de inneholder felter). Tabeller 640 kan inneholde enhver kombinasjon av forskjellige typer meldingselementer.

Et felt 660 er et meldingselement som inneholder data. Felter 660 er det laveste nivået av meldingselementer i hierarkiet for meldingsdefinisjonen. De kan ikke inneholde andre meldingselementer.

Hver meldingsdefinisjon 512 kan inneholde kriterier for å validere meldinger basert på den definisjonen. Det vil si at når brukeren definerer en meldingsdefinisjon, kan han spesifisere kriterier som data i spesielle meldingselementer må oppfylle for at en melding skal betraktes som gyldig innen systemet 100.

Brukeren kan spesifisere valideringskriterier for alle nivåer av en melding. Det vil si at brukeren kan spesifisere kriterier for meldingsfelter innenfor seksjoner eller tabeller. Enten passerer hele meldingen valideringskriteriene og fortsetter i systemet, eller den passerer ikke og kasseres. Dersom selv bare én rad i en tabell ikke passerer de spesifiserte kriterier, passerer ikke meldingen. Systemet 100 valider hver melding produsert av en adapter 220 eller transformator 520 ved anvendelse av valideringskriteriene i den aktuelle meldingsdefinisjonen.

Adaptere 220 forbinder seg med bedriftsapplikasjoner for å ekstrahere eller sende data. Hver adapter 220 produserer, mottar eller svarer på meldinger ved anvendelse av den meldingsdefinisjonen 512 som brukeren har tilordnet den. Systemet 100 tilbyr standardadaptre 220 for de applikasjonene det skal integrere. Hver standardadapter 220, som nevnt ovenfor, er enten et kildeadapter 222, et destinasjonsadapter-224, et svaradapter 226 eller et anmoderadapter 228, og er designet for en spesifikk type agent-tjenester. For eksempel så tilbyr systemet for EntireXBroker en ETB Standard Source Adapter og et ETB Standard Target Adapter. Standardadaptere er generiske. De tilbyr grunnleggende avbruddshåndtering og kan håndtere enhver meldingsdefinisjon. Dersom et standardadapter 220 ikke inkluderer all den kode brukeren trenger for å interaktere med en applikasjon (f.eks. brukeren ønsker å spesifisere en mer detaljert avbruddshåndtering), kan han lage en spesialtilpasset adapter 220 ved anvendelse av ADK 130. Brukeren kan også anvende ADK 130 for å lage spesialadaptre 220 for applikasjoner som ikke støttes av systemet 100. Likeledes kan brukeren anvende ADK 130 for å lage spesialadaptere 220 som kan forbindes til enhver applikasjon med et Java applikasjons-programmeringsgrensesnitt (API).

For å anvende en standard eller en spesialtilpasset adapter 220 i en integrasjonsflyt 540 må brukeren konfigurere den slik at den håndterer en spesifikk meldingsdefinisjon 512. Brukeren kan konfigurere så mange av hver type adaptere 220 som er nødvendig for å håndtere alle meldinger han trenger å inkludere i integrasjonsflyter 540.

Kildeadaptre 222 ekstraherer data fra bedriftsapplikasjoner og produserer meldinger som de sender til andre integrasjonsobjekter 530. Et kildeadapter 222 mer spesifikt: (1) sjekker etter, eller får beskjed om fra sin applikasjon, om en spesifikk type hendelse som har inntruffet ved applikasjonen (f.eks. at det har blitt lagt inn data om en ny kunde); (2) ekstraherer dataene vedrørende hendelsen fra applikasjonen; (3) ved anvendelse av meldingsdefinisjoner, konstruerer en systemmelding fra dataene; og (4) produserer en melding og sender den til en eller flere destinasjons-integrasjonsobjekter 530.

Destinasjonsadaptere 224 mottar meldinger fra andre systemobjekter 510, 530 i integrasjonsflyter 540 og sender meldingens data til bedriftsapplikasjoner 541, 549. Et destinasjonsadapter 224 mer spesifikt: (1) mottar systemmeldinger fra ett eller flere kilde-integrasjonsobjekter 530; (2) ved anvendelse av instruksjoner fra meldingsdefinisjonen 512, skaper applikasjonsdata fra systemmeldingen; og (3) sender dataene til destinasjons-applikasjonen 549 ved å legge inn nye data, oppdatere data eller slette data etter behov.

Svaradaptere 226 ekstraherer data fra bedriftsapplikasjoner 541, 549 når de blir bedt om det av integrasjonsobjekter 530 så som transformatorer 520. Et svaradapter 226 mer spesifikt: (1) mottar en anmodning, i form av en melding, fra et integrasjonsobjekt 530; (2) ekstraherer de anmodede dataene fra fra sin bedriftsapplikasjon 541, 549; og (3) sender dataene til transformatoren 520 i en svarmelding basert på den samme meldingsdefinisjonen 512 som anmodningen.

Anmoderadaptre 228, i samarbeid med svartransformatorer 522, anvendes for å ekstrahere data fra bedriftsapplikasjoner 541, 549 uten spesifikke anmodninger fra slike applikasjoner. Som vist i figur 7, innhenter de informasjon som de forventer at vil trenges av et applikasjonsobjekt 710 som fremsetter en anmodning om andre data. For eksempel kan anmodningen fra applikasjonsobjektet 710 være så enkel som «Jeg ønsker å se data om kundefrakter». Alle data som omfatter slike kundefraktdata trekkes da med i forventning om at de trengs, legges inn i samme meldingsdefinisjon som anmodningen, og «oversendes» til applikasjonsobjektet 710. Et anmoderadapter 228 mer spesifikt: (1) mottar en anmodningsmelding fra et applikasjonsobjekt 710; (2) ekstraherer de forventede dataene enten direkte fra et annet objekt 540 i systemet 100 eller, med assistanse fra en svartransformator 522, gjennom svartransformatoren 522; og (3) sender dataene til applikasjonsobjektet 710 i en melding basert på den samme meldingsdefinisjonen 512 som anmodermeldingen.

Agenttjenester er verter for adaptere 220, som beskrevet i mer detalj nedenfor i teksten. Agenttjenestene frembringer det informasjonsadaptere 220 trenger for å forbinde seg til sine applikasjoner (f.eks. passord og brukeridentifikasjoner). Systemet 100 tilbyr agent-tjenester for hver bedriftsapplikasjon det kan integrere. Det vil si at den tilbyr en SAP R/3 agent-tjeneste, en EntireXBroker agent-tjeneste og så videre. Systemet 100 tilbyr også agent-tjenester for spesialtilpassede adaptere som brukeren lager ved anvendelse av ADK 130.

Brukeren trenger én agent-tjeneste for hver bedriftsapplikasjon som brukeren ønsker å integrere ved anvendelse av systemet 100. For eksempel, dersom brukeren ønsker å integrere tre SAP R/3 systemer med en RDBMS, trenger han tre SAP R/3 agent-tjenester og en RDBMS agent-tjeneste. Hver agent-tjeneste innehar alle adaptere 220 for den bedriftsapplikasjonen som agenten tilknytter seg.

Transformasjonsdefinisjoner 514 definerer en prosess som transformerer meldinger som inneholder data ekstrahert fra én eller flere applikasjoner til meldinger som inneholder de data som er nødvendig for én eller flere applikasjoner. Transformatorer 520 implementerer transformasjonsdefinisjoner ved å samle inngangsmeldinger fra kildeobjekter, transformere dataene og sende utgangsmeldinger til destinasjons-objekter.

Transformasjonsprosessen som er definert i en transformasjonsdefinisjon 514 involverer alltid minst to typer meldinger: den primære inngangsmeldingen og en eller flere utgangsmeldinger, som vist i figur 8. Den primære inngangsmeldingen inneholder typisk mesteparten eller alle dataene brukeren ønsker å sende som utgangsmeldinger til destinasjons-applikasjonene. Utgangsmeldinger inneholder data fra inngangsmeldingene, om nødvendig transformert for destinasjons-applikasjonene.

Når brukeren skaper en transformasjonsdefinisjon 514 spesifiserer han først ved 805 navnet på den primære inngangsmeldingen. Deretter, ved 810, identifiserer brukeren meldingsdefinisjonen 512 som definerer meldingene han ønsker å anvende som de primære inndata. Eventuelle støtte-inngangsmeldinger blir deretter spesifisert ved 815. Deretter identifiserer brukeren ved 820 de meldingsdefinisjonene 512 som definerer slike støtte-inngangsmeldinger. En enkelt transformasjonsprosess kan produsere et hvilket som helst antall utgangsdata. Derfor må brukeren spesifisere disse utgangsmeldingene ved 825 og identifisere de meldingsdefinisjonene som definerer meldingene som brukeren ønske å produsere som utdata.

Deretter skaper brukeren, med start ved 835, en sekvens av trinn 840, 845, 850, 855, 860, 865 som definerer når inngangsdata skal leses, hvordan disse dataene skal transformeres, hvordan inngangsdataene skal avbildes fra inngangsmeldings-definisjoner til utgangsmeldings-definisjoner og når de transformerte dataene skal skrives til faktiske utgangsmeldinger.

Brukeren transformerer inngangsdata på den måten det er nødvendig for å skape de utgangsmeldinger han har behov for. For eksempel kan brukeren skape et transformasjonsuttrykk som spesifiserer at et meldingsfelt som inneholder en kundes fornavn skal legges sammen med et meldingsfelt som inneholder kundens etternavn fordi en destinasjons-applikasjon krever at kundens fulle navn ligger i ett datafelt. Brukeren oppretter et transformasjonsuttrykk som spesifiserer at det skal velges kun spesielle tegn fra et meldingsfelt, eller å fylle opp et meldingsfelt med blanke tegn for å gi det den rette lengde for det tilsvarende datafeltet i destinasjons-applikasjonen. Brukeren produserer da forskjellige utgangsmeldinger ved å skrive dem ved forskjellige steder i transformasjonsprosessen.

Når den primære ingangsmeldingen ikke inneholder alle data som er nødvendige for å produsere utgangsmeldingene, kan brukeren oppnå støttedata for transformasjonsprosessen ved anvendelse av anmodnings/svar meldingsdefinisjoner. Anta for eksempel at den primære inngangsmeldingen brukeren anvender i transformasjonsdefinisjonen anvender forkortelser for navnet på stater i USA (f.eks. VA for Virginia).

Anta videre, for eksempel, at destinasjons-applikasjonen krever fulle navn på statene. For å få tak i statens fulle navn, som er nødvendig for å produsere utgangsmeldingene, vil brukeren anvende en anmodnings/svar meldingsdefinisjon som kan sende forkortelsene til en applikasjon og få det fulle navnet på staten i retur.

Etter at brukeren har opprettet en transformasjonsdefinisjon 514, kan han teste den for å verifisere at den produserer de riktige utgangsmeldingene før den anvendes i en integrasjonsflyt. Brukeren kan deretter tilordne transformasjonsdefinisjonen til en eller flere transformatorer 520.

En transformator 520 implementerer en transformasjonsdefinisjon 514. Når brukeren oppretter en transformator 520, kan han spesifisere objekter 510,530 som skal anvendes som kilder for den primære inngangsmeldingen og de objektene 510,530 som skal være destinasjoner for utgangsmeldingene. Brukeren spesifiserer også de objektene som skal svare på anmodninger om støttedata. Når transformatoren 520 mottar en primær inngangsmelding fra et kildeobjekt 540, kjører den sekvensen av trinn, som er definert i transformasjonsdefinisjonen, som utgjør transformasjonsprosessen. Deretter leser den de primære inngangsmeldingene og støttemeldingene, transformerer inngangsdataene, skriver de transformerte dataene til en eller flere utgangsmeldinger og sender utgangsmeldingene til destinasjonsobjektene 540. En typisk transformasjonsprosess er vist i figur 9. Transformatoren 520 mottar en primær inngangsmelding 920 fra en hubb 518. Deretter får den en støtte-inngangsmelding 940 fra et svaradapter 226. Til slutt sender transformatoren 520 to forskjellige utgangsmeldinger 960, 980 til to forskjellige destinasjonsadaptre 224.

Hubber 518 er områder hvor adaptere 220 og transformatorer 520 lagrer meldinger. Hubber 518 gjør det mulig for adaptere 220 og transformatorer 520 å utveksle meldinger asynkront, og forenkler linkene mellom objekter. For eksempel kan brukeren ha en kildeadapter 222 som produserer meldinger til en transformator 520. Brukeren vil kunne ønske at adapteren 222 skal produsere og sende sine meldinger uansett om transformatoren 520 er klar til å ta imot dem. Brukeren kan da sette opp adapteren 222 til å sende sine meldinger til en meldingshubb 518, og sette opp transformatoren 520 til å motta adapterens meldinger fra den hubben 518. Systemet 100 leverer da meldinger fra hubben 518 til et destinasjonsobjekt 540 når dette er klar til å motta dem.

Videre kan brukeren ha tre kildeadaptere 222 som sender meldinger basert på den samme meldingsdefinisjonen 512 til fem destinasjoner 224, 520. Dersom brukeren ikke anvendte en hubb 518 (som vist i figur 10 (a)), ville han være nødt til å opprette totalt 15 linker mellom disse objektene. På den annen side, dersom brukeren anvender en hubb 518 (som vist i figur 10(b)), ville han bare være nødt til å skape og opprettholde åtte linker. Meldingshubber 518 kan kun lagre én type meldinger (dvs. meldinger produsert fra én meldingsdefinisjon 512). Destinasjonene for hubber 512 har permanente abonnenter. Systemet 100 holder rede på hvilke meldinger hvert destinasjonsobjekt 224, 520 har mottatt fra hubben 518, så vel som hvilke hvert destinasjonsobjekt 224, 520 ikke har mottatt. Dersom et destinasjonsobjekt 224, 520 blir inaktivt, husker systemet 100 hvilken som er den siste meldingen som destinasjonsobjektet 224, 520 har mottatt. Når dette destinasjonsobjektet 224, 520 igjen blir aktivt, leverer systemet 100 kun de meldingene som destinasjonsobjektet 224, 520 ikke allerede har mottatt. Dersom hubb-abonnentene ikke var permanente, ville destinasjonsobjekter 224, 520 motta meldinger som ankom hubber 518 mens destinasjonsobjektene 224, 520 var aktive, men ville aldri motta meldinger som ankom hubbene 518 mens destinasjonsobjektene 224, 520 ikke var aktive.

Brukeren kan velge mellom to typer meldingstjenester som han ønsker systemet 100 skal anvende når det leverer meldinger fra hubben 518: (1) punkt-til-punkt, hvor systemet 100 kun leverer hver melding til den første tilgjengelige destinasjonen; eller (2) publisér/abonnér, hvor systemet 100 leverer hver melding til hvert objekt som brukeren har identifisert som en destinasjon for hubben 518.

Dersom brukeren ønsker å sortere en spesiell type data ut av deler av en integrasjonsflyt 540, må han anvende en filterdefinisjon 516. Filterdefinisjoner 516 spesifiserer kriterier basert på meldingsdata (dvs. data som oppfyller kriteriene fortsetter i flyten), mens data som ikke oppfyller kriteriene kasseres.

Når brukeren ønsker å filtrere en spesiell type melding, skaper han en filterdefinisjon 516 og tilordner den til en eller flere linker mellom objekter 540 som håndterer den typen meldinger. Systemet 100 anvender kriteriene i filterdefinisjonen 516 på alle meldinger som sendes langs disse linkene.

Betrakt for eksempel situasjonen hvor en hubb 520 sendes meldinger inneholdende data om nye kunder til en destinasjonsadapter 224. Brukeren ønsker muligens at kun data om kunder som enda ikke har betalt skal nå destinasjonsadapteren 224. For å gjøre dette ville brukeren opprette en filterdefinisjon 516 som spesifiserer kriteriet «Status=betalt», og tilordne denne til linken mellom hubben 518 og destinasjonsadapteren 224.

Brukeren kan opprette én eller flere filterdefinisjoner 516 for hver meldingsdefinisjon 512 i brukerens integrasjonsflyt 540. Brukeren kan tilordne en enkelt filterdefinisjon 516 til mange linker eller han kan tilordne forskjellige filterdefinisjoner 516 for den samme typen melding til flere linker.

Betrakt for eksempel situasjonen hvor en hubb 518 sender meldinger inneholdende data om nye kunder til to adaptere 220. Brukeren ville kunne ønske at en adapter 220 kun mottar meldinger om kunder som har betalt, og at den andre adapteren 220 kun mottar meldinger om kunder som enda ikke har betalt. Brukeren ville da, således, opprette to filterdefinisjoner 516. Den ene spesifiserer kriteriet «Status=ubetalt» og den andre spesifiserer kriteriet «Status=betalt». Brukeren ville deretter tilordne hver filterdefinisjon 516 til den korrekte linken.

Når brukeren oppretter en filterdefinisjon 516 for meldinger som ikke inneholder tabeller med data, affekterer kriteriene brukeren spesifiserer hele meldingen. Hele meldingen enten oppfyller filterkriteriene og fortsetter i flyten, eller den passerer ikke og blir kassert.

Når brukeren oppretter en filterdefinisjon 516 for meldinger som inneholder tabeller med data, kan brukeren spesifisere kriterier som gjelder for hele meldingen eller som gjelder kun for data i én tabell. Dersom brukeren spesifiserer kriterier for meldingsfelter i en seksjon 620, vil hele meldingen enten oppfylle filterkriteriene og fortsette i flyten, eller ikke passere og bli kassert. Dersom brukeren spesifiserer kriterier for meldingsfelter i en tabell 640, fortsetter meldingen i flyten med kun de radene med data som oppfyller kriteriene. Rader som ikke oppfyller kriteriene blir kassert.

Betrakt for eksempel situasjonen hvor en melding inneholder en tabell 640 med ni rader med data, en for hver av ni nye kunder. Dersom brukeren setter opp en filterdefinisjon 516 som filtrerer ut kunder som brukte mindre enn 9000 kroner ($1000), ville rader med kunder som brukte over 9000 kroner fortsette i flyten, mens rader inneholdende kunder som brukte mindre enn 9000 kroner ville bli kassert.

Etter at brukeren har opprettet en filterdefinisjon 516, kan han teste den for å forsikre seg om at den virker skikkelig før den anvendes i en integrasjonsflyt 540.

Når de systemobjektene brukeren ønsker å anvende i en integrasjonsflyt 540 eksisterer, kan han indikere hvordan han ønsker at systemet 100 skal rute meldinger mellom dem. For å gjøre dette setter brukeren opp linker mellom integrasjonsobjektene 530. Hver link etablerer ett objekt som kilde og det andre som destinasjon, eller ett objekt som anmoder og ett som svarer. Kildeadaptere er alltid meldingskilder. De kan sende meldinger til destinasjonsadaptere av den samme typen agent-tjeneste (f.eks. kan en SAP R/3 kildeadapter sende meldinger til en SAP R/3 destinasjonsadapter), til meldingshubber 518 og til transformatorer 520.

Transformatorer 520 kan være destinasjoner, anmodere og kilder. De kan motta primære inngangsmeldinger fra kildeadaptere 222, meldingshubber 518 og andre transformatorer 520. De kan også be om støttemeldinger 940 fra svaradaptere 226 og meldingshubber 518, og sende utgangsmeldinger 960, 980 til destinasjonsadaptere 224, hubber 518 og andre transformatorer 520. Meldingshubber 518 kan være destinasjoner og kilder. Destinasjonsadaptere 224 er alltid destinasjoner. De kan motta meldinger fra kildeadaptere 222 av den samme type agent-tjeneste, fra hubber 518 og fra transformatorer 520.

Dersom ikke annet spesifiseres anvender systemet 100 «meldingspersistens». Det vil si at det skriver hver melding det leverer fra ett integrasjonsobjekt 530 til et annet til en stabil lagringsplass på et sted brukeren spesifiserer. Dersom det inntreffer en systemsvikt mens en melding er i transitt, kan systemet 100 hente tilbake meldingen fra lagringsplassen når systemet er oppe igjen og levere meldingen til sine destinasjoner.

Siden meldingspersistens øker systemets ekstrabruk av ressurser, lar systemet 100 brukeren skru av meldingspersistens for hvert integrasjonsobjekt 530. Dersom det imidlertid inntreffer en systemsvikt mens meldinger er på vei til eller fra det objektet, kan de meldingene gå tapt. Systemet 100 tilbyr andre leveringsrelaterte opsjoner som hjelper brukeren å administrere brukerens systemressurser. Systemet 100 holder meldingsoppbevaringsområder for hvert integrasjonsobjekt i en integrasjonsflyt. Brukeren kan også kontrollere størrelsen på disse oppbevaringsområdene.

Brukeren kan begrense antallet meldinger systemet 100 oppbevarer for hvert objekt samtidig, og brukeren kan begrense hvor lenge systemet 100 skal oppbevare hver melding. Dersom et integrasjonsobjekt 530 produserer meldinger raskere enn dens destinasjoner klarer å motta dem, kan disse begrensningene forhindre at objektets lagringsområde blir så stort at det tar for mye systemressurser.

Brukeren designer all integrasjonsflyt innen et prosjekt fra arbeidsbenken 120. Denne integrasjonsflyten som brukeren designer og sparer (dvs. definisjonen 510 og integrasjonsobjekter 530 som brukeren oppretter, samt linkene mellom dem) lagres alle i lagringsplassen 140. Prosjektet er en logisk struktur som lar brukeren betrakte lagringsplassen 140. Hver installasjon av systemet 100 har ett prosjekt og én lagringsplass 140.

Den generelle strukturen og designfilosofien for meldingsobjektet som anvendes av alle produsenter av meldinger i systemet 100 vil nå bli beskrevet. Meldingsmodellen som beskrives her er uendelig utvidbar og nyttig for å konvertere til og fra interne filformater så vel som for å sende interne meldinger fra node til node i systemet 100. Meldingen er hierarkisk bygget opp og anvender en navn/verdi-par paradigme for å representere dataene. Data representert ved meldingsmodellen ifølge foreliggende oppfinnelse er alltid basert på objekter. De er en instans av et Java-objekt av en spesifikk klasse. Hver datanode er typerobust i den forstand at den kan bare inneholde data som er av den spesifiserte klassen. Strukturen til en melding er drevet av metadata.

Det vil si at velkonstruerte meldinger alltid er bygget ved anvendelse av skjemaet tilgjengelig i et objekt kjent som meldingsdefinisjonen 512. Hver melding av en viss «type» er bygget med utgangspunkt i den samme meldingsdefinisjonen 512. Meldingsdefinisjonen 512 er selv en instans av en melding, selv om dens noder har blitt utvidet til å inneholde informasjon om hvordan å skape instanser med det formatet den beskriver, så vel som eventuell tilleggsinformasjon om hvordan å konvertere data til og fra et internt applikasjons-filformat.

Som kort beskrevet ovenfor, er en melding 600 en tre-strukturert samling av enkle og sammensatte objekter. Alle objekter som kan opptre i en melding er forskjellige typer «meldingsdeler». I en nåværende foretrukken utførelsesform av oppfinnelsen omfatter en meldingsdel en av de følgende typer: (1) et dataelement; (2) et arrayelement; (3) et tabellelement; og (4) et seksjonselement eller en «meldingslink». Meldingen har alltid et enkelt seksjonselement på toppen av treet, kjent som «toppseksjonen». Denne og andre seksjoner kan inneholde instanser av hvilke som helst av de fire elementtypene.

Et dataelement inneholder «atomiske» data, selv om dataene er pakket inn i en Java-klasse. For eksempel så er data i form av et heltall pakket inn i objektet java.lang.lnteger, informasjon om dato/tid er innpakket i et java.util.Calendar objekt, og så videre. Et arrayelement er en samling av ett eller flere primitive elementer. En arrays lengde er spesifisert i metadataene, selv om denne lengden kan spesifiseres som et lovlig intervall, hvor i så fall lengden bestemmes ved å sjekke in intern applikasjons filprotokoll. Et tabellelement er en isomorf samling av seksjonselementer, hvilket betyr at hver «rad» i tabellen er en seksjon inneholdende eksakt den samme kombinasjonen av navn og typer. Den har også en potensiell variabelt intervall spesifikasjon. En meldingslink er en peker til en annen persistent melding definisjon i systemet og anvendes for å slå sammen formater. Dette er nyttig for å implementere «redefinisjoner». Meldingen kan representere eventuelle tilleggsdata, så vel som standard utgangsverdier, som angitt av meldingsdefinisjonen.

I den enkelste form for anvendelse, oppretter en kun en tom generisk melding ved å kalle på en statisk fabrikkfunksjon (eng. factory method) i meldingsdefinisjons-klassen. Dette oppretter en melding med alle nødvendige navn/verdi par, men hvert dataelement er satt til null. Den eneste offentlig eksporterte meldingskonstruktoren krever en meldingsdefinisjon som parameter, hvilket sikrer en riktig form. API-et for meldinger tilbyr en måte å aksessere dens meldinger, enten ved hjelp av navn eller eller gjennom seksjonsiteratorer. Det skal her bemerkes at det at meldingen støtter et hierarkisk navningsskjema ved anvendelse av en konfigurerbar separator, muliggjør aksess til enhver komponent i hierarkiet via fullt eller relativt «banenavn».

En seksjon 620 er en ikke-repeterende gruppe av meldingselementer. Slike seksjonselementer inneholder ikke selv faktiske data. Istedet inneholder de andre meldingselementer som inneholder data (dvs. de inneholder datafelter 660). Seksjoner 620 kan inneholde enhver kombinasjon av forskjellige typer meldingselementer.

En tabell 640 er en gruppe seksjonselementer, kalt rader, som kan repeteres et hvilket som helst antall ganger. Tabellelementer inneholder heller ingen faktiske data. De inneholder andre meldingselementer som inneholder data (dvs. de inneholder felter). Tabeller 640 kan inneholde enhver kombinasjon av meldingstyper.

Et felt 660 er et meldingselement som inneholder data. Felter 660 er det laveste nivået av meldingselementer i hierarkiet av meldingsdefinisjoner. De kan ikke inneholde andre meldingselementer.

Brukeren designer all integrasjonsflyt 540 innen et prosjekt fra arbeidsbenken 120. De integrasjonsflyter 540 som brukeren designer og sparer (dvs. definisjonen 610 og integrasjonsobjekter 620 som brukeren oppretter, samt linkene mellom dem) lagres alle i lagringsområdet 140. Prosjektet er en logisk struktur som lar brukeren betrakte lagringsområdet 140. Hver installasjon av systemet 100 har ett prosjekt og ett lagringsområde 140.

Ifølge et annet viktig aspekt ved foreliggende oppfinnelse omfatter systemet 100 et distribuert system. Det vil si at brukeren kan kjøre systemkomponentene som utgjør systemet 100 på én eller flere fysiske maskiner (dvs. vertsmaskiner), men alle komponentene arbeider sammen som én applikasjon.

En node er en fysisk prosess som kjører hos en vert og støtter en eller flere tjenester. Hver node er en virtuell Java maskin (JVM) og kjennes igjen av operativsystemet som en javaw.exe prosess. Brukeren må opprette minst én node for hver vert som kjører en bedriftsapplikasjon som brukeren ønsker å integrere. Brukeren kan ha så mange noder som hans forretningskrav tilsier.

Det er to primære grensesnitt innenfor systemet 100: (1) arbeidsbenken 120; og (2) administrasjonskonsollen 160. Arbeidsbenken 120 tilbyr verktøy for å skape og modifisere integrasjonsflyter 540, mens administrasjonskonsollen 160 tilbyr alt av verktøy for å administrere systemets noder og tjenester. Begge er beskrevet mer i detalj nedenfor i teksten.

Oppretting av en integrasjonsflyt 540 ifølge foreliggende oppfinnelse kan utføres som følger. Brukeren må først fremskaffe agent-tjenester fra systemet 100. Fra administrasjonskonsollen 160 konfigurerer deretter brukeren systemnodene for hver vertsmaskin hvor en applikasjon han ønsker å integrere kjører. Deretter konfigurerer brukeren de nødvendige tjenestene ved nodene, inklusive én agent-tjeneste for hver applikasjon som brukeren skal integrere.

For å planlegge en integrasjonsflyt må brukeren bestemme følgende faktorer. For eksempel så må brukeren bestemme hvilke typer data han trenger å ekstrahere fra applikasjoner og sende til applikasjoner. Brukeren må også tenke på: (1) hvordan han ønsker å rute meldinger blant systemobjekter; (2) hvordan han trenger å transformere dataene fra en applikasjon slik at de kan anvendes av en annen applikasjon; og (3) hvorvidt han trenger å filtrere visse data ut av flyten.

Ved arbeidsbenken 120 må brukeren først opprette et prosjekt, og deretter opprette en integrasjonsflyt på følgende måte. Først må brukeren konfigurere adaptere 220 som skal interaktere med brukerens applikasjoner og opprette de meldingsdefinisjoner 512 brukeren trenger for å produsere nødvendige meldinger i integrasjonsflyten 540. Disse meldingsdefinisjonene 512 bør deretter testes for å verifisere at de produserer korrekte meldinger.

Deretter må brukeren opprette hubber 518 for å oppbevare meldinger fra adaptere 220 og transformatorer 518. Brukeren kan deretter lage avbildningsdefinisjoner 514 for å transformere meldinger fra kildeapplikasjonen 541 til meldinger som kan leses av destinasjons-applikasjonen 549. Videre kan brukeren lage testmeldinger 920, 940 og anvende dem for å teste hver avbildningsdefinisjon 514 for å verifisere at de produserer de ønskede utgangsmeldinger 960, 980.

Deretter må brukeren opprette de transformatorer 520 som er nødvendige for å implementere avbildningsdefinisjonene 514. Etter behov må adaptrene 220, transformatorene 520 og hubbene 518 knyttes sammen. Dersom brukeren har behov for å filtrere ut visse data av flyten 540, må han deretter opprette filterdefinisjoner 516. Fortrinnsvis ved anvendelse av testmeldinger, bør brukeren deretter teste filterdefinisjonene 516 for å verifisere at de filtrerer ut de riktige dataene. Deretter kan brukeren tilordne filterdefinisjonene 516 til linker mellom objekter.

Ved arbeidsbenken 120 må brukeren deretter sjekke gyldigheten av integrasjonsflyten 540 og korrigere den om nødvendig. Brukeren kan deretter spare og lukke prosjektet. Ved administrasjonskonsollen 160 må deretter brukeren konfigurere loggfremviseren slik at han kan se meldinger om systemaktiviteten. Dersom brukeren ønsker å se statistikk vedrørende systemaktiviteten (f.eks. antall meldinger produsert i spesifikke tidsintervaller av individuelle transformatorer), må han deretter konfigurere statistikkfremviseren.

Igjen ved administrasjonskonsollen 160 kan brukeren starte integrasjonsflyten ved å starte de relevante systemnodene og -tjenestene, inklusive agent-tjenestene for de applikasjonene som brukeren skal integrere. Deretter vil brukeren sjekke loggen og statistikken for å forsikre seg om at integrasjonsflyten 540 kjører korrekt. Dersom brukeren har behov for å gjøre endringer i integrasjonsflyten 540, må brukeren stoppe de relevante tjenestene fra administrasjonskonsollen 160, modifisere integrasjonsflyten 540 fra arbeidsbenken 120 og starte om tjenestene fra administrasjonskonsollen 160.

Det følgende beskriver for en med ordinære kunnskaper innen teknikken de prosedyrene som kan anvendes med en veiviser for kildeadaptre, en veiviser for destinasjonsadaptre og en veiviser for svaradaptre, alle ifølge foreliggende oppfinnelse, for korrekt å konfigurere en adapter 220. Generelt er det fire separate prosesser.

Først må en gjennomføre de følgende generelle trinn: (1) navne adapteren 200; (2) velge hvilken agent-tjeneste som skal være vert for adapteret 220; og (3) velge meldingsdefinisjonen 512 for meldinger som adapteren 220 skal produsere, motta eller svare på. Deretter må en utføre følgende generelle trinn: (1) velge en spesifikk adapter 220 som skal konfigureres (dvs. standard eller spesialtilpasset); (2) gi forbindelsesinformasjon; og (3) gi informasjon om implementasjonen. Mer regelen enn unntaket er at trinnet med å gi informasjon om implementasjonen inkluderer trinnet med å ekstrahere meldingsdefinisjonen 512 for den adapteren 220.

Den tredje prosessen avhenger av hvilken type adapter 220 som skal opprettes. Dersom en oppretter et kildeadapter 222 må en spesifisere hvilke destinasjoner adapteren 222 skal anvendes for å sende meldinger til. Dersom en på den annen side oppretter en destinasjonsadapter 224, må en spesifisere fra hvilke kilder adapteren 224 skal anvendes for å motta meldinger. Dersom en videre oppretter en svaradapter 226, må en spesifisere til hvilke anmodere (dvs. transformatorer 520) adapteren 226 skal anvendes for å sende svarmeldinger til.

Til slutt må en spesifisere leveringsopsjoner (f.eks. en meldings levetid) for adapterens meldinger. Før en kan opprette en adapter 220 må imidlertid den agent-tjenesten som skal være vert for adapteren eksistere ved applikasjonskonsollen 160. Før en for eksempel kan opprette en EntireXBroker adapter, må agent-tjenesten for EntireXBroker eksistere. Dersom en også ønsker å spesifisere kilde-, destinasjons- eller anmoderobjekter for en adapter 220 ved anvendelse av brukerveiviseren for adaptere, må disse objektene eksistere før en starter brukerveiviseren for adaptere.

Igjen med henvisning til figurene 4(a) og (b), grensesnitter agent-adapterne 200 mot applikasjonsressursene på den ene siden og systemets 100 infrastruktur på den andre. På den ene siden anvender adapter-halvdelen for hver agent-adapter 200 API-et til sin spesifikke applikasjonsressurs eller enhver annen publisert grensesnittsmekanisme. På den andre siden er agentsiden i overensstemmelse med hendelses- og meldingsmodellen for systemet 100 som beskrevet mer i detalj nedover i teksten. I kombinasjon finner agenten og adapteren ut av forskjellen i grensesnittsprotokoller og datastrukturer, hvilket gir en uniform, normalisert oversikt over forretningshendelsene de publiserer og konsumerer.

Til forskjell fra andre løsninger for applikasjons-integrasjon, frembringer det utvidbare designet av adapter-arkitekturen muligheten til sømløst å imøtekomme endringer i applikasjonsgrensesnitt samtidig som det fortsatt støtter det nåværende settet av grunnleggende grensesnitt. Dette er spesielt viktig for systemer som allerede er i produksjon. For eksempel en pakket applikasjon med et grunnleggende sett med grensesnitt A' som støttes av en spesifikk versjon av agent-adapteret 200. Dersom en nyere versjon av applikasjonen innkorporerer et nyere sett av grensesnitt A", kan brukeren velge å samtidig tilpasse seg de gamle grensesnittene A' for produksjonsmiljøet, mens han tilpasser seg A" for et pre-produksjonsmiljø for å teste de nye grensesnittene. Med denne fasiliteten kan inkrementene endringer i integrasjonsmiljøet innføres sømløst.

Alle komponenter i systemet 100 kan distribueres over alle støttede plattformer. Agent-adaptere 200 utvider dette på en fleksibel måte til de innvolverte applikasjonene. Nøkkelkomponenter i systemet 100 (f.eks agent-adaptere 200 eller integrasjonstjener 26) kan således være lokalisert samme sted som applikasjoner, fjernaksesseres eller begge deler. Det er mulig å ha mange arbeidskonfigurasjoner - miljøet er optimert for å balansere kravene til tilgjengelighet, ytelse og administrasjon.

Mange standard adaptere 200 leveres med systemet 100, inklusive SAP, MQSeries, ENTIRE Broker, RDBMS & CICS. Som sådanne frembringer adaptere 200 hurtig igangsetting og enkel integrasjon av disse informasjonsressursene. De reduserer også det nødvendige behovet for trening og kunnskaper. ADK 130, inklusive alle dets maler for automatiseringsveivisere, gir en høy produktivitet. Det kan tilpasses alle brukeres IDE-er, og det forenkler det å spesialtilpasse tilgjengelige adaptre og utvikle spesialtilpassede grensesnitt. Adaptrene 200 utgjøres av populære språk- og grensesnittbindinger, inklusive C++, Java, EJB, CORBA, COM, og Natural. På denne måten kan de plugges inn i enhver brukers miljø og verktøy. De reduserer bedriftens behov for dataspråkekspertise og de kan tilpasses komplekse krav til ressursgrensesnitt. Agent-adaptér arkitekturen ifølge foreliggende oppfinnelse frembringer således en robust fasilitet som støtter langt mer enn de enkleste grensesnitt. Dette sikrer en uniform hendelse på tvers av ressursporteføljen.

Agent-adapter undersystemet omfatter kjøretids-grensesnittsmodulene som forbinder eksterne applikasjoner til EAI-et. På adaptersiden er det det fysiske grensesnittet mot den eksterne applikasjonen. Agentsiden fungerer som vert for adapteren, styrer ressurser og publiserer hendelser på vegne av adapteren.

Base-adapterklassene i systemet 100 er som følger. Klassen «AdapterMain» gjør det mulig for adapteren å starte seg selv og prosessere sine konfigurasjonsdefinisjoner. Den er også ansvarlig for å opprette instanser av klassene som skal anvendes for de fire forskjellige typene av adapterkommunikasjon. Klassen «AdapterReceiver» gjør det mulig for adapteren å motta et dokument fra EAI og sende det videre til tredjehåndspakken. Klassen «AdapterSender» gjør det mulig for adapteren å motta et dokument fra en tredjehåndspakke og sende det til EAI. Klassen «AdapterResponder» gjør det mulig for adapteren å motta et dokument fra EAI, sende det videre til en tredjehåndspakke for prosessering, motta svar fra tredjehåndspakken og returnere dette svaret til EAI for prosessering. Klassen «AdapterRequestor» gjør det mulig for adapteren å motta et dokument fra en tredjehåndspakke, sende det videre til EAI for prosessering, motta svar fra EAI og returnere dette svaret til tredjehåndspakken.

EAI agent-adapter grensesnittet ifølge foreliggende oppfinnelse realiseres ved at adapteren implementerer en rekke Java-interface, mens adapter mot agent grensesnittet realiseres av adapteren ved anvendelse av kjente fremgangsmåter for node/agent komponentene.

Ifølge nok et annet viktig aspekt ved foreliggende oppfinnelse må enhver adapter implementere følgende grensesnitt. For AdapterBridge kalles klassefunksjonen:

initialize(Agent-adapterConfig)

av agenten under initialiseringen og anvendes av adapteren for å laste opp seg selv. Adapterbroen ligger i den klassefunksjonen hvor adapteren 220, 220', 220" må rådføre agenten 210 for å bestemme hvilke dokumentdefinisjoner som skal prosesseres og typen prosessering som tilbys for hvert dokument. Dette oppnås ved anvendelse av følgende agent-klassefunksjoner.

GetSendDocumentDefinitions() GetReceiveDocumentDefinitions() GetRequestDocumentDefinitions()

GetResponseDocumentDefinitionsQ

Denne klassefunksjonen vil da gå gjennom AdapterConfiguration dokumentet for å lokalisere den underseksjonen som tilhører den spesifikke dokumentdefinisjonen, innhente den dokumentspesifikke konfigurasjonsinformasjonen og opprette en instans av en spesifikk klasse basert på prosesseringstype (sende, mottak, anmodning eller respons). Den vil deretter enten starte en Thread (sende eller anmodning typer), kalle på Agent.setReceiveListener()(mottak type) eller Agent.setResponsel_istener()

(respons type) for å registrere agent-tilbakekallene som skal kalles når det ankommer en melding.

Klassefunksjonen restart() kalles av agenten 220, 220', 220" for å få adapteren 210 til å terminere all aktivitet, omlaste konfigurasjonsdata og starte opp seg selv igjen. Klassefunksjonen shutdown() kalles av agenten 220, 220', 220" under termineringsprosessering.

De følgende grensesnitt er også implementert av adapterne 220 som beskrevet nedenfor. For ReceiveListener-grensesnittet kalles en klassefunksjon

onReceiveMessage(ReceiveData)

av agent 210 ved mottak av en JMS melding, og agenten vil videresende dokumentet til adapteren for prosessering. Denne prosesseringer skjer under kontroll av JMS-sesjonstråden. Adapterprosesseringen vil i hovedsak bestå av en enveisruting av dokumentet til tredjehånds-programvareapplikasjonen ved anvendelse av grensesnittene som frembringes av applikasjonen. Det skal imidlertid bemerkes at det ikke forventes noe svar fra applikasjonen ved denne typen kall. Adapteren 220, 220', 200" vil kun forvente en suksess- eller feilrespons fra applikasjonen. Dersom EAI forventer et faktisk svar fra tredjehåndssystemet, må i stedet ResponsListener-grensesnittet anvendes.

For SendListener-grensesnittet kalles en klassefunksjon onSendTimerEvent(SendData)

av agenten 210 dersom adapteren 220, 220<*>. 220" anvender tidberegningstjenesten for noden/agenten. Denne tjenesten er nyttig når tredjehåndsgrensesnittet ikke har noen mulighet for å implementere en

hendelsesdrevet notitlkasjon om dokumenter som skal sendes til EAI for prosessering.

For RequestListener-grensesnittet kalles en klassefunksjon onRequestTimerEvent(RequestData)

av agenten 210 dersom adapteren 220, 220', 220" anvender tidberegningstjenesten for noden/agenten. Denne tjenesten er nyttig når tredjehånds-grensesnittet ikke har noen mulighet for å implementere en hendelsesdrevet notifikasjon om dokumenter som skal sendes til EAI for prosessering. Det skal imidlertid her bemerkes at RequestListener-grensesnittet er forskjellig fra SendListener-grensesnittet i det at det vil sende dokumentet til EAI og vente på et returdokument. Dette vil da bli sendt tilbake til tredjehåndssystemet.

For ResponseListener-grensesnittet kalles en klassefunksjon onResponseMessage(ResponseData)

av agenten 210 ved mottak av en JMS-melding, og agenten 210 vil sende dokumentet til adapteren 220, 220', 220" for prosessering. Denne prosesseringen vil foregå under kontroll av JMS-sesjonstråden. Adapterprosesseringen vil bestå av ruting av dokumentet til tredjehånds-programvareapplikasjonen ved anvendelse av grensesnittene som tilbys av applikasjonen og deretter å sende responsen tilbake til systemet 100 for ytterligere prosessering. Dersom systemet 100 imidlertid ikke forventer et faktisk svar fra tredjehåndssystemet må ReceiveListener-grensesnittet anvendes i stedet.

Når en bruker installerer systemet 100, er hovedkomponenten han installerer en nodeadministrator 1210 som vist i figur 12. Nodeadministratoren 1210 er en virtuell Java maskin (JVM) som tilbyr tjenester til alle de andre nodene og tjenestene brukeren installerer i systemet. Systeminstallasjonen oppretter automatisk en oppbevaringstjeneste 1220, en brukergrensesnitt-tjeneste (UIS) 1230 og en overvåkningstjeneste 1240 på den maskinen som er vert for nodeadministratoren 1210.

Før en bruker kan starte en klient 1205 (f.eks. administrasjonskonsollen eller integrasjonsarbeidsbenken 120) -sesjon, må han starte nodeadministratoren 1210. Som angitt ovenfor, starter nodeadministratoren 1210 automatisk oppbevaringstjenesten 1230 og UIS-et 1240. Ellers kan ikke brukeren anvende administrasjonskonsollen 160 eller integrasjonsarbeidsbenken 120 dersom ikke disse tjenestene kjører. Avhengig av den spesifikke administrasjonskonsoll-160 eller integrasjonsarbeidsbenk-120 jobb brukeren utfører, kan det være nødvendig med andre tjenester.

Når nodeadministratoren 1210 kjører, må brukeren konfigurere systemnodene og -tjenestene, inklusive agenttjenester 1250 for de applikasjonene brukeren ønsker å integrere. Brukeren initierer dette ved først å anvende en sesjon med administrasjonsprotokollen 160. Brukeren kan deretter starte en sesjon med integrasjonsarbeidsbenk 120 og begynne å designe integrasjonsflyter 540 som vist i figur 5(c). Når brukeren er ferdig med å designe slike integrasjonsflyter 540, kan han deretter starte dem ved å starte noder og tjenester fra en sesjon med administrasjonskonsoll 160.

Når brukeren igangsetter en klientsesjon, identifiserer han nodeadministratoren 1210 som klientens tjener 1215. Brukeren kan forbinde så mange integrasjonsarbeidsbenk-120 og administrasjonskonsoll-160 sesjoner med nodeadministratoren 1250 som hans forretningsbehov tilsier. Alle slike integrasjonsarbeidsbenk-120 og administrasjonskonsoll-160 sesjoner kan kun benyttes for å lese data. Konsollsesjoner forbundet med nodeadministratoren 1250 har tilgang til innholdet i oppbevaringstjenesten 520 som kjøres på den nodeadministratoren 1210. Når han arbeider med systemet 100, må brukeren kjøre nodeadministratoren 1210, en sesjon med administrasjonskonsollen 160 og en integrasjonssesjon med arbeidsbenken 120.

Noder

Som angitt ovenfor, og nå med henvisning også til figurene 13(a) til 13(c) sammen med figur 12, er en node 1310 en fysisk prosess som kjøres på en vert 1300 og støtter en eller flere tjenester. Hver node 1310 er en Java virtuell maskin (JVM) og gjenkjennes av operativsystemet som en javaw.exe prosess. Brukeren må opprette minst én node 1310 for hver vert 1300 hvor det kjøres en bedriftsapplikasjon som brukeren ønsker å integrere. Brukeren kan ha så mange noder 1310 som hans forretningskrav tilsier.

En tjeneste er et objekt som tilbyr produktfunksjonalitet. Systemet 100 omfatter generelt systemtjenester og applikasjonstjenester. Et grafisk klientbrukergrensesnitt (GUI), så som integrasjons-arbeidsbenken 120 og administrasjonskonsollen 160 lar brukeren jobbe med systemet 100. Klienter 1205 (figur 12) kan kjøres på den samme fysiske vertsmaskinen 1300 hvor noder 1310 og tjenester kjøres, eller de kan kjøres på en annen vertsmaskin 1200.

Hver bedrift må også ha en nodeadministrator 1210. Nodeadministratoren 1210 tilbyr tjenester til alle de andre nodene 1310 i systemet 100. Den kjører brukergrensesnittstjenesten (UIS) 1230 og oppbevaringstjenesten 1220. Figur 13(a) illustrerer et miljø med tre vertsmaskiner 1300. Vertsmaskin 1 kjøres nodeadministratoren 1210, mens vertsmaskin 2 og vertsmaskin 3 begge kjører noder 1310.

Systemet 100 er en samling av systemtjenester og applikasjonstjenester. Systemtjenester støtter noder og tjenester. For eksempel lagrer overvåkningstjenesten 1240 systemets kjøredata for noder 1310 og tjenester. Applikasjonstjenester tilbyr funksjonalitet til systemet 100. For eksempel støtter CICS agent-tjenestene adaptere som må forbindes med CICS applikasjoner.

Systemtjenester

Systemtjenester ifølge foreliggende oppfinnelse omfatter vanligvis en brukergrensesnittstjeneste (UIS) 1230, en oppbevaringstjeneste 1220 og en overvåkningstjeneste 1240. UIS 1230 tilbyr mer spesifikt de nødvendige hjelpemidler for å kjøre klientkomponenter (dvs. integrasjons-arbeidsbenken 120 og administrasjonskonsollen 160). Videre lagrer oppbevaringstjenesten 1220 konfigurasjonene for alle konfigurerte tjenester og integrasjonsflytobjekter 540. Til slutt lagrer overvåkningstjenesten 1240 systemets kjøredata, inklusive systemets logg- og statistikkinformasjon.

Applikasjonstjenester

Igjen med henvisning til figur 12, kan det sees at applikasjonstjenestene som anvendes i systemet 100 inkluderer bedriftsmeldingstjenesten (EMS) 1260, som muliggjør at systemet kan anvende forskjellige meldingsmodi, inklusive punkt-til-punkt, publisér/abonnér, og anmodning/svar meldingstjenester. EMS 1260 støtter også meldingshubber og tilbyr meldingspersistens. Applikasjonstjenester inkluderer også en integrasjonstjeneste (IS) 1270 som gjør at systemet 100 kan transformere meldinger, inklusive å dele opp meldinger, kombinere meldinger og manipulere data i meldinger. IS-en 1270 støtter i tillegg transformatorer. RMI fabrikktjenester (ikke vist) kan eventuelt anvendes som en applikasjonstjeneste for å styre linker for fjernprosedyrekall (RMI) til eksterne applikasjoner. Rutingstjenester 1280 omfatter også en applikasjonstjeneste som gjør et systemet 100 kan adressere meldinger gjennom systemet basert på en meldings innhold, inklusive filtrering av meldingsinnehold i henhold til brukerdefinerte kriterier og avgjørelse av hvorvidt meldinger er gyldige. Rutingstjenesten 1280 støtter også filtre. Agent-tjenester 1250 støtter adaptre. Brukeren må installere en agent-tjeneste på hver vertsmaskin 600 som kjører en bedriftsapplikasjon som han ønsker å integrere. Som vist i figur 13(b), kjører både Vertsmaskin 1 og Vertsmaskin 2 tjenester. Vertsmaskin 3 kan ikke kjøre tjenester fordi den ikke haren node 1310.

Klienter

Systemet 100 inkluderer to klient GUI-er som lar brukeren arbeide med integrasjonsflyter 540. Klienter kan kjøre på hvilken som helst vertsmaskin 1300, uavhengig av hvorvidt vertsmaskinen 1300 kjører nodeadministratoren 1210, kjører noder 1310 og tjenester eller ikke kjører noder 1310 eller tjenester. Brukeren kan installere så mange klienter som hans forretningskrav tilsier. For eksempel kan en bruker ønske å installere klienter 1205 på en nettverkstilknyttet vertsmaskin for å arbeide med sine integrasjonsflyter 540 fra et annet sted: I figur 13(c) kjører både Vertsmaskin 2 og Vertsmaskin 3 klientene administrasjonskonsoll 160 og integrasjons-arbeidsbenk 120. Vertsmaskin 1, på den annen side, kjører ingen av disse klientene.

Det er to primære grensesnitt innen systemet 100: (1) arbeidsbenken 120 og administrasjonskonsollen 160. Arbeidsbenken 120 tilbyr verktøy for å opprette og modifisere integrasjonsflyter 700, mens administrasjonskonsollen 160 tilbyr alt av verktøy for å styre systemets noder og tjenester. Begge er beskrevet i mer detalj senere i teksten.

Oppretting av en integrasjonsflyt 700 ifølge foreliggende oppfinnelse kan utføres som følger. Brukeren må først hente agent-tjenester fra systemet 100. Fra administrasjonskonsollen 160 konfigurerer brukeren deretter systemnodene for hver vertsmaskin hvor det kjøres en applikasjon som brukeren ønsker å integrere. Deretter konfigurerer brukeren de nødvendige tjenestene på nodene, inklusive en agent-tjeneste for hver applikasjon som brukeren skal integrere.

For å planlegge en integrasjonsflyt, må brukeren bestemme følgende faktorer. For eksempel så må brukeren bestemme hvilke typer data han trenger å ekstrahere fra applikasjoner og sende til applikasjoner. Brukeren må også tenke på: (1) hvordan han ønsker å rute meldinger blant systemobjekter; (2) hvordan han trenger å omdanne dataene fra en applikasjon slik at de kan brukes av en annen applikasjon; og (3) hvorvidt han trenger å filtrere visse data ut av flyten.

Transformasjonsprosess - Aksessorer oa Konvertere

Som angitt tidligere i teksten er en annen viktig funksjon for meldingsmodellen det å importere til og eksportere fra interne filformater fra en hvilken som helst applikasjon. Filer som inneholder både tegn- og binærdata i applikasjons- og plattformavhengige formater bringes på den beskrevne «kanoniske» formen, hvor data representeres som Java-objekter. Et nøkkelmål i designet av dette skjemaet er å maksimere gjenbruksmuligheten. Derfor kan en gitt meldingsdefinisjon spesialkonfigureres med noe som konseptuelt er en «maskinvare-driver». Det vil si at to interne filformater, som strukturelt representerer det samme dataformatet, kan produsere identisk strukturerte kanoniske meldinger når de konfigureres med riktige drivrutiner. «Maskinvare-driveren» er egentlig et sett Java-objekter kalt «aksessorer» og «konvertere», som tilknyttes sine noder i meldingsdeifnisjonens metadata og globale metadata.

En fullt konfigurert meldingsdefinisjon som har blitt gjort persistent via Java objektserialisering blir da en pakket og klar-til-å-kjøre formatparser og formatterer for en gitt internt filformat transformasjonsprosess som drar full nytte av de seneste tegnsettkoding og lokaliseringsfasiliteter som tilbys av Java Development Kit (JDK). Alle interne tegnstrenger betraktes som bigruppe- arrayer og konverteres internt til Unicode for anvendelse av parsings- og formatteringsrutiner.

Det kan bemerkes at versjon 1.1.6 av JDK støtter nesten 100 forskjellige tegnkodinger, og at meldingsmodellen ifølge foreliggende oppfinnelse håndterer alle disse med den samme logikken. Meldingsmodellen streber også etter å anvende arv av elementattributter så mye som mulig. Applikasjonsspesifikke data antas således å ha en standard bitgruppe-rekkefølge, innkoding og lokalitet. Individuelle aksessorer kan overskrive hvilke som helst av disse, men i praksis vil ikke dette skje så ofte.

Aksessorene og konverterne er to-veis objekter. De kan konvertere interne data til et Java-objekt som skal lagres i et meldingstre og kan også transformere et Java-objekt tilbake til sin interne representasjon. Med tanke på gjenbruksmuligheter, var et mål ved foreliggende oppfinnelse å minimere antallet transformasjonsklasser som måtte skrives. Transformasjonsprosessen beskrevet her kan således betraktes som et problem med to akser, symbolisering/formattering på den ene aksen, og bitgruppe-transformasjon på den andre. En instans av en aksessorklasse er et Java-objekt som vet hvordan det skal gå gjennom den «syntaktiske hjelpen» i et internt felt og isolere ut de faktisk bitgrupper som en spesifikk konverter trenger for å produsere eller konvertere fra et Java-objekt.

Betrakt for eksempel tilfellet hvor et flyttall-datafelt merkes på begge sider ved en predefinert bitgruppe- eller tegnsekvens. Disse er kjent som «markører» i system 100. En spesifikk type aksessor (i dette tilfellet en aksesor for endemarkører) vet at den skal hoppe over frontmarkøren og finne lokaliseringen til endemarkøren for å isolere de fire bitgruppene som faktisk er «kjøttet» i flyttallsdataene. Bitgruppe-konverteren for flyttall som er konfigurert i meldingsdefinisjonen produserer et Java Float-objekt fra bitgruppene. I den andre retningen skriver aksessoren ut den ledende markøren, ber konverteren skrive ut de interne bitgruppene og deretter avslutter aksessoren med endemarkøren. En spesiell fordel ved dette skjemaet er at det kun trenger å skrives en håndfull aksesorer og omtrent to dusin konvertere. Siden aksessorene og konverterne ifølge foreliggende oppfinnelse hovedsakelig kun kan leses etter at de er konfigurert, kan størrelsen på en meldingsdefinisjon holdes relativt liten på grunn av objektdeling der det er mulig. Javasøppeltømmeren fjerner hensiktsmessig anliggender om hvem som eier objektet i dette tilfellet.

Enkelte aksessorer og konvertere trenger å bli konfigurert med initielle settinger, mens andre ikke trenger det. Disse objektene pakkes som JavaBeans, med enkle egenskapsdialoger dersom det er nødvendig. Ifølge en nåværende foretrukken utførelsesform av oppfinnelsen, beskriver følgende tabell de aksessorene som støtter systemet 100. Etter hvert som det trengs nye typer, kan de sømløst legges til systemet 100 uten at det er behov for å skrive nye konvertere.

En bør merke seg at hver av aksessorene beskrevet ovenfor er felt-aksessorer. Selv om de er mye enklere, kan seksjonsaksessorer likeledes anvendes. Slike seksjonsaksessorer har eventuelt markører og kan også anvende et separatorskjema. Til en viss grad avhenger inkluderingen av et slikt separatorskjema av at dets inneholdte elementer kan parses. Separatorer anvender enten et prefiks-, infiks- eller postfiksskjema, og er de samme markørelementene som anvendes for å angi felter. Tabellaksessorer utvider seksjonsaksessorer til å arbeide med et linket felt som angir en postteller.

Det initielle antallet konvertere som støtter system 100 er relativt lite, men er veldig komplett basert på en analyse av kommersielle filformater. Konverterne ifølge foreliggende oppfinnelse omfatter to grunnleggende typer: enten en tegnbasert konverter eller en binærkonverter. Alle tegnkonvertere arver fra en felles baseklasse som frembringer metoder for plassering og innfylling av tegn. Slike innfyllingstegn kan spesifiseres som absolutt bitgruppe verditegn eller som Unicode tegn, som avbildes til den interne kodingen. Tegnkonvertere ifølge foreliggende oppfinnelse inkluderer:

Binærkonvertere arver den standard meldings-spesifiserte bitgruppe-rekkefølgen, men kan individuelt overskrive denne med et argument til konstruktoren. Disse binærkonverterne ifølge foreliggende oppfinnelse inkluderer:

Pakket desimal

Konvertere kan produsere eller konsumere mer enn én Java type. For eksempel kan en intern flyttallskonverter på en fornuftig måte konvertere til et flyttall, dobbelt flyttall, heltall, langt heltall eller en streng, blant annet. Alle konvertere implementerer et internt konverter-grensesnitt som spesifiserer en «Object load(Class,...)» og «void store(Object...)» funksjonalitet. Hvilken faktiske underklasse som produseres avhenger av hvilke andre konverter-grensesnitt som implementeres av objektet. Disse er hovedsakelig markør- grensesnitt, som ikke bidrar til noen nye klassefunksjoner. For eksempel kan en DoubleConverter, IntegerConverter, StringConverter og så videre anvendes i systemet 100 uten at en går ut over den faktiske tanken bak og rekkevidden av foreliggende oppfinnelse. Et konfigureringsverktøy, så som et grafisk brukergrensesnitt (GUI) kan, ved analyse av klassene, plukke ut en hensiktsmessig liste av konvertere for anvendelse i et spesifikt tilfelle. Inne i klassefunksjonene load og store, sjekker konverteren hvilke av dets støttede grensesnitt det implementerer som svarer til en klasse objektet er en instans av (instanceof) eller den gitte Class-parameteren. Det generiske objektet (Object) som returneres eller prosesseres er nå den rette undertypen.

Markører

Markører kan betraktes som syntaktisk sukker, nyttige som både feltseparatorer og individuelle feltsymboler. Alle objekter, om de er seksjoner eller felter, kan inkludere en ledende markør, endemarkør eller begge deler. Ifølge en nåværende foretrukken utførelsesform av oppfinnelsen, er det tre grunnleggende markørformater. To formater, kjent som en fast mønster markør og en «strtok»-stil markør, spesifiserer enten et bitgruppemønster eller en Unicode streng som konverteres til den interne tegnkodingen. Omfattende et sett av tegn hvorav 0 eller flere tegn finnes, er «strtok»-stil markøren nyttig for å indikere innfylling av blanke tegn eller binærtall. Det tredje formatet, nøkkel-baserte markører, har et mønster hvor nøkkelen til et objekt som prosesseres substitueres inn i et mønster. For eksempel ville markør-paret <X-> og </-X-> bli til <Kunder> og </Kunder>, hvilket ville være nyttig for å parse XML-stil meldinger og generelt som en hjelp for å lokalisere valgfrie tilleggsfelter.

Valgfrie tilleggsargumenter

Parsing og gjenkjenning av valgfrie tilleggsargumenter er en vanskelig prosess. For eksempel dersom inngangsdataene som spesifiseres er fem valgfrie tilleggsstrenger med en hvilken som helst lengde, og tre strenger er lest korrekt, kan det være umulig å skille strengene fra hverandre. Valgfrie tilleggsargumenter som ikke finnes vil bli satt til null i meldingen. Ett sett av betingelser for at valgfrie tilleggselementer kan gjenkjennes ifølge foreliggende oppfinnelse følger.

Betrakt tilfellet hvor en seksjon anvender separatorer og det detekteres en separator for et tomt felt. For eksempel ville en bruker vite at det andre argumentet mangler dersom inndataene var «Able,,Charley» i et infiks-skjema. Et annen betingelse for at valgfrie elementer kan gjenkjennes er når feltene anvender den nøkkel-baserte markøren for selv-identifikasjon. I stil med C++ funksjonsargumenter med gitt standardverdi, ville nok en betingelse være at dersom alle de valgfrie argumentene kommer på slutten av lista og slutten på seksjonen detekteres, gikk parsingen greit. Generelt, når brukeren ikke parser et felt korrekt, og dette feltet er valgfritt, hopper brukeren til neste felt og forsøker igjen inntil han når slutten av seksjonen. En seksjon med en endemarkør (eller et filslutt-tegn)) ville være nødvendig her. På slutten av seksjonen, dersom ikke obligatoriske felter er blitt tilordnet en verdi, er parsingen ikke korrekt. Dette ville ikke garantere korrekte resultater dersom formatet på suksessive felter ikke var entydig.

Standard utgangsverdier virker forskjellig, avhengig av hvorvidt dette er en seksjon eller et felt. Meldings-metadata for et felt inneholder et objekt som tilordnes som normalverdi. Som normalverdi, dersom objektet støtter cloneable-grensesnittet, klones objektet fra metadataene til meldingsinstansen. Dersom det ikke støtter dette grensesnittet, lagres verdien som en streng i metadataene, sammen med dets klasse, og Java Reflection API-et anvendes for å kalle objektets streng-baserte konstruktør for å supplere meldingen med et objekt. For seksjoner er normalverdien en link til en annen persistent lagret meldingsdefinisjon. Toppnivå-seksjonen for den refererte meldingsdefinisjonen ville bli overført til meldings-metadataene og det ville bli produsert en melding med den kombinerte strukturen.

Linkede og transiente felter

I noen tilfeller er interne data selvbeskrivende. For eksempel kan en tabell starte med dens radantall. Brukere ville imidlertid ikke ønske å inkludere denne telleren i den endelige kanoniske meldingen som produseres, fordi dette tallet er gitt ved lengden på Java-arrayet som representerer tabellen. I dette tilfellet kan noden eventuelt merkes som transient. Den blir midlertidig lagt til meldingen og fjernes med en gang tabellen er fylt og lagt inn. På denne måten kan brukeren konfigurere en meldingsdefinisjon med to forskjellige drivere for å produsere den samme kanoniske meldingen. Det vil si at dersom, i det ene tilfellet tabellengden ble bestemt uten tellerindikator, ville den ikke produsere det heltallsfeltet i noden. Tabeller må være isomorfe i dette tilfellet, slik at argumentet må være transient.

Mens vi fortsetter med eksempelet ovenfor, kan en merke seg at det er en naturlig forbindelse mellom telleren og tabellen. Som et resultat vil begge bli merket som å ha en link-relasjon. Begge vil i tillegg ta vare på det relative og det absolutte banenavnet til det andre objektet, pluss en statusindikator i deres aksessorer som vist nedenfor.

COUNT-PROVIDER

COUNT-USER

L ENGTH-PROVIDER

LENGTH-USER

REDEFINE-PROVIDER

REDEFINE-USER

I tilfellet med redefine frembringer provider en enten streng- eller heltallsdiskriminant. Provider-feltet må befinne seg, i parsingsretningen, før dens user ved traversering og transformasjon. I formatteringsretningen skrives provider først ut i form av en plassholder og fylles deretter ut med sin rette verdi. Det skal bemerkes count-provider må anvende et fast lengde-format for at det ovennevnte skal fungere.

Validerinasklausuler og Relasjoner

Meldingsdefinisjonen har plassholdere i sine metadata-felter for en liste av valideringsklausuler og relasjoner mellommeldinger. Ifølge en nåværende foretrukket utførelsesform av foreliggende oppfinnelse, kjøres ingen valideringsklausuler på den konverterte meldingen før etter at hele meldingen er konvertert. Objekt-designet tillater imidlertid per-felt valideringsklausuler om det er ønsket. Det er også en plassholder for å spesifisere relasjoner mellom kolonner i en tabell i en melding og kolonner i en annen. Dette forenkler avbildningen av verdier og sammenknytninger.

Fremgangsmåten for å opprette en melding, med eller uten konvertering av rådataene, er vist i figurene 13 og 14. Figur 13 illustrerer en fremgangsmåte 1340 uten å konvertere rådataene som begynner ved applikasjonen 541.

Brukeren oppretter en tom melding (f.eks. «DocDef.createNewlnstance») ved 1320, og den tomme meldingen fylles med applikasjonens data gjennom meldingsdefinisjons API-et 1330. En meldingsinstans blir således opprettet. Meldingsinstansen 1340 kan deretter gå gjennom en annen applikasjons meldingsdefinisjons-AP11350 for å sende meldingen til den applikasjonen 1360.

Når det oppstår behov for å konvertere rådataene, anvendes fremgangsmåten som vist i figur 14. I begynnelsen mottas applikasjonsspesifikke data 1410 fra en applikasjon 1420. En tom melding opprettes ved 1430 og fylles ikke bare med slike applikasjonsspesifikke data, men også med rå transformasjonsinformasjon. De applikasjonsspesifikke dataene 1410, ved hjelp av aksessorer og konvertere 1440, sendes til en meldingsinstans 1450, som også mottar informasjonen fylt inn i det tomme dokumentet ved 1430. Dette kan for eksempel gjøres med:

DocRef.createDocumentFromFile

API-et støtter begge følgende funksjoner for å opprette meldingen: DocRef.createDocumentFromFile DocRef. createDocu mentFrom Bytes

Deretter, gjennom andre aksessorer og konvertere 1460, kan meldingen konverteres til en annen applikasjons applikasjonsspesifikke data 1470 og mottas av den applikasjonen 1480.

Nå med henvisning til figurene 15(a) til 15(d), vil nå fordelene med meldingsobjektet ifølge foreliggende oppfinnelse bli beskrevet. Figur 15(a) illustrerer en fremgangsmåte 1510, ifølge foreliggende oppfinnelse, for å opprette en melding uten å konvertere rå applikasjonsdata.

En tom melding opprettes ved applikasjonen 1512 som et første trinn. Dette utføres ved å opprette en meldingsdefinisjon 512 (f.eks. «def;

//initialiseres et annet sted def.createemptydocument(docname);»). Applikasjonens API 1514 koples til meldingsdefinisjons API-et 1516 for å fylle opp meldingen ved anvendelse av meldingsdefinisjons API-et 1516. Meldingens standard utgangsverdier kan deretter anvendes (f.eks. «def.applyDocumentDefaultValues(docname)») og en melding blir således opprettet. Den reverse funksjonen 1520 er vist i figur 15(b), hvor meldingsinstansen 1522 sendes gjennom meldingsdefinisjons API-et 1524, som er koplet til applikasjons API-et 1526, og anvendes for å fylle opp feltverdiene. Meldingen sendes deretter til applikasjonen 1528.

Oppretting av meldinger med konvertering av applikasjonsdata er vanskeligere. Som vist i figur 15(c), begynner en fremgangsmåte 1530, ifølge foreliggende oppfinnelse, for å konvertere meldinger fra en applikasjon 1532 til en meldingsinstans 1538 med at meldingen sendes fra applikasjonen 1532 gjennom en konverter. Meldingsdefinisjons API-et 1536 oppretter en tom melding, fyller opp den tomme meldingen med dataene fra applikasjonen 1532 (dvs. enten fra en fil eller fra bitgrupper) og legger til rå konverteringsinformasjon fra aksessorer og konvertere ifølge foreliggende oppfinnelse. For eksempel: Document Definition def, // Legg til Aksessorer og Konvertere Initialisering et annet sted

def.createDocumentFromFile(docname,r7/ename)

eller

def.createDocumentFromBytes(docname,byte[])

Den reverserte fremgangsmåten 1540 er vist i figur 15(d), hvor en meldingsinstans 1542 sendes gjennom meldingsdefinisjons API-et 1544 for å fylle opp en fil eller et bitgruppe-array 1546 med dataene fra meldingsinstansen 1532 og deretter til applikasjonen 1548. For eksempel: Document Definition def; // Legg til Aksessorer og Konvertere Initialisering et annet sted

def.storeDocumentToFile(/7/ena/77e)

eller

def.storeDocumentToBytes(byte[])

Klassediagrammer for tilsvarende slike prosesser er vist i figurene 16 og 17.

Ifølge et annet viktig aspekt ved foreliggende oppfinnelse omfatter system 100 et distribuert system. Det vil si at brukeren kan kjøre systemkomponentene som utgjør systemet 100 på en eller flere fysiske maskiner (dvs. vertsmaskiner), mens alle komponentene fortsatt virker sammen som én applikasjon. Enhver komponent i systemet 100 kan distribueres mellom alle støttede plattformer. Agent-adaptere 200 utvider dette på en fleksibel måte til alle deltagende applikasjoner. Nøkkelkomponenter i systemet 100 (f.eks. agent-adaptere 200 eller integrasjonstjener 26) kan således være lokalisert sammen med applikasjoner, fjernaksesseres, eller begge deler. Mange brukskonfigurasjoner er mulige - miljøet er optimert for å balansere tilgjengelighet, ytelse og administrasjonskrav.

Operatorer

Følgende tabell beskriver generelt alle de på det nåværende tidspunkt forventede systemoperatorer som en bruker kan anvende for å sette sammen uttrykk for meldingsdefinisjoner, transformasjonsdefinisjoner og filterdefinisjoner. Systemet 100 støtter disse operatorene.

Funksjoner

Tabellen som følger på neste side beskriver generelt alle de på det nåværende tidspunkt forventede systemfunksjonene som en bruker kan anvende for å bygge uttrykk for å validere eller filtrere meldinger og transformere meldingsdata. Hver beskrivelse inkluderer hva funksjonen gjør, hvilke parametre den tar og verdien den returnerer.

Når han transformerer meldingsdata, anvender brukeren typisk disse funksjonene for å ta verdier fra meldingsfelt i inngangsmeldingene og skape verdier til meldingsfeltene i utgangsmeldingene. Når han validerer eller filtrerer meldinger, anvender brukeren vanligvis disse funksjonene for å lage boolske uttrykk. Parameterverdiene for disse funksjonene kan enten være meldingsfelter eller konstanter (dvs. bokstavelige) verdier.

Systemet 100 tilbyr også funksjonene beskrevet nedenfor, selv om en bruker kan skrive sine egne funksjoner for anvendelse med systemet 100.

addfoDate

Denne funksjonen legger et Long-objekt, som spesifiserer et antall dager, til datoen i et Calendar-objekt og returnerer den resulterende datoen i Calendar-objektet.

Calendar addtoDate(Calendar.Long)

Eksempel: Et meldingsfelt med navn DatePurchased er definert som et Calendar-objekt. For en annen melding trenger brukeren verdien til DatePurchased pluss fem dager i et Calendar-objekt. Brukeren ville da kalle funksjonen som følger:

addToDate (MsgDef.DatePurchased,5)

Dersom verdien i DatePurchased var ekvivalent med 13. Februar, 2000, ville funksjonen returnere et Calendar-objekt hvis verdi var ekvivalent med 18. Februar, 2000.

bigDecimalToBoolean

Denne funksjonen konverterer et BigDecimal-objekt til et Boolean-objekt. Boolean bigDecimalToBoolean(BigDecimal)

bigDecimalToDouble

Denne funksjonen konverterer et BigDecimal-objekt til et Double-objekt. Double bigDecimalToDouble(BigDecimal)

bigPecimalToLonq

Denne funksjonen konverterer et BigDecimal-objekt til et Long-objekt. Long bigDecimalToLong(BigDecimal)

bi<g>PecimalToStrin<q>

Denne funksjonen konverterer et BigDecimal-objekt til et String-objekt. String bigDecimalToString(BigDecimal)

booleanToBi<q>Pecimal

Denne funksjonen konverterer et Boolean-objekt til et BigPecimal-objekt. BigDecimal booleanToBigDecimal(Boolean)

booleanToLong

Penne funksjonen konverterer et Boolean-objekt til et Long-objekt. Long booleanToLong(Boolean)

booleanToStrin<q>

Penne funksjonen konverterer et Boolean-objekt til et String-objekt. String booleanToString(BigDecimal)

calendarToString

Det er to versjoner av denne funksjonen.

Den følgende funksjonen konverterer et Calendar-objekt til et String-objekt.

String calendarToString(Calendar)

Den følgende funksjonen konverterer et Calendar-objekt til et String-objekt, ved anvendelse av en formatmaske for å formattere String-objektet.

String calendarToString(Calendar,String)

Eksempel:

Et meldingsfelt med navnet DatePurchased er definert som et Calendar-objekt. For en annen melding trenger brukeren verdien i DatePurchased i et String-objekt, i formatet M/d/yyyy. Brukeren ville da kalle funksjonen som følger:

calendarToString (MsgDef.DatePurchased,«M/d/yyyy»)

Dersom verdien i DatePurchased var ekvivalent med 13. Februar, 2000, ville funksjonen returnere et String-objekt med verdien «2/13/2000».

compareDates

Denne funksjonen sammenlikner to Calendar-objekter sine datoer og angir hvorvidt den første datoen er mindre enn, lik eller større enn den andre datoen.

Long compareDates(Calendar,Calendar)

doubleToBi<q>Decimal

Denne funksjonen konverterer et Double-objekt til et BigDecimal-objekt.

BigDecimal doubleToBigDecimal(Double)

doubleToLonq

Denne funksjonen konverterer et Double-objekt til et Long-objekt. Long doubleToLong(Double)

doubleToStrinq

Det er to versjoner av denne funksjonen.

Den følgende funksjonen konverterer et Double-objekt til et String-objekt. String doubleToString(Double)

Den følgende funksjonen konverterer et Double-objekt til et String-objekt, ved anvendelse av en formatteringsmaske for å formattere String-objektet.

String doubleToString(Double,String)

Eksempel:

Et meldingsfelt med navnet Discount er definert som et Double-objekt. For en annen melding trenger brukeren verdien i Discount i et String-objekt, i formatet #.##. Brukeren ville da kalle funksjonen som følger:

doubleToString(MsgDef.Discount,«#.##»)

Dersom verdien i Discount var 0.04531, ville funksjonen returnere et String-objekt med verdien «0.05».

findStrin<q>

Denne funksjonen søker etter et String-objekt i et annet String-objekt. Dersom funksjonen finner det spesifiserte String-objektet, returnerer den posisjonen til strengens første tegn i den andre strengen.

Long findString(String,String)

findWord

Denne funksjonen søker etter et ord i et String-objekt. Dersom funksjonen finner det spesifiserte ordet, returnerer den posisjonen til ordets første tegn i String-objektet. Funksjonen kan kun finne ordet når det er omgitt av blanke i String-objektet.

Long findWord(String,String)

foundString

Denne funksjonen søker etter et String-objekt i et annet String-objekt og returnerer et Boolean-objekt.

Boolean foundString(String,String)

foundWord

Denne funksjonen søker etter et ord i et String-objekt og returnerer et Boolean-objekt. Funksjonen kan kun finne ordet når det er omgitt av blanke i strengen.

Boolean foundWord(String,String)

getDate

Penne funksjonen finner datoen i et Calendar-objekt og returnerer datoen som et Integer-objekt.

Integer getDate(Calendar)

Eksempel:

Et meldingselement med navn PatePurchased er definert som et Calendar-objekt. For en annen melding trenger brukeren datoen fra verdien i PatePurchased i et Integer-objekt. Brukeren ville da kalle funksjonen som følger:

GetPate(MsgPef.PatePurchased)

Persom verdien i PatePurchased var identisk med 13. februar, 2000, ville funksjonen returnere et Integer-objekt med verdien 13.

getMonth

Penne funksjonen finner måneden i et Calendar-objekt og returnerer måneden som et Integer-objekt.

Integer getMonth(Calendar)

Eksempel:

Et meldingselement med navn DatePurchased er definert som et Calendar-objekt. For en annen melding trenger brukeren måneden fra verdien i DatePurchased i et Integer-objekt. Brukeren ville da kalle funksjonen som følger:

GetMonth(MsgDef.DatePurchased)

Dersom verdien i DatePurchased var identisk med 13. februar, 2000, ville funksjonen returnere et Integer-objekt med verdien 2.

getTokenAt

Det er to versjoner av denne funksjonen.

Den følgende funksjonen deler inn et String-objekt i symboler, finner et spesifikt symbol og returnerer det som et String-objekt. Funksjonen antar at et komma separerer symbolene og lar brukeren angi posisjonen til symbolet som skal returneres. Dersom String-objektet som skal parses inneholder en nullverdi eller den spesifiserte posisjonen ikke ligger i et gyldig intervall, returnerer funksjonen en nullverdi.

String getTokenAt(String,Integer)

Den følgende funksjonen deler inn et String-objekt i symboler, finner et spesifikt symbol og returnerer det som et String-objekt. Funksjonen lar brukeren spesifisere hvilket tegn som separerer symbolene og lar brukeren angi posisjonen til symbolet som skal finnes.

Dersom String-objektet som skal parses inneholder en nullverdi eller den spesifiserte posisjonen ikke ligger i et gyldig intervall, returnerer funksjonen en nullverdi.

String getTokenAt(String,String,Integer)

Eksempler:

(1) Et meldingsfelt med navnet Date er definert som et String-objekt som inneholder en dato i formatet M/d/yy. For en annen melding trenger brukeren måneden fra verdien i Date i et String-objekt. Brukeren ville da kalle funksjonen som følger:

getTokenAt(Msg Def. Date,«/»,0)

Dersom Date inneholdt 2/13/00, ville funksjonen returnere et String-objekt med verdien «2». (2) Et meldingsfelt med navnet Date er definert som et String-objekt som inneholder en dato i formatet MM.dd.yy. For en annen melding trenger brukeren datoen fra verdien i Date i et String-objekt. Brukeren ville da kalle funksjonen som følger:

getToken At(Msg Def. Date,«/», 1)

Dersom Date inneholdt 02.13.00, ville funksjonen returnere et String-objekt med verdien «13». (3) Et meldingsfelt med navnet Date er definert som et String-objekt som inneholder en dato i formatet M/d/yyyy. For en annen melding trenger brukeren året fra verdien i Date i et String-objekt. Brukeren ville da kalle funksjonen som følger:

getTokenAtMonth(Msg Def. Date,«/»,2)

Dersom Date inneholdt 2/13/2000, ville funksjonen returnere et String-objekt med verdien «2000».

qetYear

Denne funksjonen finner året i et Calendar-objekt og returnerer året som et Integer-objekt.

Integer getYear(Calendar)

Eksempel:

Et meldingselement med navn DatePurchased er definert som et Calendar-objekt. For en annen melding trenger brukeren året fra verdien i DatePurchased i et Integer-objekt. Brukeren ville da kalle funksjonen som følger:

getYear(MsgDef. DatePurchased)

Dersom verdien i DatePurchased var identisk med 13. februar, 2000, ville funksjonen returnere et Integer-objekt med verdien 2000.

inte<g>erToStrin<q>

Det er to versjoner av denne funksjonen.

Den følgende funksjonen konverterer et Integer-objekt til et String-objekt.

String integerToString(lnteger)

Den følgende funksjonen konverterer et Integer-objekt til et String-objekt, ved anvendelse av en formatteringsmaske for å formattere String-objektet.

String integerToString(lnteger,String)

Eksempel:

Et meldingsfelt med navnet Quantity er definert som et Integer-objekt. For en annen melding trenger brukeren verdien i Quantity i et String-objekt, i formatet Brukeren ville da kalle funksjonen som følger:

integerToString(MsgDef.Quantity,«#,###»)

Dersom verdien i Quantity var 2540, ville funksjonen returnere et String-objekt med verdien «2,540».

isAlpha

Denne funksjonen avgjør hvorvidt alle tegn i et String-objekt er alfabet-tegn og returnerer et Boolean-objekt.

Boolean isAlpha(String)

isAlphaNumeric

Denne funksjonen avgjør hvorvidt alle tegn i et String-objekt er alfanumeriske og returnerer et Boolean-objekt.

Boolean isAlphaNumeric(String)

isNumeric

Denne funksjonen avgjør hvorvidt alle tegn i et String-objekt er numeriske og returnerer et Boolean-objekt.

Boolean isNumeric(String)

iustifvCenter

Det er to versjoner av denne funksjonen.

Den følgende funksjonen oppretter et String-objekt med lengde angitt av et Integer-objekt og sentrerer et String-objekt i det. Dersom den sentrerte strengen er kortere enn den spesifiserte lengden, fyller funksjonen opp strengen på hver side med et likt antall blanke tegn.

Dersom den sentrerte strengen er lengre enn den spesifiserte lengden, returnerer funksjonen en nullverdi.

String justifyCenter(String,Integer)

Den følgende funksjonen oppretter et String-objekt med lengde angitt av et Integer-objekt og sentrerer et String-objekt i det. Dersom den sentrerte strengen er kortere enn den spesifiserte lengden, fyller funksjonen opp strengen på hver side med et likt antall tegn som spesifisert i en annen streng.

Dersom den sentrerte strengen er lengre enn den spesifiserte lengden, returnerer funksjonen en nullverdi.

String justifyCenter(String,lnteger,String)

Eksempel:

Et meldingselement med navnet Name er definert som et String-objekt. For en annen melding trenger brukeren verdien i Name, sentrert i et String-objekt med lengde 20, og om nødvendig fylt opp med asterisker (<*>). Brukeren ville da kalle funksjonen som følger:

justifyCenter(MsgDef.Name,20,«<*>»)

Dersom verdien i navn var «Wolfgang A. Mozart» ville funksjonen returnere et String-objekt med verdien «<*>Wolfgang A. Mozart<*>».

iustifyLeft

Det er to versjoner av denne funksjonen.

Den følgende funksjonen oppretter et String-objekt med lengde angitt av et Integer-objekt og venstrejusterer et String-objekt i det. Dersom den venstrejusterte strengen er kortere enn den spesifiserte lengden, fyller funksjonen opp strengen fra høyre med blanke tegn.

Dersom den venstrejusterte strengen er lengre enn den spesifiserte lengden, returnerer funksjonen en nullverdi.

String justifyl_eft(String,lnteger)

Den følgende funksjonen oppretter et String-objekt med lengde angitt av et Integer-objekt og venstrejusterer et String-objekt i det. Dersom den venstrejusterte strengen er kortere enn den spesifiserte lengden, fyller funksjonen opp strengen fra høyre med tegn som spesifisert i en annen streng.

Dersom den venstrejusterte strengen er lengre enn den spesifiserte lengden, returnerer funksjonen en nullverdi.

String justifyLeft(String,lnteger,String)

Eksempel:

Et meldingselement med navnet Name er definert som et String-objekt. For en annen melding trenger brukeren verdien i Name, venstrejustert i et String-objekt med lengde 20, og om nødvendig fylt opp med blanke. Brukeren ville da kalle funksjonen som følger:

justifyLeft(MsgDef.Name,20,«<*>»)

Dersom verdien i Name var «Frantz Schubert» ville funksjonen returnere et String-objekt med verdien «Franz Shubert».

justifvRight

Det er to versjoner av denne funksjonen.

Den følgende funksjonen oppretter et String-objekt med lengde angitt av et Integer-objekt og høyrejusterer et String-objekt i det. Dersom den høyrejusterte strengen er kortere enn den spesifiserte lengden, fyller funksjonen opp strengen fra venstre med blanke tegn.

Dersom den høyrejusterte strengen er lengre enn den spesifiserte lengden, returnerer funksjonen en nullverdi.

String justifyRight(String,Integer)

Den følgende funksjonen oppretter et String-objekt med lengde angitt av et Integer-objekt og høyrejusterer et String-objekt i det. Dersom den høyrejusterte strengen er kortere enn den spesifiserte lengden, fyller funksjonen opp strengen fra venstre med tegn som spesifisert i en annen streng.

Dersom den høyrejusterte strengen er lengre enn den spesifiserte lengden, returnerer funksjonen en nullverdi.

String justifyRight(String,lnteger,String)

Eksempel:

Et meldingselement med navnet Name er definert som et String-objekt. For en annen melding trenger brukeren verdien i Name, høyrejustert i et String-objekt med lengde 20, og om nødvendig fylt opp med asterisker (<*>). Brukeren ville da kalle funksjonen som følger:

JustifyRight(MsgDef.Name,20,«<*>»)

Dersom verdien i Name var «Sergei Rachmaninoff» ville funksjonen returnere et String-objekt med verdien «<*>Sergei Rachmaninoff».

longToBigDecimal

Denne funksjonen konverterer et Long-objekt til et BigDecimal-objekt. BigDecimal longToBigDecimal(Long)

lonqToBoolean

Denne funksjonen konverterer et Long-objekt til et Boolean-objekt. Boolean longToBoolean(Long)

lon<q>ToDouble

Denne funksjonen konverterer et Long-objekt til et Double-objekt. Double longToDouble(Long)

lon<q>ToStrin<q>

Det er to versjoner av denne funksjonen.

Den følgende funksjonen konverterer et Long-objekt til et String-objekt.

String longToString(Long)

Den følgende funksjonen konverterer et Long-objekt til et String-objekt, ved anvendelse av en formatteringsmaske for å formattere String-objektet.

String longToString(Long,String)

Eksempel:

En meldingselement med navn CustID er definert som et Long-objekt. For en annen melding trenger brukeren verdien i CustID i et String-objekt, i formatet Brukeren ville da kalle funksjonen som følger:

longToString (MsgDef.CustID, «##,###»)

Dersom verdien i CustID var 10321, ville funksjonen returnere et Sting-objekt med verdien «10,321».

lookup

Det er to versjoner av denne funksjonen.

Den følgende funksjonen finner et String-objekt i en oppslagstabell spesifisert i et annet String-objekt og returnerer den tilhørende verdien. Dersom funksjonen ikke finner en tilhørende verdi i oppslagstabellen, returnerer den en nullverdi.

String lookup(String,String)

Den følgende funksjonen finner et String-objekt i en oppslagstabell spesifisert i et annet String-objekt og returnerer den tilhørende verdien. Dersom funksjonen ikke finner en tilhørende verdi i oppslagstabellen, returnerer den en standardverdi spesifisert i et tredje String-objekt.

String lookup(String,String,String)

Eksempel:

Et meldingselement med navnet State er definert som et String-objekt. State inneholder alltid en tobokstavers forkortelse for navnet til én av tre stater i USA. For en annen melding trenger brukeren statens fulle navn i et String-objekt. Dersom ingen fulle navn tilsvarer forkortelsen, ønsker brukeren at String-objektet skal inneholde «N/A». Brukeren ville da anvende funksjonen som følger: lookup(MsgDef.State, «MD=Maryl_and, PA=Pennysylvania,

VA=virginia»,« N/A»)

Dersom verdien i State var «VA» ville funksjonen returnere et String-objekt med verdien «Virginia».

Iowercase

Denne funksjonen konverterer alle tegn i et String-objekt til nedre tegnsett. String lowercase(String)

replaceString

Denne funksjonen søker gjennom et String-objekt etter et spesifikt String-objekt, erstatter det funnede String-objektet med et annet String-objekt og returnerer String-objektet med den erstattede strengen.

Dersom funksjonen ikke finner strengen den skal erstatte, returnerer den String-objektet den søkte i uten å endre det.

String replaceString(String,String,String)

Eksempel:

Et meldingselement med navn Address er definert som et String-objekt. For adresser i staten Virginia, inkluderer av og til verdien i Address tobokstav-forkortelsen VA. For en annen melding trenger brukeren et String-objekt som inneholder verdien i Address, men med det fulle navnet erstattet for forkortelsen. Brukeren ville da kalle funksjonen som følger:

replaceString(«VA», «Virginia», MsgDef.Address)

Dersom verdien i Address var «Reston, VA 20191», ville funksjonen returnere et String-objekt med verdien «Reston, Virginia 20191».

replaceWord

Denne funksjonen søker gjennom et String-objekt etter et spesifikt ord, erstatter det funnede ordet med et annet ord og returnerer String-objektet med erstatningsordet på plass.

Funksjonen kan bare finne det spesifikke ordet i String-objektet dersom ordet: (1) har blanke tegn foran og etter seg; (2) er venstrejustert i String-objektet og etterfølges av et blankt tegn; og (3) er høyrejustert i String-objektet og har et blankt tegn foran seg. Dersom funksjonen ikke finner ordet, returnerer den String-objektet den søkte i uten å endre det.

String replaceWord(String,String,String)

Eksempel: Et meldingselement med navn Address er definert som et String-objekt. For adresser i staten Maryland, inkluderer av og til verdien i Address tobokstav-forkortelsen MD. For en annen melding trenger brukeren et String-objekt som inneholder verdien i Address, men med det fulle navnet erstattet for forkortelsen. Brukeren ville da kalle funksjonen som følger:

replaceWord(«MD», «Maryland», Msg Def .Address)

Dersom verdien i Address var «Bethesda, MD 20904», ville funksjonen returnere et String-objekt med verdien «Bethesda, Maryland 20904».

sizeOf

Det er to versjoner av denne funksjonen.

Den følgende funksjonen bestemmer størrelsen til et String-objekt og returnerer størrelsen som et Long-objekt.

Long sizeOf(String)

Den følgende funksjonen bestemmer størrelsen til et ByteArray-objekt og returnerer størrelsen som et Long-objekt.

Long sizeOf(ByteArray)

strinqToBigDecimal

Denne funksjonen konverterer et String-objekt til et BigDecimal-objekt.

BigDecimal stringToBigDecimal(String)

stringToBoolean

Denne funksjonen konverterer et String-objekt til et Boolean-objekt.

Boolean stringToBoolean(String)

strinqToCalendar

Det er to versjoner av denne funksjonen.

Den følgende funksjonen konverterer et String-objekt til et Calendar-objekt.

stringToCalendar(String)

Den følgende funksjonen konverterer et String-objekt til et Calendar-objekt, ved anvendelse av en formatmaske for å interpretere String-objektet.

Calendar stringToCalendar(String,String)

Eksempel:

Et meldingselement med navn DatePurchased er definert som et String-objekt som inneholder en dato i formatet M/d/yy. For en annen melding trenger brukeren Calendar-ekvivalenten til verdien i DatePurchased i et Calendar-objekt. Brukeren ville da kalle funksjonen som følger: stringToCalendar (MsgDef.datePurchased,«M/d/yy») Dersom verdien i DatePurchased var «2/13/00», ville funksjonen returnere et Calendar-objekt med en verdi ekvivalent med 13. februar, 2000.

stringToDouble

Det er to versjoner av denne funksjonen.

Den følgende funksjonen konverterer et String-objekt til et Double-objekt.

Double stringToDouble(String)

Den følgende funksjonen konverterer et String-objekt til et Double-objekt, ved anvendelse av en formatmaske for å interpretere String-objektet.

Double stringToDouble(String,String)

Eksempel:

Et meldingselement med navn TotalCost er definert som et String-objekt som inneholder et dollarbeløp i formatet For en annen melding trenger brukeren verdien i TotalCost i et Double-objekt. Brukeren ville da kalle på funksjonen som følger:

stringToDouble(MsgDef.TotalCost,«##,###.##»)

Dersom verdien i TotalCost var «5,137.29» ville funksjonen returnere et Double-objekt med verdien 5137,29.

strinqTolnteqer

Det er to versjoner av denne funksjonen.

Den følgende funksjonen konverterer et String-objekt til et Integer-objekt.

Integer stringTolnteger(String)

Den følgende funksjonen konverterer et String-objekt til et Integer-objekt, ved anvendelse av en formatmaske for å interpretere String-objektet.

Integer stringTolnteger(String,String)

Eksempel:

Et meldingselement med navn Quantity er definert som et String-objekt som inneholder en mengde i formatet For en annen melding trenger brukeren verdien i Quantity i et Integer-objekt. Brukeren ville da kalle på funksjonen som følger:

stringTolnteger(MsgDef.Quantity,«#,###»)

Dersom verdien i TotalCost var «2,540» ville funksjonen returnere et Integer-objekt med verdien 2540.

stringToLonq

Det er to versjoner av denne funksjonen.

Den følgende funksjonen konverterer et String-objekt til et Long-objekt. Long stringToLong(String)

Den følgende funksjonen konverterer et String-objekt til et Long-objekt, ved anvendelse av en formatmaske for å interpretere String-objektet.

Long stringToLong(String,String)

Eksempel:

Et meldingselement med navn CustID er definert som et String-objekt som inneholder et tall i formatet For en annen melding trenger brukeren verdien i CustID i et Long-objekt. Brukeren ville da kalle på funksjonen som følger:

stringToLong(MsgDef.CustlD, »##,###»)

Dersom verdien i TotalCost var «10,321» ville funksjonen returnere et Long-objekt med verdien 10321.

subarrav

Denne funksjonen finner et ByteArray-objekt innen et annet ByteArray-objekt og returnerer det funnede ByteArray-objektet.

Dersom funksjonen ikke finner ByteArray-objektet, returnerer den en nullverdi.

ByteArray subarray(Long,Long,ByteArray)

Eksempel:

Et meldingselement med navn Array er definert som et ByteArray-objekt. For en annen melding trenger brukeren de første åtte bitgruppene i Array i et ByteArray-objekt. Brukeren ville da kalle på funksjonen som følger:

subArray(0,7,MsgDef .Array)

substring

Denne funksjonen finner et String-objekt innen et annet String-objekt og returnerer det funnede String-objektet.

Dersom funksjonen ikke kan finne strengen, returnerer den en nullverdi. String subString(Long,Long,String)

trim

Denne funksjonen fjerner blanke tegn før og etter et String-objekt. String trim(String)

uppercase

Denne funksjonen konverterer alle tegn i et String-objekt til øvre tastesett.

String uppercase(String)

Eksemplene vist og illustrert ovenfor i teksten er ikke ment å begrense oppfinnelsens rekkevidde. Modifikasjoner og variasjoner ifølge foreliggende oppfinnelse vil således sees av de med ordinære kunnskaper innen teknikken, uten at en går utover tanken bak og rekkevidden til de etterfølgende patentkravene.

Claims (29)

1. System for å integrere et mangfold datamaskin-applikasjoner, karakterisert ved at det omfatter: et meldingssystem for bedrifter, idet nevnte meldingssystem sender meldinger mellom nevnte datamaskin-applikasjoner; et database-lagringssystem koplet til nevnte meldingssystem for bedrifter, idet nevnte database-lagringssystem lagrer et mangfold datatransformasjons-konfigurasjoner og et mangfold regler; en integrasjonstjeneste koplet til nevnte meldingssystem for bedrifter, idet nevnte integrasjonstjener omfatter en datatransformasjonsmotor som anvender datatransformasjons-konfigurasjonene lagret i nevnte database-lagringssystem og en regelevalueringsmotor som anvender reglene lagret i nevnte database-lagringssystem; et mangfold agent-adaptere koplet til nevnte meldingssystem for bedrifter, idet hver adapter er koplet til én respektiv blant nevnte datamaskin-applikasjoner, og hver agent-adapter sender meldinger mellom nevnte meldingssystem for bedrifter og nevnte respektive datamaskin-applikasjon; og et meldingsskjema som opererer i samarbeid med nevnte agent-adaptere for å parse individuelle meldingselementer fra datamaskin-applikasjonene.

2. System ifølge krav 1, karakterisert ved at nevnte integrasjonstjeneste-system splitter opp og kombinerer meldinger mottatt fra nevnte meldingssystem for bedrifter og utfører innholdsbasert ruting av meldinger til nevnte datamaskin-applikasjoner.

3. System ifølge krav 1, karakterisert ved at hver nevnte agent-adaptere oversetter meldinger som sendes fra nevnte meldingssystem for bedrifter til nevnte respektive datamaskin-applikasjon fra et systemformat til et respektivt applikasjonsformat, og ved at det oversetter meldinger som sendes fra nevnte respektive datamaskin-applikasjon til nevnte bedrifts-meldingssystem fra det respektive applikasjonsformatet til systemformatet.

4. System ifølge krav 1, karakterisert ved at hver nevnte agent-adapter videre sender meldinger mellom andre nevnte agent-adaptere og nevnte respektive datamaskin-applikasjon.

5. System ifølge krav 1, karakterisert ved at hver nevnte agent-adapter omfatter en adapterdel og en agentdel som innkapsler nevnte adapterdel.

6. System ifølge krav 1, karakterisert ved at hver nevnte agent-adapter omfatter én eller flere adapterdeler og en agentdel som innkapsler alle de nevnte én eller flere adapterdeler.

7. Forbedret bedriftsapplikasjon-integreringssystem som inkluderer en agent-adapter for bruk i dette, karakterisert ved at forbedringen omfatter: en adapter konfigurert for én utvalgt blant bedriftsapplikasjonene; en agent-tjeneste som er vert for nevnte adapter; en meldingsdefinisjon for hver av et mangfold meldinger som nevnte adapter vil produsere, motta eller svare på; anordninger for å forbinde nevnte adapter til nevnte utvalgte bedriftsapplikasjon; og anordninger for å implementere nevnte adapter gjennom nevnte forbindelsesanordning.

8. Forbedring ifølge krav 7, karakterisert ved at nevnte adapter velges blant gruppen bestående av en kildeadapter, en destinasjonsadapter, en svaradapter og en anmoderadapter.

9. Fremgangsmåte for å sende meldinger mellom en første datamaskin-applikasjon og en andre datamaskin-applikasjon, karakterisert ved at den omfatter trinnene med å: frembringe en første melding med første data fra nevnte første datamaskin-applikasjon; publisere nevnte første melding for å oppnå en første publisert melding; konvertere nevnte første data i nevnte første publiserte melding til andre data for å oppnå en andre melding; publisere nevnte andre melding for å oppnå en andre publisert melding; og overføre nevnte andre publiserte melding til nevnte andre datamaskin-applikasjon.

10. Fremgangsmåte ifølge krav 9, karakterisert ved at den videre omfatter trinnene med å: oversette nevnte første melding fra formatet til en første datamaskin-applikasjon til et systemformat før nevnte første melding publiseres; og oversette nevnte andre publiserte melding fra nevnte systemformat til et format for en andre datamaskin-applikasjon før nevnte andre publiserte melding leveres til nevnte andre datamaskin-applikasjon.

11. Fremgangsmåte ifølge krav 9, karakterisert ved at nevnte trinn med å konvertere nevnte første data omfatter: be om nevnte andre data fra en database; og motta nevnte andre data fra nevnte database.

12. Agent-adapter for anvendelse i et bedriftsapplikasjon-integreringssystem som integrerer et mangfold applikasjoner, karakterisert ved at den omfatter: en adapter konfigurert for én utvalgt blant bedriftsapplikasjonene; en agent-tjeneste som er vert for nevnte adapter, en meldingsdefinisjon for hver av et mangfold meldinger nevnte adapter vil produsere, motta eller svare på; anordninger for å forbinde nevnte adapter til nevnte utvalgte bedriftsapplikasjon; og anordninger for å implementere nevnte adapter gjennom nevnte forbindelsesanordning.

13. Agent-adapter ifølge krav 12, karakterisert ved at nevnte adapter velges blant gruppen bestående av en kildeadapter, en destinasjonsadapter, en svaradapter og en anmoderadapter.

14. Agent-adapter ifølge krav 13, karakterisert ved at nevnte adapter omfatter en kildeadapter og videre omfatter anordninger for å angi utvalgte blant et mangfold destinasjoner som nevnte kildeadapter er tilpasset for å sende én eller flere meldinger til.

15. Agent-adapter ifølge krav 13, karakterisert ved at nevnte adapter omfatter en destinasjonsadapter og videre omfatter anordninger for å angi utvalgte blant et mangfold kilder som nevnte destinasjonsadapter er tilpasset for å motta én eller flere meldinger fra.

16. Agent-adapter ifølge krav 13, karakterisert ved at nevnte adapter omfatter en svaradapter og videre omfatter anordninger for å angi utvalgte blant et mangfold anmodere som nevnte svaradapter er tilpasset for å sende én eller flere svarmeldinger til.

17. Fremgangsmåte for å sende meldinger mellom en første datamaskin-applikasjon og en andre datamaskin-applikasjon, karakterisert ved at den omfatter trinnene med å: frembringe en første melding med første data fra nevnte første datamaskin-applikasjon; publisere nevnte første melding for å oppnå en første publisert melding; konvertere nevnte første data i nevnte første publiserte melding til andre data for å oppnå en andre melding; publisere nevnte andre melding for å oppnå en andre publisert melding; og overføre nevnte andre publiserte melding til nevnte andre datamaskin-applikasjon.

18. Fremgangsmåte ifølge krav 17, karakterisert ved at den videre omfatter trinnene med å: oversette nevnte første melding fra formatet til en første datamaskin-applikasjon til et systemformat før nevnte første melding publiseres; og oversette nevnte andre publiserte melding fra nevnte systemformat til et format for en andre datamaskin-applikasjon før nevnte andre publiserte melding leveres til nevnte andre datamaskin-applikasjon.

19. Fremgangsmåte ifølge krav 18, karakterisert ved at nevnte trinn med å konvertere nevnte første data omfatter: be om nevnte andre data fra en database; og motta nevnte andre data fra nevnte database.

20. Fremgangsmåte ifølge krav 19, karakterisert ved at den videre omfatter trinnene med å: frembringe en adapter konfigurert for én utvalgt blant nevnte datamaskin-applikasjoner; frembringe en agent-tjeneste som vert for nevnte adapter; definere en meldingsdefinisjon for hver av et mangfold meldinger nevnte adapter vil produsere, motta eller svare på; og forbinde nevnte adapter til nevnte utvalgte datamaskin-applikasjon.

21. Et bedriftsapplikasjon-integreringssystem som integrerer et mangfold bedriftsapplikasjoner, som hver har et respektivt internt format for å skape, sende, motta, lagre og prosessere et mangfold meldinger, karakterisert ved at forbedringen omfatter: en agent-adapter som inkluderer et mangfold adaptere innkapslet av en agent; hvor hver blant nevnte mangfold adaptere innkapslet av nevnte agent inkluderer anordninger for å utføre en diskret funksjon mens den er innkapslet av nevnte agent.

22. Forbedring ifølge krav 21, karakterisert ved at nevnte agent videre omfatter et mangfold interne objekter, idet hver blant nevnte mangfold objekter er tilpasset for å utføre en diskret funksjon.

23. Forbedring ifølge krav 22, karakterisert ved at et første i nevnte mangfold interne objekter i nevnte agent videre omfatter anordninger for å administrere forbindelser for nevnte agent-adapter mellom utvalgte i mangfoldet av bedriftsapplikasjoner og systemet.

24. Forbedring ifølge krav 23, karakterisert ved at et andre i nevnte mangfold interne objekter i nevnte agent videre omfatter anordninger for å administrere feil detektert i nevnte agent-adapter mellom utvalgte blant mangfoldet av bedriftsapplikasjoner og systemet.

25. Forbedring ifølge krav 23, karakterisert ved at et tredje i nevnte mangfold interne objekter i nevnte agent videre omfatter anordninger for å administrere en transformasjon av mangfoldet meldinger innen nevnte agent-adapter mellom utvalgte blant mangfoldet av bedriftsapplikasjoner og systemet.

26. Forbedring ifølge krav 22, karakterisert ved at den videre omfatter et mangfold noder og et mangfold systemtjenester lokalisert ved nevnte noder.

27. Forbedring ifølge krav 26, karakterisert ved at nevnte agent videre omfatter et mangfold interne objekter, idet hvert i nevnte mangfold objekter er tilpasset for å utføre en diskret funksjon.

28. Forbedring ifølge krav 27, karakterisert ved at hvert i nevnte mangfold interne objekter i nevnte agent er tilpasset for å utføre sin respektive funksjon ved en hvilken som helst blant nevnte mangfold noder.

29. Forbedring ifølge krav 27, karakterisert ved at hvert i nevnte mangfold interne objekter i nevnte agent er tilpasset for å utføre sin respektive funksjon i samarbeid med respektive av nevnte interne objekter i en annen agent i systemet.