Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
UNIT I Based On Service-Oriented Architecture: Concepts, Technology, and Design By Thomas Erl
Prepared By S.Usha & J.Jeyalakshmi Lecturer / Department of Information Technology Rajalakshmi Engineering College
04.05.2011
Unit 1
04.05.2011
Unit 1
Application architecture
Application architecture is to an application development team what a blueprint is to a team of construction workers. Different organizations document different levels of application architecture. Some keep it high-level, providing abstract physical and logical representations of the technical blueprint. Others include more detail, such as common data models, communication flow diagrams, application-wide security requirements, and aspects of infrastructure.
A key part of any application-level architecture is that it reflects immediate solution requirements, as well as long-term, strategic IT goals.
04.05.2011
Unit 1
Enterprise architecture
In larger IT environments, the need to control and direct IT infrastructure is critical. When numerous, disparate application architectures co-exist and sometimes even integrate, the demands on the underlying hosting platforms can be complex and onerous. Therefore, it is common for a master specification to be created, providing a high-level overview of all forms of heterogeneity that exist within an enterprise, as well as a definition of the supporting infrastructure. Continuing our previous analogy, an enterprise architecture specification is to an organization what an urban plan is to a city. Therefore, the relationship between an urban plan and the blueprint of a building are comparable to that of enterprise and application architecture specifications. Typically, changes to enterprise architectures directly affect application architectures, which is why architecture specifications often are maintained by the same group of individuals. Further ,enterprise architectures often contain a long-term vision of how the organization plans to evolve its technology and environments. For example, the goal of phasing out an outdated technology platform may be established in this specification.
04.05.2011
Unit 1
Service-oriented architecture
service-oriented architecture spans both enterprise and application architecture domains. The benefit potential offered by SOA can only be truly realized when applied across multiple solution environments. This is where the investment in building reusable and interoperable services based on a vendor-neutral communications platform can fully be leveraged. This does not mean that the entire enterprise must become service-oriented. SOA belongs in those areas that have the most to gain from the features and characteristics it introduces. Note that the term "SOA" does not necessarily imply a particular architectural scope. An SOA can refer to an application architecture or the approach used to standardize technical architecture across the enterprise. Because of the composable nature of SOA (meaning that individual applicationlevel architectures can be comprised of different extensions and technologies), it is absolutely possible for an organization to have more than one SOA.
04.05.2011 Unit 1
Characteristics of SOA
The following primary characteristics: 1. Contemporary SOA is at the core of the serviceoriented computing platform. 2. Contemporary SOA increases quality of service. 3. Contemporary SOA is fundamentally autonomous. 4. Contemporary SOA is based on open standards. 5. Contemporary SOA supports vendor diversity. 6. Contemporary SOA fosters intrinsic interoperability. 7. Contemporary SOA promotes discovery. 8. Contemporary SOA promotes federation. 9. Contemporary SOA promotes architectural composability.
04.05.2011 Unit 1
Characteristics of SOA
Service-oriented software architecture has these characteristics Bieber and Carpenter 2001, Stevens, Service-Oriented, 2002, Sun Microsystems, Jini Technology Architectural Overview 2001):
Services are discoverable and dynamically bound. Services are self-contained and modular. Services stress interoperability. Services are loosely coupled. Services have a network-addressable interface. Services have coarse-grained interfaces. Services are location-transparent Services are composable.
SOA vs Traditional Distributed Internet Architecture Muliple client-server architectures have appeared Client-server DB connections have been replaced with Remote Procedure Call connections (RPC) using CORBA or DCOM Middleware application servers and transaction monitors require significant attention Multi-tiered client-server environments began incorporating internet technology in 90s.
04.05.2011
Unit 1
SOA vs Traditional Distributed Internet Architecture The browser shifted 100% of application logic to the server Distributed Internet architecture introduced the Web server as a new physical tier HTTP replaced RPC protocols
04.05.2011
Unit 1
SOA vs Traditional Distributed Internet Architecture Distributed Internet application put all the application logic on the server side Even client-side scripts are downloaded from the server Entire solution is centralized Emphasis is on: How application logic is partitioned Where partitioned units reside How units of logic should interact
04.05.2011 Unit 1
SOA vs Traditional Distributed Internet Architecture Difference lies in the principles used to determine the three primary design considerations Traditional systems create components that reside on one or more application servers Components have varying degrees of functional granularity Components on the same server communicate via proprietary APIs. RPC protocols are used across servers via proxy stubs
04.05.2011 Unit 1
SOA vs Traditional Distributed Internet Architecture Actual references to other physical components can be embedded in programming code (tight coupling) SOAs also rely on components Services encapsulate components Services expose specific sets of functionality Functionality can originate from legacy systems or other sources
04.05.2011
Unit 1
SOA vs Traditional Distributed Internet Architecture Functionality is wrapped in services Functionality is exposed via open, standardized interface, irrespective of technology providing the solution Services exchange information via SOAP messages. SOAP supports RPC-style and document-style messages Most applications rely on document-style
04.05.2011
Unit 1
SOA vs Traditional Distributed Internet Architecture Messages are structured to be self-sufficient Messages contain meta information, processing instructions, policy rules SOA fosters reuse on a deep level by promoting solution-agnostic services
04.05.2011
Unit 1
04.05.2011
Unit 1
04.05.2011
Unit 1
Client-Server Application Technology The technology set for client-server applications included 4GLs like VB and PowerBuilder, RDBMSs The SOA technology set has expanded to include Web technologies (HTML, CSS, HTTP, etc) SOA requires the use of XML data representation architecture along with a SOAP messaging framework
04.05.2011
Unit 1
04.05.2011
Unit 1
Client-Server Application Security Centralized at the Server level Databases manage user accounts and groups Also controlled within the client executable Security for SOA is much more complex Security complexity is directly related to the degree of security measures required Multiple technologies are required, many in WSSecurity framework
04.05.2011 Unit 1
Client-Server Application Administration Significant maintenance costs associated with clientserver Each client housed application code Each update required redistribution Client stations were subject to environment-specific problems Increased server-side demands on databases
04.05.2011
Unit 1
Client-Server Application Administration SOA solutions are not immune to client-side maintenance challenges Distributed back-end supports scalability, but new admin demands are introduced Management of server resources and service interfaces may require new admin tools and even a private registry Commitment to services and their maintenance may require cultural change in an organization
04.05.2011
Unit 1
04.05.2011
Unit 1
23
04.05.2011
Unit 1
25
Renamed terms
Messages Operations Services Processes
Activity has been changed because it uses a different context when modeling service-oriented business processes.
04.05.2011 Unit 1 26
04.05.2011
Unit 1
28
Components of an SOA
Message
A message represents the data required to complete some or all parts of a unit of work.
04.05.2011
Unit 1
29
Components of an SOA
Operation
An operation represents the logic required to process messages in order to complete a unit of work.
04.05.2011
Unit 1
30
Components of an SOA
Service
A service represents a logically grouped set of operations capable of performing related units of work.
04.05.2011
Unit 1
31
Components of an SOA
Processes
A process contains the business rules that determine which service operations are used to complete a unit of automation. A process represents a large piece of work that requires the completion of smaller units of work.
04.05.2011
Unit 1
32
04.05.2011
Unit 1
33
04.05.2011
Unit 1
34
A process instance is not necessarily defined by its service because it may only require a subset of the functionality offered by the services.
A process instance invokes a unique series of operations to complete its automation. Every process instance is therefore partially defined by the service operation it uses.
04.05.2011 Unit 1 35
04.05.2011
Unit 1
36
Key Points
The logical parts of an SOA can be mapped to corresponding components in the basic Web services framework. By viewing a service-oriented solution as a unit of automation logic, we establish that SOA consists of a sophisticated environment that supports a highly modularized separation of logic into differently scoped units. SOA further establishes specific characteristics, behaviors, and relationships among these components that provide a predictable environment in support of service-orientation.
04.05.2011 Unit 1 37
04.05.2011
Unit 1
38
04.05.2011
Unit 1
41
Case Study
RailCo created the Invoice Submission Service which contains two operations
SubmitInvoice GetTLSMetadata
SubmitInvoice - Allows RailCo send electronic invoices to TLS Account Payable Service GetTLSMetadata checks periodically for changes to TLS Account Payable Service
04.05.2011 Unit 1 42
Case Study
In Plain English
Business License Office provides a distinct service
Issuing business licenses Renewing business licenses
04.05.2011
Unit 1
43
04.05.2011
Unit 1
44
04.05.2011
Unit 1
46
Case Study
RailCo and TLS agreed to a service contract that allow the two companies to communicate TLS defined the definition of the associated service description documents TLS ensures a standardized level of conformance that applies to each of its online vendors TLS can change the service at any time
04.05.2011 Unit 1 47
Case Study
In Plain English Application form is needed obtain or renew a business license
Application formalizes the request in a standard format for the Business License Office Application is a contract between the business and Business License Office
04.05.2011
Unit 1
48
04.05.2011
Unit 1
49
04.05.2011
Unit 1
50
Case Study
TLS services are designed to communicate with multiple online vendors make it loosely coupled RailCo service are designed to communicate only with TLS B2B system so is considered less loosely coupled
04.05.2011
Unit 1
51
Case Study
In Plain English
Once the Application is submitted no further action is required on the business Business and Business License Office remain independent Application is the only requirement to communicate with Business License Office
04.05.2011 Unit 1 52
04.05.2011
Unit 1
53
04.05.2011
Unit 1
54
Case Study
RailCo Web services hide the underlying legacy code need to produce the invoices that are needed to sent to TLS TLS Web services hide the underlying services that process the invoices from multiple online vendors Neither service requestor require any knowledge of what processes are working on the others service providor
04.05.2011 Unit 1 55
Case Study
In Plain English
Business License Office tasks are hidden from the business Business does not care what Business License Office does, it just wants a license
04.05.2011
Unit 1
56
04.05.2011
Unit 1
57
04.05.2011
Unit 1
58
Case Study
TLS accounts Payable Service is composed on three services
Accounts Payable Service Vendor Profile Service Ledger Service
04.05.2011
Unit 1
59
Case Study
In Plain English
Other government agencies can use the Business License Office for their license tasks
04.05.2011
Unit 1
60
THANK YOU
04.05.2011
Unit 1