TU Wien:Advanced Internet Computing VU (Dustdar)/MindMap WS09
Zur Navigation springen
Zur Suche springen
Datei:TU Wien-Advanced Internet Computing VU (Dustdar) - MindMap WS09.zip
AIC
- Open World Assumption
- EAI
- SoC
- Services
- Standardized Interface / Well-defined - WSDL
- Self-contained
- available
- little integration need
- granularity
- fine
- coarse-grained
- loosely coupled
- reusable
- can be stateful
- context-independent
- service-composition
- QoS
- measureable
- availability
- accessibility
- integrity
- performance
- synchonicity
- sync RPC-style
- async message/document-style
- Interface
- operations, params, data-typing, access protocols
- SOA
- publish/find/bind
- Roles + grafik
- Service Providers
- Service Clients (Requestors)
- Service Reqistry
- Technologies
- Distributed object midware
- CORBA
- J2EE
- Message-oriented midware
- ActiveMQ
- IBM WebSphere MQ
- .. Web services != SOA, = one approach
- Distributed object midware
- ASP vs Web Services
- ASP limitations
- Software as a Service (dazwischen, download)
- SLAs
- contract between provider and client
- Services
- Web Services
- do *
- Describe
- WSDL
- Publish
- UDDI
- Find
- UDDI
- Bind
- SOAP
- Invoke
- SOAP
- Compose
- Orchestration (BPEL)
- Describe
- Extended Specifications
- WS-Addressing
- WS-Policy
- WS-MetaDataExchange
- QoS
- WS-Security
- integrate kerberos etc
- WS-ReliableMessaging
- in-order delivery, at least/most once
- WS-Coordination
- WS-Transaction
- short/long
- WS-Security
- WS-CDL Choreography Description Language
- BPEL Business Process Exectution Language
- do *
- SOAP
- Simple Object Access Protocoll, XML-based messaging protocol
- Message Format: Header + Body
- Roles and processing
- No nodes
- All nodes except initial sender
- Only ultimate receiver
- + additional roles by modules/application
- Faults
- Code, Reason
- optional: detail, node, role
- Interaction Styles
- Document literal
- binding style="document", soap:body use="literal"
- Remote procedure call
- binding style="rpc", soap:body use="encoded"
- Document literal
- Extensibility
- features (reliability, security, message exchange patterns)
- Processing model
- Protocol bindings
- Message Exchange Patterns (MEP)
- features extending one-way communication
- Request-response
- Bindings
- how to use transport protocol
- HTTP intermediaries != SOAP intermediaries
- Request-response using HTTP POST
- Response using HTTP GET
- Attachments
- XML Base64 encoding
- SOAP MTOM (abstract), XOP (impl)
- MIME for binary parts
- WSDL
- XML vocabulary to describe Web services
- exensible and adaptable
- parts
- Abstract: operational behaviour (what)
- Concrete: binding, service (how, where)
- Abstract
- Types
- data type definition (normally XML Schema)
- Message
- multiple parts associated with a type
- RPC -> parts are parameters
- Operation
- combinations of input/output
- Port-type
- named set of abstract operations
- Types
- WSDL Message Exchange Patterns
- One-way operation (predefined)
- async messaging
- Request-response operation (predefined)
- Notification operation
- client has registered for event update
- Solicit-reponse operation
- One-way operation (predefined)
- Concrete
- Bindings
- Operations
- Ports
- individual endpoint, single address
- Services
- group of ports, not communicating
- alternatives for protocol, distance
- Predefined Bindings
- SOAP binding
- HTTP & MIME bindings
- Problems/Limitations
- WSDL 2.0
- simpler, better specified, additional features
- no message construct
- interfaces replace port types
- endpoints replace ports
- document-style operations first-class-citizens
- MEPs
- message exchange patterns more flexible
- faults as interace sub-elements
- 8 predefined
- in-only, out-only
- robust in-only, robust-out-only
- in-out, out-in
- in-optional-out, out-optional-in
- interface extensions / fault extensions
- import / include ... different/same target namespace
- WSDL 1.1 widely used, WSDL 2.0 adoption takes time
- Web service Composition
- Business processes
- activity performed in sequence according to business rules, produces outcome
- short/long lived
- internally or between business partners
- Process model - real world
- Workflow model - technology interactions
- Requirements
- Combine and link existing Web services
- Flexible, Recursive, Recoverable, Seperation of concerns
- Issues
- Abstract process representation
- Discovery and interoperability
- Efficiency
- Process Execution and Monitoring
- Orchestration vs Choreography
- Orchestration
- "part-of" sense
- compose web services for business processes
- define composite services
- reuse of existing web services
- Choreography
- "sequencing" sense
- compose web services for business collaboration
- peer-to-peer model
- define how multiple parties collaborate
- Orchestration
- Web services workflows
- thousands of Web services available
- requires analysis of web services QoS
- Composition
- multi-party conversational interactions
- approaches
- process-based
- requirements-driven
- AI-based
- protocols
- Orchestration (BPEL)
- Cheoreography (WS-CDL)
- Event-based federation (WS-Eventing)
- time
- design time (static composition)
- deployment time ... e.g. different services per installation
- run time (dynamic composition)
- dynamic issues
- discovery, QoS parameter negotionation
- services do not answer, wrong state info, service contract violation
- service protocols and policies
- Research
- Autonomic composition
- self-configuring
- discovery
- self-optimizing
- selection
- self-healing
- reaction
- self-adapting
- behaviour-change
- self-configuring
- QoS-aware service compositions
- respect policies, performance levels,security requirements, SLAs,...
- Autonomic composition
- WS-BPEL
- Web Services Business Process Execution Language
- Process-oriented composition language
- concrete vs abstract processes
- mainly orchestration, some choreography support
- WSDL-based, block-structured
- Activities - primitive/structured
- Data handling - containers
- Processes
- Abstract
- may hide optional details
- describe externally visible interactions
- Concrete
- implementation details
- internal business logic
- Abstract
- Service Selection
- Partner Link Type
- Partner Link
- Endpoint
- Binding
- static/dynamic
- Adoption/Implementations
- Apache ODE
- WebSphere
- Biztalk erver
- OraceBPEL
- WS-CDL
- Web Services Choreography Description Language
- Declarative language for B2B interaction patterns
- Global definition formessage exchanges
- Ordering conditions
- Constraints
- Complementary to WS-BPEL
- extends choreography support
- more global view
- declarative, not executeable
- hardly adopted, over-engineered and too abstract
- Business processes
- Transactions
- Intro
- QoS-Layer: WS-C, WS-AT, WS-BA
- Two-phase commit (2PC)
- prepare, commit
- Resource locking
- ACID Properties
- Atomicity + Consistency + Isolation + Durability
- WS-Transactions challenges
- loose coupling
- distribution
- heterogeneity
- long runtimes
- Long-running activities
- commit sub-activities on completion
- error -> rollback, compensation
- application specific compensation
- limited isolation, visible intermediary results
- Coordination / WS-TransactionStandards
- About
- example: auction + trading / bidding
- Protocols
- message exchange between participant and coordinator
- Coordinator
- mediates, agreement protocols
- Participants
- must agree on outcome
- plays one-to-many roles (completer, 2PC resource manager, caching...)
- Activities
- combine distributed web services
- WS-Coordination
- Foundation layer for coordination
- Activation, Registration
- Coordination context
- Extensibility
- WS-AtomicTransaction
- 2-phase commit for web services (2PC)
- short-lived activities
- WS-BusinessActivity
- long-running transactions
- operation nesting
- compensation-based
- combine with atomic transactions
- About
- Intro
- WS Metadata UDDI
- Metadata
- addressing information for endpoint
- required extended features
- QoS attributes
- Technologies
- XML Schema
- data types
- WSDL
- messages, interfaces, endpoints
- message exchange patterns
- WS-Addressing
- web service endpoint references
- WS-Policy
- QoS requirements
- UDDI
- metadata repository
- WS-MetadataExchange
- dynamic metadata exchange
- XML Schema
- UBR
- Universal Business Registry
- global registry of all services
- quality issues, availability of services...
- > mainly private/semi-private UDDIs
- UDDI
- Universal Description, Discovery and Integration
- APIs in WSDL with SOAP binding to publish & query
- purspose: web service info & dynamic binding
- Registry
- White pages: business information
- Yellow pages: categorization
- Green pages: technical information
- Data
- businessEntity
- organization
- contact info
- businessService
- web services
- addresses, versions, protocols, ..
- bindingTemplate
- technical manual
- parameters, default values, ...
- tModel
- generic container spec
- WSDL specification
- reference to actual document
- unstrctured, human-readable
- generic container spec
- businessEntity
- Dynamic binding
- standard interface as tModel
- app queries UDDI for known tModel key
- WS-Addressing
- Motivation
- messaging
- BPEL
- coordination/transactions
- no addressing in SOAP
- transport-protocol independence required
- messaging
- Specifies
- endpoint references
- additional SOAP headers
- Endpoint References
- map to WSDL port
- Address URI
- Reference Property
- Reference Parameter
- optional Metadata (port type, policies, ...)
- Message Headers
- mandatory: To, Action
- optional: related endpoints, msg relationships
- Motivation
- WS-Policy
- describe nonfunctional service behaviour (vs WSDL)
- eg: supports/requires transactions, security, QoS
- WS-Policy (define) + WS-PolicyAttachment (apply)
- Policy
- assertions + operators
- ExactlyOne, All, optional attribute
- Normal Form for intersection: ExactlyOne + Alls
- Validation using intersection + domain-specific knowledge
- WS-MetadataExchange
- WSDL interface for metadata exchange between endpoints
- Bootstrapping of interactions
- Extensibility + Redirection
- Metadata
- WS-I
- WS-I Basic Profile
- subset of proven, interoperable WS features
- checklist for middleware providers
- WS-I Basic Security Profile
- REST
- Representational State Transfer
- architectural style for distributed systems
- basic architecture of the WWW
- HTTP & URI
- simple, ad-hoc, light-weight
- Characteristics
- Resource-Orientation
- MIME-type
- Statelessness
- so is HTTP
- Uniform Interface
- HTTP interface, GET POST PUT HEAD DELETE
- Naming
- unique and descriptive
- URI per resource
- Layering
- transparent intermediaries (proxies, caches)
- supported by HTTP
- Resource-Orientation
- RESTful Web Services
- in line with the Web
- HTTP + URI
- XML or JSON, HTML, ...
- JAX-RS
- Java API
- POJO based
- annotations
- Jersey, Apache CXF, JBoss Resteasy
- SOAP vs REST
- SOAP & WS-*
- + protocol transparent
- + wsdl
- - fuzzy boundaries
- performance
- RESTful
- + simple & lightweight, HTTP, XML, URI, MIME
- + HTTP available in languages/platforms
- + port 80 - firewalls
- - Hi-REST vs Lo-REST
- SOAP & WS-*
- Mashups
- eg: netvibes
- ad-hoc
- client-side / server-side
- JSON, RSS, Atom
- Service Mashups
- combine services with
- fresh content
- collaborative approaches (tags)
- semantic techs (RSS, RDFa, SPARQL)
- often RESTful
- Tools
- Yahoo Pipes
- combine services with
- Research Questions
- Autonomic Management