TPTP indeholder en struktur for automatiseringsserviceprogrammer med understøttelse af udbud og forbrug af Eclipse-baserede TPTP-serviceprogrammer fra forskellige miljøer. Da disse serviceprogrammer dybest set er uigennemsigtige komponenter, som publiceres via udvidelser (med en tilknyttet specifikation af understøttede egenskaber og en funktionsmådekontrakt), er det muligt at oprette en ny serviceprogramudbyder, der implementerer samme serviceprogram. Denne implementerede metode giver en løs og dynamisk binding mellem forbrugeren og udbyderen af serviceprogrammet.
TPTP's serviceprogramabstraktioner er ikke helt identiske med abstraktioner for standardwebserviceprogrammer (de er langt tyndere, enklere og mere uformelle), men de bringer TPTP et skridt nærmere en rolle i en serviceprogramorienteret arkitektur. De begreber og abstraktioner, der introduceres med strukturen til automatiseringsserviceprogrammer, er synonyme med højniveauabstraktionerne i en hvilken som helst serviceprogramorienteret arkitektur.
Der vil gradvist blive udviklet og publiceret serviceprogrammer for de funktioner, der udgør TPTP, så TPTP-platformen gøres klar til at blive styret fra scripts og diverse programmer uden for Eclipse. De aktuelle TPTP-testfunktioner stiller et serviceprogram til testudførelse til rådighed, som gør det muligt at udføre TPTP-tests på en fleksibel og programlignende måde.
Strukturen for automatiseringsserviceprogrammer har en lagdelt arkitektur, der tillader løse koblinger mellem strukturens komponenter. Den bus, der transporterer anmodninger fra forbrugere af serviceprogrammet til svar fra serviceprogramudbyderen (udførelsen af serviceprogrammer) tillader udvidelser i begge sider med en adaptermodel på klientsiden (klientsiden kan være kode, der udføres i en Eclipse-forekomst, eller kode, der udføres uden for Eclipse, f.eks. kommandolinjescripts) og en tilbudsmodel for serviceprogramudbydere på serversiden (serversiden er den Eclipse-forekomst, der er vært for de plugins, som leverer serviceprogramimplementeringerne).
Der kan udvikles yderligere automatiseringsklientadaptere, som indsætter nye paradigmer for serviceprogramforbrugere i de standardklientgrænseflader til automatisering, som stilles til rådighed i TPTP. En tredjepart kunne f.eks. udvikle en klientautomatiseringsadapter til webserviceprogrammer, der tillader, at TPTP-automatiseringsserviceprogrammer udføres i et standardmiljø for webserviceprogrammer, eller der kunne blive skrevet en automatiseringsadapter til Jython-klienter, som understøtter forbrug af serviceprogrammer fra Jython-miljøet.
Efterhånden som nye kompatible automatiseringsserviceprogrammer publiceres, øger de den pulje med serviceprogrammer, der er offentligt tilgængelige fra en TPTP Eclipse-forekomst, og dermed de tilgængelige serviceprogramudbydere, som kan levere funktionalitet til interesserede forbrugere ved at udnytte strukturen for automatiseringsserviceprogrammer. En bruger kan oprette en plugin, som leverer et nyt serviceprogram, ved blot at implementere de relevante udvidelsespunkter og udvikle mindst én Java-klasse. Som følge af den lagdelte arkitektur og bussens natur vil dette serviceprogram automatisk være tilgængeligt fra ANT-scripts, shell-scripts, Java-programmer og eventuelle andre installerede klientadaptere i forbrugermiljøet.
Den tynde automatiseringsklientkomponent leverer et standardsæt serviceprogramgrænseflader, der kan bruges af klientadaptere, samt Eclipse-startstrategier for de relevante scenarier. I øjeblikket tilbydes to start- og udførelsesstrategier, en til serviceprogramforbrug inden for processen og en anden til serviceprogramforbrug uden for processen (strategien uden for processen er den typiske strategi, der betjener klienter uden for en bestemt Eclipse-forekomst). Strategien inden for processen bruges i situationer, hvor det er ønskeligt, at serviceprogrammet udføres i samme Eclipse-forekomst som kalderen.
Den tynde komponent interagerer med den tunge komponent (tung, fordi dens afhængighed af Eclipse er større, og den dermed har yderligere biblioteksafhængigheder, som automatiseringsklientkomponenten uden for Eclipse ikke har pga. abstraktioner). Den tynde komponents eneste kobling til en bestemt Eclipse-forekomst er en streng-id, der kan angives for automatiseringsklientkomponentens forekomst. Den automatiseringsserver, der er placeret i en Eclipse-forekomst (betegnes også som en tung intern komponent eller mægler), modtager indgående kommunikation fra den tynde automatiseringsklientkomponent og styrer kaldet til den relevante serviceprogramudbyder (et automatiseringsserviceprogram). Automatiseringsserveren definerer nogle enkle udvidelsespunkter, som tillader indirekte reference mellem det serviceprogram, der er anmodet om, og den Java-klasse, der opfylder anmodningen.
Relaterede opgaver
Start test fra scripts og programmer
Udfør serviceprogram til testudførelse
Relateret reference
Understøttede egenskaber for serviceprogram til testudførelse
(C) Copyright IBM Corporation 2000, 2006. All Rights Reserved.