29-08-2011, 04:47 PM
[attachment=15552]
ABSTRACT
Service-oriented architecture (SOA)is a software architecture where functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are often seen as built upon, and evolving from older concepts of distributed computing and modular programming..."
Service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration in computing. A system based on a SOA will package functionality as a suite of interoperable services that can be used within multiple separate systems from several business domains.
SOA also generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well understood, well defined interface to access them. XML is commonly used for interfacing with SOA services, though this is not required.
SOA defines how to integrate widely disparate applications for a Web-based environment and uses multiple implementation platforms. Rather than defining an API SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such a SOA implementation.
“SERVICE ORIENTED ARCHITECTURE”
INTRODUCTION
The SOA implementations rely on a mesh of software services. Services comprise associated, loosely coupled units of functionality that have no calls to each other embedded in them.Each service implements one action, such as filling out an online application for an account, or viewing an online bank statement, or placing an online booking or airline ticket order. Rather than services embedding calls to each other in their source code, they use defined protocols that describe how services pass and parse messages using description metadata.
SOA developers associate individual SOA objects by using orchestration. In the process of orchestration the developer associates software functionality (the services) in a non-hierarchical arrangement using a software tool that contains a complete list of all available services, their characteristics, and the means to build an application utilizing these sources.
Underlying and enabling all of this requires metadata in sufficient detail to describe not only the characteristics of these services, but also the data that drives them. Programmers have made extensive use of XML in SOA to structure data that they wrap in a nearly exhaustive description-container. Analogously, the Web Services Description Language (WSDL) typically describes the services themselves, while the SOAP protocol describes the communications protocols. Whether these description languages are the best possible for the job, and whether they will become/remain the favorites in the future, remain open questions. SOA depends on data and services that are described by metadata that should meet the following two criteria:
1. The metadata should come in a form that software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity. For example, metadata could be used by other applications, like a catalogue, to perform autodiscovery of services without modifying the functional contract of a service.
2. The metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort.
SOA aims to allow users to string together fairly large chunks of functionality to form ad hoc applications that are built almost entirely from existing software services. The larger the chunks, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not prove sufficiently granular for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA suggests that the marginal cost of creating the n-th application is low, as all of the software required already exists to satisfy the requirements of other applications. Ideally, one requires only orchestration to produce a new application.
What Is an Architecture?
Software architecture is a description of a software system in terms of its major components, their relationships, and the information that passes among them.In essence, architecture is a plan for building systems that meet well-defined requirements and, by extension, systems that possess the characteristics needed to meet those requirements now and in the future.
A fundamental purpose of software architecture is to help manage the complexity of software systems and the modifications that systems inevitably undergo in response to external changes in the business, organizational, and technical environments.There is no single, industry-wide definition of software architecture. The Software Engineering Institute (SEI) web site includes a long list of definitions for the term ‘‘software architecture’’ at http://sei.cmu.edu/architecture/definitions.html. Some definitions provide details and context to the abstractdefinition given above, and expand on the notions of a system description, requirement specification, and planning. Others are just as abstract but provide a different viewpoint for thinking about architecture.
The definition of software architecture from The Rational UnifiedProcess—An Introduction by Booch and Kruchten (1999).
Software Architecture encompasses the significant decisions about:
The organization of a software system,
the selection of the structural elements and their interfaces by which the system
is composed, together with their behavior as specified in the collaboration among
those elements,
the composition of these elements into progressively larger subsystems,
the architectural style that guides this organization, these elements and their
interfaces, their collaborations, and their composition.
Software architecture is not only concerned with structure and behavior but
also with usage, functionality, performance, resilience, reuse, comprehensibility,
economic and technological constraints and tradeoffs, and aesthetics.
What Is Service Oriented Architecture?
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
SOA is an architectural style for building enterprise solutions based on services. More specifically, SOA is concerned with the independent construction of business-aligned services that can be combined into meaningful,higher-level business processes and solutions within the context of the enterprise. Anybody can create a service; that is not the challenge of SOA. The real value of SOA comes when reusable services are combined to create agile,
flexible, business processes. Unfortunately, that does not just happen by itself. Achieving it might be easier to manage if a single organization is creating all of the services, but that is not the case at most large organizations. So, part of the architecture of SOA is responsible for creating the environment necessary to create and use composable services across the enterprise. In other words, architecture enables different organizations to independently implement services that meet their immediate needs, yet can also be combined into higher-level business processes and enterprise solutions. This requires that services: Have similar size, shape, form, function, and other characteristics
Conform to enterprise standards
Communicate at a technical level
Communicate at a semantic level
Don’t have gaps and overlaps in responsibilities
The important parts of SOA are:
Processes — High-level business functions, often spanning applications or LOBs
Services —Modular units of business functionality
Integration— Connection to and exposure of existing applications and/or data as services
Existing systems — Existing legacy systems, commercial off-the-shelf (COTS) applications, and data that the enterprise wants to leverage
Documents— High-level units of business information, such as a purchase order, or an EDI document
Semantics— The underlying meaning of information that is exchanged in processes
Transformation— The conversion of information from one format or semantic to another
Communications— The ability of services to communicate with each other
ABSTRACT
Service-oriented architecture (SOA)is a software architecture where functionality is grouped around business processes and packaged as interoperable services. SOA also describes IT infrastructure which allows different applications to exchange data with one another as they participate in business processes. The aim is a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. SOA separates functions into distinct units, or services, which are made accessible over a network in order that they can be combined and reused in the production of business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. SOA concepts are often seen as built upon, and evolving from older concepts of distributed computing and modular programming..."
Service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration in computing. A system based on a SOA will package functionality as a suite of interoperable services that can be used within multiple separate systems from several business domains.
SOA also generally provides a way for consumers of services, such as web-based applications, to be aware of available SOA-based services. For example, several disparate departments within a company may develop and deploy SOA services in different implementation languages; their respective clients will benefit from a well understood, well defined interface to access them. XML is commonly used for interfacing with SOA services, though this is not required.
SOA defines how to integrate widely disparate applications for a Web-based environment and uses multiple implementation platforms. Rather than defining an API SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point for such a SOA implementation.
“SERVICE ORIENTED ARCHITECTURE”
INTRODUCTION
The SOA implementations rely on a mesh of software services. Services comprise associated, loosely coupled units of functionality that have no calls to each other embedded in them.Each service implements one action, such as filling out an online application for an account, or viewing an online bank statement, or placing an online booking or airline ticket order. Rather than services embedding calls to each other in their source code, they use defined protocols that describe how services pass and parse messages using description metadata.
SOA developers associate individual SOA objects by using orchestration. In the process of orchestration the developer associates software functionality (the services) in a non-hierarchical arrangement using a software tool that contains a complete list of all available services, their characteristics, and the means to build an application utilizing these sources.
Underlying and enabling all of this requires metadata in sufficient detail to describe not only the characteristics of these services, but also the data that drives them. Programmers have made extensive use of XML in SOA to structure data that they wrap in a nearly exhaustive description-container. Analogously, the Web Services Description Language (WSDL) typically describes the services themselves, while the SOAP protocol describes the communications protocols. Whether these description languages are the best possible for the job, and whether they will become/remain the favorites in the future, remain open questions. SOA depends on data and services that are described by metadata that should meet the following two criteria:
1. The metadata should come in a form that software systems can use to configure dynamically by discovery and incorporation of defined services, and also to maintain coherence and integrity. For example, metadata could be used by other applications, like a catalogue, to perform autodiscovery of services without modifying the functional contract of a service.
2. The metadata should come in a form that system designers can understand and manage with a reasonable expenditure of cost and effort.
SOA aims to allow users to string together fairly large chunks of functionality to form ad hoc applications that are built almost entirely from existing software services. The larger the chunks, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not prove sufficiently granular for easy reuse. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA suggests that the marginal cost of creating the n-th application is low, as all of the software required already exists to satisfy the requirements of other applications. Ideally, one requires only orchestration to produce a new application.
What Is an Architecture?
Software architecture is a description of a software system in terms of its major components, their relationships, and the information that passes among them.In essence, architecture is a plan for building systems that meet well-defined requirements and, by extension, systems that possess the characteristics needed to meet those requirements now and in the future.
A fundamental purpose of software architecture is to help manage the complexity of software systems and the modifications that systems inevitably undergo in response to external changes in the business, organizational, and technical environments.There is no single, industry-wide definition of software architecture. The Software Engineering Institute (SEI) web site includes a long list of definitions for the term ‘‘software architecture’’ at http://sei.cmu.edu/architecture/definitions.html. Some definitions provide details and context to the abstractdefinition given above, and expand on the notions of a system description, requirement specification, and planning. Others are just as abstract but provide a different viewpoint for thinking about architecture.
The definition of software architecture from The Rational UnifiedProcess—An Introduction by Booch and Kruchten (1999).
Software Architecture encompasses the significant decisions about:
The organization of a software system,
the selection of the structural elements and their interfaces by which the system
is composed, together with their behavior as specified in the collaboration among
those elements,
the composition of these elements into progressively larger subsystems,
the architectural style that guides this organization, these elements and their
interfaces, their collaborations, and their composition.
Software architecture is not only concerned with structure and behavior but
also with usage, functionality, performance, resilience, reuse, comprehensibility,
economic and technological constraints and tradeoffs, and aesthetics.
What Is Service Oriented Architecture?
A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.
SOA is an architectural style for building enterprise solutions based on services. More specifically, SOA is concerned with the independent construction of business-aligned services that can be combined into meaningful,higher-level business processes and solutions within the context of the enterprise. Anybody can create a service; that is not the challenge of SOA. The real value of SOA comes when reusable services are combined to create agile,
flexible, business processes. Unfortunately, that does not just happen by itself. Achieving it might be easier to manage if a single organization is creating all of the services, but that is not the case at most large organizations. So, part of the architecture of SOA is responsible for creating the environment necessary to create and use composable services across the enterprise. In other words, architecture enables different organizations to independently implement services that meet their immediate needs, yet can also be combined into higher-level business processes and enterprise solutions. This requires that services: Have similar size, shape, form, function, and other characteristics
Conform to enterprise standards
Communicate at a technical level
Communicate at a semantic level
Don’t have gaps and overlaps in responsibilities
The important parts of SOA are:
Processes — High-level business functions, often spanning applications or LOBs
Services —Modular units of business functionality
Integration— Connection to and exposure of existing applications and/or data as services
Existing systems — Existing legacy systems, commercial off-the-shelf (COTS) applications, and data that the enterprise wants to leverage
Documents— High-level units of business information, such as a purchase order, or an EDI document
Semantics— The underlying meaning of information that is exchanged in processes
Transformation— The conversion of information from one format or semantic to another
Communications— The ability of services to communicate with each other
