Get Started. It's Free
or sign up with your email address
Rocket clouds
OCEA by Mind Map: OCEA

1. Chap2 Architecture decomposition

1.1. BUSINESS REQUIREMENTS DECOMPOSITION

1.1.1. Strategier for decomposition

1.1.1.1. Det finnes totalt 10 strategier som kan grupperes sammen, men det er ikke gitt at alle disse brukes. Man kan dermed kombinere strategier fra forskjellige grupper

1.1.1.2. Group1

1.1.1.2.1. Layering - lagdeling i applikasjonen. Et lag menes her med hardware og software-stacken som innehar servicene i et gitt "tier" (se under). Tiers representerer prosesserings-kjeder mellom kompomenter og layers representerer container/component-relasjoner i implementasjon og deployering av tjenester

1.1.1.2.2. Distribution - behandle oppgaver i tråder, mange typer klienter. Viktig for skalerbarheten av applikasjonen.

1.1.1.3. Group2

1.1.1.3.1. Exposure - hvordan komponenter eksponeres og konsumerer andre konsumenter. En komponent har tre forskjellige aspekter

1.1.1.3.2. Generality - gjenbrukbare komponenter bør være mest mulig generell. Forsiktig med å ikke gjøre antakelser slik at man bygger komponenter for krav som ikke finnes

1.1.1.3.3. Functionality - organisere moduler ut i fra funksjonalitet

1.1.1.4. Group3

1.1.1.4.1. Coupling and cohesion - grupper ting som jobber sammen sammen (high cohesion) og separer ting som ikke jobber sammen (lav kobling)

1.1.1.4.2. Volatility - Isoler komponenter som sansynligvis har stor risiko for å endres

1.1.1.5. Group4

1.1.1.5.1. Configuration - Systemet bør kunne konfigureres fra et sentralt sted. Security, performance og usability

1.1.1.6. Group5

1.1.1.6.1. Planning and Tracking - Lage en prosjektplan med fokus på avhengigheter. En god arkitektur har få, hvis noen, bi-directional eller circular avhengigheter. Utviklingsoppgaver bør være små slik at de kan gjøres iterativt

1.1.1.6.2. Work assignment - hvordan teamet jobber (distribuert?), skill-set matching i team(ene)

1.1.2. Tiers - logisk eller fysisk organisering av komponenter for å få en organisert komponenter i en lagdeling. Komponenter i et bestemt lag konsumerer som regel komponenter i laget under

1.1.2.1. "Physical" tiers

1.1.2.1.1. Client - hvilken som helst enhet som har interaksjon med systemet. Dette trenger man ikke nødvendigvis ikke ha kontroll over

1.1.2.1.2. Resource - legacy systemer, databaser, feeds, telekommunikasjons-hardware, etc

1.1.2.1.3. Integration - abstraherer og gir aksess til eksterne ressurser

1.1.2.1.4. Business - Forretningslogikk

1.1.2.1.5. Web

1.1.2.2. Two-Tier systems

1.1.2.3. Three and Multi-Tier Systems

1.2. SERVICE-LEVEL REQUIREMENTS DECOMPOSITION

1.2.1. Ikke-funksjonelle krav til systemet

1.2.1.1. Service level eller quality of service reuirements, også kjent som ikke-funksjonelle krav. Kravene ligger under. Det må ofte gjøres trade-offs mellom de ulike kravene

1.2.1.2. Performace - måles som regel i response-tid for en transaksjon per bruker. Kan også måles i throughput, dvs hvor mange transaksjoner som går igjennom på en gitt tid

1.2.1.2.1. Øke kapasiteten på systemet og legge til mer prosessor-kraft

1.2.1.2.2. Benytte effektive algoritmer

1.2.1.2.3. Benytte caching

1.2.1.2.4. Concurrency

1.2.1.2.5. Introdusere intermediade responses for å øke "subjective performance" hos brukeren

1.2.1.3. Scalability - evnen til å opprettholde quality of service mens belastningen (load) på systemet økes. Systemet må fortsatt opprettholde kravene selv om last økes (dette er også noe som spesifiseres i SLA som kapasiteten til systemet).

