architecting web services unit – ii – part - iii
TRANSCRIPT
![Page 1: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/1.jpg)
Architecting Web Services
Unit – II – PART - III
![Page 2: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/2.jpg)
SOA Paradigm Shift
![Page 3: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/3.jpg)
Kruchten’s 4+1 view model
Logical Viewpoint
Implementation Viewpoint
Process Viewpoint
Deployment Viewpoint
Scenarios
End-user Functionality
Programmers Software management
Integrators Performance Scalability
System engineers Topology
Communications
Use Case view
![Page 4: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/4.jpg)
Implementation View
Web Services Technology Stack
![Page 5: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/5.jpg)
Implementation View• The development view focuses on the organization of
the actual software modules in the software-development environment. The software is packaged in small chunks-program libraries or subsystems-that can be developed by one or more developers. The subsystems are organized in a hierarchy of layers, each layer providing a narrow and well-defined interface to the layers above it.
• Components are related by “is submodule of”.
![Page 6: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/6.jpg)
4 + 1: Implementation Viewpoint
• The imlementation viewpoint focuses on the organization of the actual software modules in the software-development environment.
• The software is packaged in small chunks-program libraries or subsystems-that can be developed by one or more developers.
![Page 7: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/7.jpg)
The Web Services Stack
• To perform the three operations of publish, find and bind in an interoperable manner, there must be a Web Services stack that embraces standards at each level.
• Figure shows a conceptual Web Services stack. • The upper layers build upon the capabilities provided
by the lower layers.• The vertical towers represent requirements that
must be addressed at every level of the stack.• The text on the left represents standard technologies
that apply at that layer of the stack.
![Page 8: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/8.jpg)
The Web Services Stack (continued)
![Page 9: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/9.jpg)
The Web Services Basic Stack
![Page 10: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/10.jpg)
XML Messaging-Based Distributed Computing
• The most fundamental underpinnings of the IBM Web Services architecture is XML messaging.
• The current industry standard for XML messaging is SOAP.
• IBM, Microsoft. and others submitted SOAP to the W3C as the basis of the XML Protocol Working Group.
![Page 11: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/11.jpg)
XML Messaging-Based Distributed Computing (continued)
• SOAP is a simple and lightweight XML-based mechanism for exchanging structured data between network applications.
• SOAP consists of three parts: an envelope that defines a framework for describing what is in a message, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls (RPCs) and responses.
• SOAP can be used in combination with or re-enveloped by a variety of network protocols such as HTTP, SMTP, FTP, RMI over IIOP or MQ.
![Page 12: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/12.jpg)
XML messaging using SOAP
• The basic requirements for a network node to play the role of requestor or provider in XML messaging-based distributed computing are the ability to build, parse a SOAP message, or both, and the ability to communicate over a network
![Page 13: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/13.jpg)
XML messaging using SOAP (continued)
![Page 14: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/14.jpg)
Basic service description
![Page 15: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/15.jpg)
Complete Web Services description stack
![Page 16: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/16.jpg)
LOGICAL VIEW
Composition of Web Services
![Page 17: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/17.jpg)
LOGICAL VIEW• The logical view primarily supports the functional
requirements; the services the system should provide to its end users.It depicts the major design elements and their interaction.
• Designers decompose the system into a set of key abstractions, taken mainly from the problem domain. These abstractions are objects or object classes that exploit the principles of abstraction, encapsulation, and inheritance. In addition to aiding functional analysis, decomposition identifies mechanisms and design elements that are common across the system.
• Components are related by “shares data with”
![Page 18: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/18.jpg)
4 + 1: Logical Viewpoint
• The logical viewpoint supports the functional requirements, i.e., the services the system should provide to its end users.
• Typically, it shows the key abstractions (e.g., classes and interactions amongst them).
![Page 19: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/19.jpg)
A Simple Web Services Workflow
![Page 20: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/20.jpg)
More complex workflow
![Page 21: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/21.jpg)
Composed workflow
![Page 22: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/22.jpg)
Further composition of workflows
![Page 23: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/23.jpg)
Business process hierarchy
![Page 24: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/24.jpg)
Deployment View
From Application Server to Peer to Peer
![Page 25: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/25.jpg)
Deployment View
• The physical view takes into account the system's nonfunctional requirements such as system availability, reliability (fault-tolerance), performance (throughput), and scalability. The software executes on a network of computers (the processing nodes). The various elements identified in the logical, process, and development views-networks, processes, tasks, and objects-must be mapped onto the various nodes. Several different physical configurations will be used-some for development and testing, others for system deployment at various sites or for different customers. The mapping of the software to the nodes must therefore be highly flexible and have a minimal impact on the source code itself.
• Components are related by “communicates with”
![Page 26: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/26.jpg)
4 + 1: Deployment Viewpoint
• The deployment viewpoint defines how the various elements identified in the logical, process, and implementation viewpoints-networks, processes, tasks, and objects-must be mapped onto the various nodes.
• It takes into account the system's nonfunctional requirements such as system availability, reliability (fault-tolerance), performance (throughput), and scalability.
![Page 27: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/27.jpg)
Process View
Life in the Runtime
![Page 28: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/28.jpg)
Process View
• The process view takes into account some nonfunctional requirements, such as performance and system availability. It addresses concurrency and distribution, system integrity, and fault-tolerance. The process view also specifies which thread of control executes each operation of each class identified in the logical view.
• So the process view describes the mapping of functions to runtime elements. It concenrs the dynamics of the system. A process is a group of tasks which form a logical unit. A process can be started, stopped, resumed, etc., and there is communication between processes.
• Components are related by “synchronizes with”
![Page 29: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/29.jpg)
4 + 1: Process Viewpoint
• Addresses concurrent aspects at runtime (tasks, threads, processes and their interactions)
• It takes into account some nonfunctional requirements, such as performance, system availability, concurrency and distribution, system integrity, and fault-tolerance.
![Page 30: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/30.jpg)
Scenario View• The scenario view consists of a small subset of important
scenarios-instances of use cases-to show that the elements of the four views work together seamlessly. For each scenario, we describe the corresponding scripts (sequences of interactions between objects and between processes). This view is redundant with the other ones (hence the "+1"), but it plays two critical roles:– it acts as a driver to help designers discover
architectural elements during the architecture design;
– it validates and illustrates the architecture design, both on paper and as the starting point for the tests of an architectural prototype.
• The scenario view is important for stakeholder communication.
![Page 31: Architecting Web Services Unit – II – PART - III](https://reader036.vdocuments.us/reader036/viewer/2022081519/56649e985503460f94b9b304/html5/thumbnails/31.jpg)
4 + 1: Scenario Viewpoint
• The scenario viewpoint consists of a small subset of important scenarios (e.g., use cases) to show that the elements of the four viewpoints work together seamlessly.
• This viewpoint is redundant with the other ones (hence the "+1"), but it plays two critical roles:– it acts as a driver to help designers discover
architectural elements during the architecture design;
– it validates and illustrates the architecture design, both on paper and as the starting point for the tests of an architectural prototype.