An Open-EDI prototype based on UML, CORBA and Java

1. An Open-EDI prototype based on UML, CORBA and Java Erfaringer fra utvikling av prototype ISO/IEC SC32 WG1 Ottawa 22. September 1998 Per Myrseth per@nr.no Norwegian Computer Center www.nr.no

2. Åpen EDI skal bli en standard som: • Har som visjon at det skal kunne lages SW systemer basert på formelle spesifikasjoner av forretningsprosesser • Stiller krav til andre standarder • Koordinerer bruk av andre standarder • Enkelt gir teknologisk og virksomhetsmessig interoperabilitet Slide 2

3. Scenario, hovedelementer • Roller • Informasjonsbunker / pakker • Scenarioattributter Slide 3

4. Et scenario beskrives Åpen EDI referanse- modell, retningslinjer og krav Forretnings- transaksjoner Beskrivelser av scenarier og krav til tekno- logiske tjenester Operativt virksomhets- perspektiv. Brukergruppe Registrerings- autoritet Slide 4

5. Scenarier og formelle beskrivelsesteknikker Åpen EDI referansemodell Virksomhetsperspektiv Teknologisk perspektiv Skal beskrives: Skal beskrives: Notasjoner for beskrivelse, f.eks Notasjoner for beskrivelse, f.eks Meldings- utvekslings- mekanismer Scenario: IDEF-1x STEP -Roller EXPRESS STEP, EXPRESS -Informasjons- pakker Sikkerhets mekanismer ESTELLE SA Petri Nets -Scenario- attributter Automati- serte Rolle- utøvere UML OMT OOram OMT Slide 5

6. Bruk av Åpen EDI EDI-aktør EDI-aktør Internt datasystem Internt datasystem Trekker ut og laster inn data Bruker Trekker ut og laster inn data Bruker Automatisert rolleutøver Automatisert rolleutøver Teknologisk tjeneste- perspektiv Teknologisk tjeneste- perspektiv Utvekslings- og sikkerhetstjenester Utvekslings- og sikkerhetstjenester Nett-tjenester Datanett Nett-tjenester Slide 6

7. Mål: Formell spesifikasjon og automatisk systemgenerering En gammel ide innen systemutvikling, som sålangt kun har hatt suksess i svært begrenset omfang Hvordan prøvde vi å nå målet vårt: • Benyttet ”state-of-the-art” FDT toolkit. Rational Rose og UML notasjon • Benyttet ”state-of-the-art” teknologi, Corba og Java for implementasjon Slide 7

8. Modell i UML Message sequence diagram Objectmodel (+State diagram) FSV BOV Slide 8

9. Fra modell til kode UML model Class State Message Open EDI framework Client- specific code diagrams sequence diagrams diagrams IDL code generation Scenario generation CORBA interface definitions Java code generation Scenario drivers & utilities Specific operations, interfacing, etc. Scenario skeleton Object interfaces ORB interfacing code Slide 9

10. Strukturen i CORBA/Java-applikasjonen Slide 10

11. Modellering av åpen-EDI scenarier med Rational Rose og bruk avUML Utdrag av hva fant vi ut: • Rational Rose er primært designet til bruk for å designe og utvikle objektorient SW, og er har ikke blitt designet for å modellere forretningsmodeller. • Flere objekter kan sammen utgjøre en enkelt rolle. • Alle hendelser må skje i konkrete objekter, som alltid vil bli utført på en hostmaskin under ansvar av en aktør. Slide 11

12. FDT’s for asynkron versus synkron system integrasjon NB! EDI meldinger i asynkrone systemer tilsvarer metodekallet i distribuerte objektsystemer. Når må vi velge asynkron versus synkron integrasjon? • Referanse modell nivå (åpen-EDI, eCo, Zackman) • FTD nivå • Design nivå • Programvareverktøy Slide 12

13. Meldingsmodellering versus tilstandsmodellering Forskjeller mellom: • Meldingsmodellering • Tilstandsmodellering av agenter/program som skal utføre aksjoner ved å benytte data i objekter • Hvordan håndtere feil • Sikkerhetsproblemstillinger • Signatur på melding versus metodekall • Kryptering på meldinger versus restriksjoner på tilgang til objekter Slide 13

14. ”Informasjonsutveksling” i en distribuert objectmodell, 1 Benytte referanser til objekter • Stole på at systemene til andre partnere alltid vil være tilgjengelig • Benytte versjonshåndtering på instanser av objekter Slide 14

15. ”Informasjonsutveksling” i en distribuert objectmodell, 2 Copiering eller kloning • What about the methods, they are not platform independent and can’t be copied? • Could all involved actors use the same method libraries? • What about deep versus shallow copying? • Java: Coping objects by value, data, state and methods The idea of an object is that it should be viewed as a whole in the context it belongs. Copy by value is not in line with this idea. Slide 15

16. Points of interest for evaluating FDT’s and variations of implementations In a ”live” business transaction: • Where/what is the scenario state? • What/where are the scenario attributes? • How is a scenario initiated? • When does a role die? • End of scenario • End of business relation with partner • Error handling? Where is it modeled? • Security issues? Where is it modeled? • Digital signatures, encryption, access controll Slide 16

17. Top down versus bottom up What to do Consepts of scenarios and its components Specification of scenarios and their components OeDT FDTx Open-edi Reference model FDTy UML Abstract Concrete Implementation How to do it Slide 17

18. Comments • A FDT’s expression power has to be equal to the expression power to the target abstration level • Open-edi reference model serves as a good vocabulary for a very complex field, made up by simple parts • UML descriptions is interchangable by using XMI, XML Metadata Interchange. Slide 18