1.2.1.3.1. Vertical scaling - vertikalt (legge til prosessorer, minne, disker til eksisterende maskin(er). Enklere og billigere enn horizontal scaling, men gir bla single point of failure og det finnes en grense for hvor høyt man kan skallere en enkel unit

1.2.1.3.2. Horizontal scaling - horisontalt og legge til flere maskiner. Øker reliability, availability og flexibility. Men det øker også kompleksiteten på arkitekturen og gir derfor lavere manageability

1.2.1.4. Reliability - integrity og consistency i applikasjonen og transaksjonene. Når load økes må systemet fortsatt være like presist som før. Reliability kan være en utfordring for scalability

1.2.1.5. Availability - oppetiden til systemet. Spesifiseres i SLA hva som er krav til oppetid. Måles i nedetid eller lang response-tid (time-out)

1.2.1.5.1. Økes gjennom replication. Man har redundante hardware og software-komponenter

1.2.1.6. Extensibility - Evnen til å legge til funksjonalitet uten at det går ut over de andre punktene. Vanlig med endring i kravene til et system.

1.2.1.6.1. Definer tydelig scope for systemet i SLA

1.2.1.6.2. Forvent endringer og design deretter

1.2.1.6.3. Ha en god objekt-model og benytt OO-prinsipper

1.2.1.7. Maintainability - Evnen til å rette opp i mangler i eksisterende funksjonalitet uten at det går ut over de andre kravene. For å øke maintainability er det viktig med low coupling, modularitet og dokumentasjon

1.2.1.8. Manageability - monitorering av systemet mtp scalability, reliability, availability, performance og security. Man må kunne monitorere QoS-kravene. Bør også være mulig å konfigurere og "tune" systemet.

1.2.1.9. Security - Sikkerheten i systemet. Vanskelig å spesifisere i SLA. Konfidensialitet, integritet, men også DoS. Viktig med bra komponent-deling slik at man kan bygge sikkerhet-soner i systemet.

1.2.2. Dimensjoner i systemet (variabler)

1.2.2.1. Capacity - ytelsen i et element, feks cpu, netverk-forbindelse, lagringskapasitet. Økes gjennom vertikal skalering. Kan øke performance, availability og scalability

1.2.2.1.1. Kan øke: performance, availability, scalability

1.2.2.2. Redundancy - antall systemer som utfører samme oppgave som feks lastbalansering. Økes gjennom horisontal skalering og kan øke performance, reliability, availability, extensibility og scalability. Kan også redusere performance, manageability og security

1.2.2.2.1. Kan øke: performance, reliability, availability, extensibility og scalability

1.2.2.2.2. Kan redusere: performance, manageability og security

1.2.2.2.3. Load balancing - gir en økning i throughput og scalability. En server kan delegere arbeid til andre servere slik at arbeidet fordeles. Must ifbm horisontal skalering.

1.2.2.2.4. Failover - hvis en server går ned så kan en annen ta over. Backup-serveren tar over "identiteten" til serveren som feilet og opptrer på vegne av den. Capacity er et viktig aspekt mtp failover. Hvis man designer med extra capacity har man mye backup, men liten load for prosesseringskraften. Man bruker penger på servere som ikke gjør noe (før en annen server feiler). Viktig å avveie risiko

1.2.2.2.5. Clusters - minimerer sansynligheten for system-failure. Gir høy availability til system-ressurser. Clusters gir gruppe-administrasjon, detekterer hardware og software failure, håndterer system-feil og restarter services automatisk

1.2.2.3. Modularity - hvordan man deler opp et computational-problem inn i separade elementer og sprer elementene mellom ulike systemer/moduler

1.2.2.3.1. Kan øke: scalability, extensibility, maintainability og security

1.2.2.3.2. Kan redusere: performance, reliability, availability og manageability

1.2.2.4. Tolerance - tid tilgjengelig for å fullføre en request fra en bruker. Betegnes ofte som "oppfattet performance".

1.2.2.4.1. Kan øke: performance, scalability, reliability og manageability

1.2.2.5. Workload - arbeidet som utføres en spesifikk plass i applikasjonen. Relatert til capacity.

1.2.2.5.1. Kan øke: performance, scalability, availability

1.2.2.6. Heterogeneity - diversiteten i teknologier som benyttes i et system og dets subsystemer. Man ønsker størst mulig heterogenitet hvis dette er mulig.

1.2.2.6.1. Kan øke: performance og scalability

1.2.2.6.2. Kan redusere: performance, scalability, availability, extensibility, manageability og security

2. CHAP3 Web Tier Technologies

2.1. Objectives

2.1.1. Benefits/Drawback adopting web framework in designing Java EE application

2.1.1.1. Rammeverkene skal fylle "glippen" mellom JSP, servlet og JSF-spesifikasjonen. Skal fjerne alle "åpne" spørsmål. Gir klare retningslinjer for hvordan man skal implementere viktige komponenter, som feks action handlers, validering, transaksjoner, sikkerhet, session state, bygge UI, etc. Mange rammaverk er så gode at arkitekter benytter de i stedet for EJBS.

2.1.1.2. Inneholder mange gjenbrukbare komponenter og ferdige løsninger. Man slipper å finne opp hjulet på nytt og man følger best practice standarder

2.1.1.3. Hvis man bestemmer seg for å IKKE benytte et web-rammeverk på eksamen, så må dette forklares

2.1.2. Explain typical usage of JSP and Servlets

2.1.2.1. JSP benyttes i presentasjonslaget. Kompileres til slutt til en servlet og man har så og si samme muligheter. Gjør det mye enklere å implementere presentasjonslogikk. Kan skrive EL i en JSP. JSTL ingår også i JSP spec og har mye presentation-utils.

2.1.3. Explain typical uses for JSF

2.1.3.1. JSF er et UI rammeverk. Benyttes i UI-utvikling. Event-basert slik at man "slipper" å forhålde seg til req/resp, men events i stedet. Mange gjenbrubare komponenter.

2.1.3.2. JSF har støtte for: Input validering, event handling, datakonvertering mellom model objects og components, lifecycle managed model object creation, page navigation configuration

2.1.4. Explain web-centric vs EJB-centric implementation to solve requirements. (web-centric = not EJBs)

2.1.4.1. Kalles web-centric hvis man ikke benytter en EJB-container

2.1.4.2. Man må tydelig forstå hvorfor man ikke benytter/benytter en ejb-container

2.1.4.3. EJB

2.1.4.3.1. Høye krav til transaksjonshåndtering

2.1.4.3.2. Høye krav til sikkerhet (sikkerhetskrav som i utgangspunktet ikke dekkes av web, men som dekkes av ejb)

2.1.4.3.3. Høye krav til meldingshåndtering, transaksjoner og sikkerhet

2.1.4.4. WEB

2.1.4.4.1. Enkle applikasjoner

2.1.4.4.2. Krav til rask utvikling

2.1.4.4.3. Hvis man skal utvide en appliksjon som fra før av er WEB

2.2. MVC

2.2.1. Model

2.2.1.1. Underliggende data

2.2.2. View

2.2.2.1. Implementeres i JSP, med eller uten JSF

2.2.2.2. Presentasjon (som regel av modellen)

2.2.2.3. Skal IKKE inneholde forretningslogikk

2.2.3. Controller

2.2.3.1. Implementeres som en Servlet

2.2.3.2. Håndterer interaksjon og delegerer

2.3. Web Container

2.3.1. Gir støtte til view og controller-komponentene

2.3.2. Har støtte for JSP, JSF, Servlets, filters, listeners, EL

2.3.3. Håndterer også sikkerhet, transaksjoner, konfigurasjon, concurrency, sesjoner, scopes, etc

3. CHAP4 Business Tier Technologies

3.1. Objectives

3.1.1. Forklar bruksområder for entity beans, entity classes, stateful og stateless session beans, og message driven beans samt forklar fordeler/ulemper med de forskjellige typene

3.1.1.1. Session Bean - EJBs som innehar forretningslogikk

3.1.1.1.1. Stateless Session Bean

3.1.1.1.2. Statefull Session Bean

3.1.1.2. Entity Beans

3.1.1.2.1. Bønner som persisterer data. IKKE det samme som JPA entities (entity classes). Til eksamen: Må være en særdeles god grunn til å ikke bruke entity classes

3.1.2. Forklar følgende persistering-strategier: Container managed persistence (CMP), BMP, JDO, JPA og ORM

3.1.2.1. CMP Entity Bean (Container Managed Persistence

3.1.2.1.1. Delegerer persisteringen av sin interne state til containeren

3.1.2.1.2. Skal gjøre utviklingen mer produktiv

3.1.2.1.3. Man mister kontroll over persisiteringen til containeren.

3.1.2.2. BMP Entity Bean

3.1.2.2.1. Utvikler må kode hvordan intern state (feks instans-variabler) blir persistert, typisk gjennom SQL. Veldig rett-fram, men ikke særlig produktivt. Alt må hardkodes.

3.1.2.3. Entity Class

3.1.2.3.1. Benyttes av JPA

3.1.2.3.2. POJO med annoteringer som gir info til JPA

3.1.2.3.3. JPA-implementasjonen tar seg av persistering

3.1.2.3.4. EntityManager har rollen til containeren og tar seg av alle metoder for persistering (CRUD + custom SQL)

3.1.2.3.5. Har fire lifecycle states: New, Managed, Detached og Removed

3.1.2.4. Persistering-strategier

3.1.2.4.1. 1. Deleger persisteringen til EJB-containeren eller til ORM-tool

3.1.2.4.2. 2. Skriv all persisteringslogikk selv

3.1.2.4.3. Valget står mellom å kode persisteringen selv eller å delegere dette til en 3. party tool. Når det kommer til ytelse er det egentlig kun prototyping og benchmarking som kan annbefale korrekt løsning

3.1.3. Forklar Data Access Objects (DAOs) og JDBC-basert persistering og knytt det opp mot følgende variabler: Ease of development performance, scalability, extensibility, security

3.1.4. Forklar hvordan Java EE støtter web-services og forklar fordeler/ulemper med å implementere komponenter som webservices

3.1.4.1. Java EE gjør det enkelt å eksponere web-services

3.1.4.2. Alle public-metoder av en klasse kan eksponeres gjennom @WebService-annotering

3.1.4.3. Jax-WS kan benyttes for å konsumere web-services

3.1.4.4. Fordeler med WS i Java EE er produktivitet, man kan kjapt ta i bruk web-services for å imøtekomme krav, man kan raskt eksponere forretningslogikk til eksterne applikasjoner

3.1.4.5. Ulember med WS er potensialet for en dårlig lagdeling i applikasjonen. Det bør innføres et integrasjons-lag. Sikkerhet er vanskeligere å ivareta. Datavalidering kan være vanskelig.

3.1.5. Forklar fordeler med EJB3-utvikling kontra tidligere generasjoner

3.1.5.1. EJB2 har en veldig tung programmeringsmodell. Man må opprette mange interfaces og implementere masse metoder (som ikke nødvendigvis benyttes), kun for en enkel bønne

3.1.5.2. Man slipper å konfigurere masse i xml, men kan bruke annoteringer i stedet

3.1.5.3. Dependency injection gjennom annoteringer, slik at man slipper å gjøre jndi-oppslag manuelt

3.1.5.4. Enklere persisterings-API (JPA)

3.1.5.5. Unit-testbare komponenter (POJOs)

3.1.6. EJB fordeler og ulemper

3.1.6.1. Avgjørelsen mellom å bruke EJB eller å ikke gjøre det kan sammenlignes med avgjørelsen om å benytte et rammeverk

3.1.6.2. Hvis man ikke har et svært stort behov for sikkerhet og transaksjonstøtte har avgjørelsen om å benytte EJB som regel vært "nei" for 1.1, 2.0 og 2.1, men 3.0+ er svært mye enklere enn forgjengerene

3.1.6.3. Scalability - Pooling av EJBs (stateless) gjør at ejb-applikasjoner skallerer veldig bra. Siden containeren kan gjenbruke en stateless session bean etter hver metode-invokasjon så kan et lite antall stateless bønner i en container-managed pool service et høyt antall concurrent clients

3.1.6.4. Security - Security er en av core servicene som tilbys av EJB-containeren. Gjennom transaksjonshåndtering og concurrency control, er sikkerheten en av primærgrunnene til å benytte ejb.

3.1.6.5. Ease of Development - Man får abstrahert bort mange detaljer (dette kan også gjøres gjennom ulike rammeverk (spring feks))

3.2. Hva tilbyr EJB-containeren?

3.2.1. Integrasjon - DI og lookup

3.2.2. Pooling - Styrer en pool med tilgjengelige bønner. Høy ytelse. Gjelder for stateless session beans og MDB

3.2.3. Thread Safety - Session beans og MDB. Gjør alle bønner trådsikker

3.2.4. State management - Stateful session beans. Holder state automatisk i instansvariabler

3.2.5. Messagin - MDBs. Trenger ikke å forholde seg til JMS-api

3.2.6. Transactions - Session beans og MDB. Deklarativ transaksjoner.

3.2.7. Security - Session beans. Integrerer med JAAS. Deklarativt. Enkel konfigurasjon.

3.2.8. Interceptors - Session beans. Veldig lettvekt AOP

3.2.9. Remote Access - Session beans. Automatisk DI.

3.2.10. Web Services - Stateless session beans. Kan gjøre komponentene til web services med minimale endringer i kode

3.2.11. Persisitence - Entities, JPA

3.2.12. Caching and Performance - Entities. JPA tilbyr mye cachingmuligheter og performance-optimalisering

3.2.13. En forenklet programmeringsmodell

4. CHAP5 Integration and Messaging

4.1. Objectives

4.1.1. Forklar hvilke muligheter man har for å kommunisere med eksterne systemer fra et JAVA EE-basert system. Fordeler og ulemper med de ulike metodene

4.1.1.1. Web Services

4.1.1.1.1. Muligjør system-til-syste-kommunikasjon over netverk

4.1.1.1.2. Startet som en veldig lettvekts-protokoll, men har siden integrert egenskaper som security, reliability og transactions gjennom WS-Security, WS-ReliableMessaging, WS-Coordination og WS-AtomicTransaction spesifikasjonene

4.1.1.1.3. SOAP - Simple Access Protocol

4.1.1.1.4. WSDL - Web Service Description Language. Beskriver web-service og definerer hvordan man aksesserer og konsumerer en web-service

4.1.1.1.5. JAX-RPC - Java API for XML-based Remote Procedure Call

4.1.1.1.6. JAX-WS

4.1.1.1.7. JAXR - Java API for XML Registries

4.1.1.2. JMS

4.1.1.2.1. Core Messagin infrastruktur i JEE platformen som tilbyr asynkron java-til-java integrasjon gjennom queues og topics

4.1.1.2.2. Benyttes mye til "inhouse"-integrasjon mellom systemer hvor arkitekten kontrollerer både produsent og konsument

4.1.1.2.3. "JMS provider" injectes i containeren er enten en topic eller en provider

4.1.1.2.4. En stateless-bønne kan være både produsent og konsument ved å injecte en jms-provider eller jms-consumer

4.1.1.3. JCA

4.1.1.3.1. Tilbyr en standardisert aksess-mekanisme til Enterprise Information Sources (EIS) fra Java EE platformen

4.1.1.3.2. Brukes mye mindre enn Web Services og JMS

4.1.1.3.3. Kan benyttes til å wrappe legacy-applikasjoner og eksponere dem gjennom velutformede interfaces

4.1.2. Forklar beste messaging-strategi ut i fra ulike krav

4.1.2.1. Integrasjon er å legge til rette for at informasjon kan sendes mellom to eller flere software-komponenter

4.1.2.1.1. Spørsmål i forhold til dette

4.1.2.2. JMS

4.1.2.2.1. Svært fornuftig hvis man skal integrere to systemer som er implementert på JAVA og som skal sende informasjon mellom hverandre

4.1.2.2.2. Ingen grunn til å bruke web-services (som har mye mer overhead, dårligere sikkerhet, dårligere transaksjonsstøtte, etc) så lenge man ikke skal integrere med et ikke-java-system i fremtiden

4.1.2.2.3. Bra for asynkron informasjon (man kan "emulere" synkron kommunikasjon, men dette går imot designprinsippet)

4.1.2.2.4. Støtter publish-subscribe og point-to-point

4.1.2.2.5. Har message delivery acknowledgments

4.1.2.2.6. Støtter krypering av meldinger

4.1.2.2.7. Støtter transaksjoner gjennom JTA (java transaction api)

4.1.2.3. Web-services

4.1.2.3.1. Benyttes i java to non-java integrasjon

4.1.2.3.2. Bra når man skal integrere mot et eksternt system som man ikke eier eller man kan kontrolere

4.1.2.3.3. Kan benytte både soap og restful semantikk (og JCA)

4.1.2.3.4. Web services var i utgangspunktet designet for å integrere heterogene systemer (noe JMS ikke var)

4.1.2.3.5. JMS er optimisert for Java producers og consumers (det er ikke ws)

4.1.2.3.6. Sikrer at hvis den underliggende implementasjonen av systemet man integrerer mot endrer seg, så opprettholdes fortsatt kontrakten gjennom WSDL

4.1.2.3.7. Teknologi-uavhengig

4.1.2.4. JCA

4.1.2.4.1. Benyttes for å tilby standardisert aksess til et eksisterende EIS fra java ee platformen

4.1.2.4.2. Benyttes ofte til integrasjon mot mainframe systemer

4.1.2.4.3. Man kobler til systemet gjennom en adapter

4.1.2.4.4. Støtter transaksjoner, atomicity, consistency, isolation, durability (ACID)

4.1.3. Forklar typisk bruk av web services og xml over http for å integrere like software-komponenter

4.1.4. Forklar hvordan JCA og JMS brukes fo rå integrere forskjellige software-komponenter i en JEE aplikasjon

4.2. Protokoller

4.2.1. Web services ved bruk av SOAP

4.2.2. Web services ved bruk av REST

4.2.3. Web services for java EE 1.2

4.2.4. JAX-WS 2.0 - Java aPI for XML Web Servies

4.2.5. JAXB 2.0 - Java Architecture for XML Binding

4.2.6. SAAJ 1.3 - SOAP with atachments API for Java

4.2.7. JAX-RPC 1.1 - Java API for XML-based RPC

4.2.8. JAXR 1.0 - Java API for XML Registries

4.2.9. JMS 1.1 - Java Messaging Service

4.2.10. JCA 1.5 - Java Connector Architecture

4.3. CORBA

4.3.1. Designet for å kunne integrere applikasjoner i heterogene miljøer (java-to-.net-to-cobol-to-c++)

4.3.2. IDL - Implementation-neutral interface Definition Language.

4.3.2.1. Kan mappes til et hvilket som helst programmeringsspråk (kommunikasjon mellom språk)

4.3.2.2. Implementasjon i java heter JAVA IDL. Dette gjør det mulig å programmere i Java mot interfaces som er definert i IDL.

4.3.2.3. Brukes for å kalle på legacy systemer da disse ikke nødvendigvis kan mappes til RMI-interfaces.

4.3.3. IIOP - Internet Inter-ORB Protocol.

4.3.3.1. Felles kommunikasjons-protokoll for TCP/IP-nettverk. Gjør det mulig for applikasjoner å kommunisere gjennom en bestemt protokoll. Fjerner dermed nettverk og platform-forskjeller

4.3.3.2. Har støtte for transaksjon og sikkerhets-context på tvers av språkene

4.3.3.3. Java har støtte for RMI over IIOP-protokollen (RMI-IIOP). Denne gjør det mulig for java-objekter å aksessere corba-objekter skrevet i andre språk (og vice versa)

4.3.3.4. RMI-IIOP er kun for å programmere mot RMI-interfaces hvor IIOP blir brukt. Kan kun aksessere mot andre språk hvis alle remote interfaces er definert som Java RMI interfaces.

4.3.3.5. Bruke hvis man skulle designe et nytt system!

4.3.4. RMI-JRMP (java native protocol for method invocations) kan brukes hvis alle applikasjoner som skal integreres er skrevet i Java. Mye kjappere, bedre sikkerhet, bedre portabilitet og garbage collection ++

4.4. MISC

4.4.1. Off-board server: En server som fungerer somen proxy for et legacy system. Det kommuniserer med legacy systemet ved å bruke protokollene som støttes av legacy systemet og kommuniserer med eksterne applikasjoner gjennom industry-standard protocols. Tenk adapter

4.4.2. Screen scraper (terminal emulator): Emulerer en mainframe terminal. Logger på mainframe-systemet som en normal bruker og sender requests til mainframen. Responsene blir intercepted og tolket. Et problem er er hvis det gjøres en endringe i UI til mainframet så vil screen scraperen slutte å virke (ekstremt tett kobling). Mest egnet når legacy systemet ikke eksponerer et API og kildekoden ikke er tilgjengelig. Man slipper å gjøre noen som helst endringer på legacy systemet

4.4.3. B2B integration

4.4.3.1. Spoke: Billig å implementere. En nettleser leser data. Data kan kun ses hos en partner i gangen

4.4.3.2. Exchange: Man har en sentral tredjeparts "marketplace" som tar seg av infrastruktur for at business skal sende data til hverandre. Tenk bus

4.4.3.3. Hub: bus

5. CHAP6 Transactions and Security

5.1. EJB in action

5.1.1. Transaksjoner

5.1.1.1. ACID

5.1.1.1.1. Atomic - Alt eller ingenting

5.1.1.1.2. Consistency - Alt må være i henhold til forretningsregler før og etter transaksjonen uavhengig av om det er commit eller rollback

5.1.1.1.3. Isolation - Transaksjoner jobber ikke på samme data. (låsing i db)

5.1.1.1.4. Durability - Når en transaksjon er commited er den permanent. Kan rulle tilbake eller commite selv om systemet kræsjer pga logger osv

5.1.1.2. 2phase commit

5.1.1.2.1. Brukes i distribuerte miljøer, særlig med 2 eller flere databaser

5.1.1.2.2. Det legges til et ekstra steg slik at man sjekker med resource-managere om transaksjonene kan commites. Hvis alle svarer ja så commites det. Hvis en eller flere svarer nei så rulles alt tilbake

5.1.1.2.3. XA protokollen brukes for two-pahse commit, som er den mest brukte

5.1.1.3. Local transaction

5.1.1.3.1. 1 ressurs

5.1.1.3.2. Koordineres av Resource Manager

5.1.1.3.3. Single-phase commit

5.1.1.4. Global transaction

5.1.1.4.1. Fluere ressurser

5.1.1.4.2. Koordineres av Transaction Manager

5.1.1.4.3. Two-phase

5.1.1.5. JTA - Java Transaction API

5.1.1.5.1. Lite høynivå API som eksponerer transaksjons-funksjonalitet som tibys av appserveren

5.1.1.5.2. Containeren håndterer mesteparten av transaksjonstøtte behind the scenes

5.1.1.5.3. Alt utvikleren gjør er å håndtere transaction demarcation/transaction bounderies (start og slutt på transaksjoner)

5.1.1.5.4. CMT Containere Managed Transactions - Deklarative transaksjoner håndteres gjennom annoteringer

5.1.1.5.5. BMT Bean Managed Transactions - Man koder eksplisitt transaksjoner programmatisk gjennom JTA

5.1.1.6. JTS - Java Transaction Services

5.1.1.6.1. JTA definerer application transaction services og interaksjonen med applikasjonserveren, transaction manager og resource manager

5.1.1.6.2. JTS er selve implementasjonen av transactino manager

5.1.1.6.3. En JTS transactino manager støtter JTA og JTA er høynivå interface for en JTS implementasjon

5.1.1.6.4. JTS implementerer OMG Object Transaction Services (OTS) spesifikasjonen som lavt-nivå interface

5.1.2. SECURITY

5.1.2.1. Authentication - Bevise at man er den man er (passord, fingeravtrykk, etc)

5.1.2.2. Autorization - Få tilgang til de ressurser man har krav på (lese, skrive, filer, mapper, områder, etc)

5.1.2.3. Users, Groups, Roles

5.1.2.3.1. Role

5.1.2.3.2. Group

5.1.2.4. Sikkerhetsrelaterte konsepter

5.1.2.4.1. JRE

5.1.2.4.2. JAAS

5.1.2.4.3. Credential

5.1.2.4.4. Principal

5.1.2.5. Client-Side security

5.1.2.5.1. Applets som kjører i browser eller applikasjoner deployert gjennom Java Web Start eller installert direkte på maskinen

5.1.2.5.2. Kjører i et sandbox-miljø som gir brukeren mulighet til å bestemme hvilke client-side ressurser koden kan og ikke kan aksessere og modifisere

5.1.2.5.3. Kompilert bytecode på signes før den kan requeste aksess til ressurser. Når kode prøver å aksessere client-side ressurser (filsystem eller åpne sockets) vil brukeren få en popup om det skal gis tilgang eller ikke.

5.1.2.5.4. Java applikasjoner installert direkte på en brukers system kjører ikke i sandbox og har dermed tilgang til "alt".

5.1.2.5.5. Man må sørge for at sensitiv data sendt mellom server og klient blir kryptert. Enkleste måten å gjøre dette på er gjennom SSL (Secure Sockets Layer)

5.1.2.5.6. M bruke RMI over SSL, HTTP over SSL eller HTTPS

6. DESING PATTERNS

6.1. GOF

6.1.1. Creational

6.1.1.1. Abstract Factory

6.1.1.1.1. I: Provides an interface for creating families of related or dependent objects

6.1.1.1.2. + Isolerer konkrete klasser

6.1.1.1.3. + Enkelt å endre objekt-familier

6.1.1.1.4. + Consistency mellom objekter

6.1.1.1.5. U: Systemet skal være uavhengig av hvordan objekter blir lagd. Løs kobling her

6.1.1.1.6. U: Systemet skal være konfigurert med mange forskjellige familier av objekter. Dette blir man tvunget til å følge

6.1.1.2. Factory method

6.1.1.2.1. I: Tilbyr et interface for å lage et objekt og lar subklassene besteme hvilken implementasjon som blir instansiert

6.1.1.2.2. + Man slipper å binde "klient" opp mot spesifikke klasser (løs kobling, koding mot interfaces)

6.1.1.2.3. U: Når man ikke vet hvilken implementasjon man ønsker skal instansieres

6.1.1.2.4. U: Man ønsker å dekoble instansieringen av et objekt

6.1.1.3. Builder

6.1.1.3.1. I: Separerer oppbyggingen av et kompleks objet fra representasjonen til objektet slik at den samme byggeprosessen kan lage forskjellige representasjoner

6.1.1.3.2. + Gir god kontroll over instansieringen av objektet

6.1.1.3.3. U: Når algoritmen for å lage et kompleks objekt skal være uavhengig av de delene som utgjør objektet og hvordan delene blir samlet sammen

6.1.1.4. Prototype

6.1.1.4.1. I: Man lager objekter ut i fra en "prototyp" instans av klassen, og objektene man lager kopierer denne prototypen

6.1.1.4.2. Prototyp-interfacet definerer en clone-metode

6.1.1.4.3. + Skjuler den konkrete klassen fra klienten

6.1.1.4.4. U: Når systemet skal være uavhengig av hvordan objektene blir laget. Klassen som skal instansieres spesifiseres runtime. Instanser av en klasse har kun få forskjellige kombinasjoner av state

6.1.1.5. Singleton

6.1.1.5.1. I: Sørger for at man kun har en enkelt instans av en klasse som har et globalt aksesspunkt

6.1.1.5.2. + man har full kontroll med aksess til instansen

6.1.1.5.3. + alle "klienter" må forholde seg til en felles state

6.1.1.5.4. + man unngår mange instanser (effektivt)

6.1.1.5.5. U: Når man må ha nøyaktig en instans av en klasse og alle konsumenter har et veldefinert aksesspunkt til denne instansen

6.1.2. Behavioral

6.1.2.1. Chain of Responsibility

6.1.2.1.1. I: Man unngår kobling mellom senderen av en request og handleren som åndterer requesten. Man gir flere enn ett objekt mulighet til å håndtere requesten. Mange handlers er "chainet" sammen og requesten går fra handler til handler helt til en kan håndtere requesten

6.1.2.1.2. + Redusert kobling

6.1.2.1.3. + Fleksibelt siden man kan legge til handlers runtime (uten å påvirke annen kode)

6.1.2.1.4. U: Når mer enn et objekt kan håndtere en request og man ikke vet hvem som burde håndtere det.

6.1.2.2. Command

6.1.2.2.1. Man definerer et "request-objekt" som klienten kan parameterisere (altså gi rik input via requesten)

6.1.2.2.2. Kan tilby "undo" operasjoner

6.1.2.2.3. + decoupling av objektet som invoker en operasjon og objektet som vet hvordan operasjonen utføres

6.1.2.2.4. + Lett å legge til nye commands siden man ikke trenger å endre eksisterende klasser

6.1.2.3. Interpreter

6.1.2.3.1. I: Man har et "språk" hvor man ønsker å definere en representasjon for grammatikken. Her kan man benytte en interpreter som kan tolke språket

6.1.2.3.2. + Det er lett å ekstende og endre språket

6.1.2.3.3. + Det er enkelt å implementere språket

6.1.2.3.4. U: Når språket er enkelt og det ikke stilles store krav ti lytelse

6.1.2.4. Iterator

6.1.2.4.1. I: Tilbyr en måte å aksessere alle elementer i et aggregat sekvensielt uten å eksponere aggregatets underliggende representasjon

6.1.2.5. Mediator

6.1.2.5.1. I: Definerer et objekt som enkapsulerer all logikk relatert til hvordan et set med forskjellige objekter har interaksjon med hverandre. Man får løs kobling mellom alle objektene og de trenger ikke å ha en referanse til hverandre direkte. Mediatoren ligger i "midten" og håndterer all interaksjon mellom objektene på et sentralt sted

6.1.2.6. Memento

6.1.2.6.1. I: Ved bruk av memento-patternet kan man lagre et objekts interne state slik at objektet kan "restores" på et senere tidspunkt. Bla brukt ifbm stateless beans. Viktig at enkapsuleringen i objektet ikke skal brytes

6.1.2.7. Observer

6.1.2.7.1. I: Definerer en-til-mange avhengighet slik at når et objekt oppdateres så blir alle "observatørene" av objektet notified automatisk

6.1.2.7.2. + Man får en abstrakt kobling mellom subject og observer

6.1.2.7.3. + Man har en broadcasting-mekanisme

6.1.2.8. State

6.1.2.8.1. I: Gjør det mulig for et objekt å endre på sin OPPFØRSEL når dens interne state endres. Man får inntrykk av at klassen i seg selv har endret seg

6.1.2.8.2. + Man har full kontroll over "state"-endringer i objektet, og objektoppførselen kan endre seg deretter (Eks: brusautomatisk gir brus hvis penger puttet på og feilmelding hvis ikke penger puttet på

6.1.2.9. Strategy

6.1.2.9.1. Man definerer en "familie" med algoritmer som implementerer samme interface og gjør det mulig å endre hvilken algoritme et objekt bruker runtime

6.1.2.9.2. + Et godt alternativ til subklassing (man bruker komposisjon i stedet for arv)

6.1.2.9.3. + Man unngår en haug med "if"`er

6.1.2.9.4. + Man trenger forskjellige varianter av en algoritme

6.1.2.9.5. Svært nyttig ifbm DI

6.1.2.10. Template Method

6.1.2.10.1. I: Man definerer et skjelett av en algoritme i flere steg og ett eller flere steg av algoritmen er det opp til subklasser å implementere. Subklasser kan også endre på andre steg

6.1.2.11. Visitor

6.1.2.11.1. I: Visitor gjør det mulig å definere nye operasjoner på en objektstruktur uten å endre noen av klassene i seg selv

6.1.2.11.2. + Gjør det enkelt å legge til nye operasjoner

6.1.3. Structural

6.1.3.1. Adapter

6.1.3.1.1. I: Konverterer et ukjent interface av en klasse til et interface klienten er kjent med. Adapteret har en instans av det ukjente interfacet og delegerer videre til denne gjennom et kjent interface

6.1.3.1.2. + Gjør det mulig for inkopatible objekter å kommunisere og ha interaksjon med hverandre

6.1.3.2. Bridge

6.1.3.2.1. I: Dekobler en abstraksjon fra en implementasjon slik at disse kan variere uavhengig av hverandre. Abstraksjonen delegerer videre til en av implementasjonene og dette kalles bridgen

6.1.3.2.2. + veldig bra for extensibility, abstraksjonen og implementasjonen kan endres uavhengig av hverandre, endringer i implementasjonen har ingen påvirkning på klienten

6.1.3.3. Composite

6.1.3.3.1. I: Gjør det mulig å gruppere en familie med objekter i en trestruktur og dermed få hierarkier. Composite pattern lar klienter behandle inviduelle objekter og kompositter på en uniform måte

6.1.3.4. Decorator

6.1.3.4.1. I: Man kan legge til ansvar og oppførsel til et objekt dynamisk ved å legge en decorator rundt det. Veldig fleksibelt alternativ til subclassing

6.1.3.4.2. + Mer fleksibelt enn statisk arv

6.1.3.4.3. U: Når man ønsker å legge til funksjonalitet og ansvar til et objekt uten å måtte endre på implementasjonen av objektet

6.1.3.5. Facade

6.1.3.5.1. I: tilbyr et grovkornet interface til et sett med interfaces i et subsystem. Gir høynivår tilgang til et lavnivå subsystem. Gir et globalt aksesspunkt hvor man kan styre tilgangslogikk, transaksjoner, etc. Effektivt siden man kun trenger å gjøre et kall til baksystemet

6.1.3.5.2. + gir lav kobling mellom klient og baksystem

6.1.3.5.3. + skjermer klienter fra kompleksitet i subsystemet

6.1.3.6. Flyweight

6.1.3.6.1. I: Objekter deler state slik at det blir mer ytelseseffektivt å ha mange objekter samtidig

6.1.3.6.2. + reduserer antall objekter, reduserer minne og lagringskrav

6.1.3.6.3. U; Når en applikasjon benytter et stort antall objekter

6.1.3.6.4. U; En gruppe med objekter kan erstattes med få delte objekter som deler state

6.1.3.7. Proxy

6.1.3.7.1. I: Man har en "surrogat" eller placeholder for et annet objekt slik at man kan kontrollere aksessen til objektet

6.2. Object Oriented Principlse

6.2.1. Open Closed Principle

6.2.1.1. Klasser er åpen for extension men lukket for modification

6.2.1.2. Det viktigste prinsippet

6.2.1.3. Vi skal kunne legge til ny funksjonalitet til systemet uten å måtte endre våre eksiterende klasser

6.2.1.4. Man reduserer coupling mellom klasser til et abstrakt nivå. Vi lager relationships mellom abstrakte klasser

6.2.2. Liskov Substitution Principle

6.2.2.1. Den skal gå ann å erstatte base classes med subclasses uten at funksjonaliteten til base classen endres

6.2.2.2. Precondition og postcondition skal være di samme når man gjør et kall på en klasse, uavhengig av om det er klassen eller en subklasse man kaller på

6.2.3. Dependency Inversion Principle

6.2.3.1. Depend upon abstractions. Do not depend upon concretions.

6.2.3.2. Mye av det samme som open closed. Gå mot interfaces og ikke konkrete klasser. Da er mye gjort.

6.2.3.3. Sørger for lav kobling

6.2.4. Interface Segregation Principle

6.2.4.1. Det er bedre med mange interfaces i stedet for et generelt interface

6.2.4.2. Interfaces skal være svært cohesive

6.2.4.3. Et interface skal være ansvarlig for å gi et objekt en enkelt rolle

6.2.5. Composite Reuse Principle

6.2.5.1. Benytt polymorfisk komposisjon (mot interfaces) i stedet for arv

6.2.5.2. Dette beskytter oss mot en av de mest katastrofale feilene i et OO-system: å bruke arv som primær gjenbruk-mekanisme

6.2.6. Principle of Least Knowledge/Law of Demeter

6.2.6.1. gitt en operasjon o på en klasse c, så skal det kun være mulig å gjøre operasjoner på følgende objekter: this, parametere i metoden, objekter som blir lagd eller feltene i klassen

6.2.6.2. Dermed slipper man å har intern kjennskap til det objektet man utfører operajsoner på. Dette sørger for løs kobling mellom objektene

6.2.7. Package dependency

6.2.7.1. Hvis innholdet i pakke A er avhengig av innholdet i pakke B så har A en dependency til B. Hvis B endrer seg må man derfor også se om det må gjøres endringer i A.

6.2.7.2. Man ønsker IKKE sirkulre/asykliske avhengigheter

6.2.8. Separation of concerns i java EE

6.2.8.1. Java EE Applikasjoner har lagdeling som ihensyntar soc

6.2.8.1.1. Client Tier (applets, html)

6.2.8.1.2. Java EE Server

6.2.8.1.3. EIS Tier (database server)