service oriented architecture full report
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
project report tiger
Active In SP

Posts: 1,062
Joined: Feb 2010
02-02-2010, 12:41 PM

.doc   Service Oriented Architecture.doc (Size: 240 KB / Downloads: 278)

Report on Service Oriented Architecture (SOA)
SOA is a design for linking business and computational resources (principally organizations, applications and data) on demand to achieve the desired results for service consumers (which can be end users or other services). Service-orientation describes an architecture that uses loosely coupled services to support the requirements of business processes and users. Resources on a network in a SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation. These concepts can be applied to business, software and other types of producer/consumer systems.
The main drivers for SOA adoption are that it links computational resources and promotes their reuse. Enterprise architecture believes that SOA can help businesses respond more quickly and cost-effectively to changing market conditions. This style of architecture promotes reuse at the macro (service) level rather than micro (objects) level.
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA
¢ Reuse, granularity, modularity, compos ability, componentization, and interoperability
¢ Compliance to standards (both common and industry-specific)
¢ Services identification and categorization, provisioning and delivery, and monitoring and tracking.
One obvious and common challenge faced is managing service metadata. Another challenge is providing appropriate levels of security. Interoperability is another important aspect in the SOA implementations.
SOA implementations rely on a mesh (Mesh consists of semi-permeable barrier made of connected strands of metal, fiber, or other flexible/ductile material. Mesh is similar to web or net in that it has many attached or woven strands.)Of software services. Services comprise unassociated, 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. Instead of 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 (Orchestration describes the automated arrangement, coordination, and management of complex computer systems, middleware, and services.). In the process of orchestration the developer associates software functionality (the services) in a non-hierarchical arrangement (in contrast to a class hierarchy) 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 theSOAP 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. As of 2008 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.
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.
For this to operate, no interactions must exist between the chunks specified or within the chunks themselves. Instead, humans specify the interaction of services (all of them unassociated peers) in a relatively ad hoc way with the intent driven by newly emergent requirements. Thus the need for services as much larger units of functionality than traditional functions or classes, lest the sheer complexity of thousands of such granular objects overwhelm the application designer. Programmers develop the services themselves using traditional languages like Java, C,C++, C# or COBOL.
SOA services feature loose coupling, in contrast to the functions that a linker binds together to form an executable, to a dynamically linked library or to an assembly. SOA services also run in "safe" wrappers (such as Java or .NET) and in other programming languages that manage memory allocation and reclamation, allow ad hoc and late binding, and provide some degree of indeterminate data typing.
As of 2008, increasing numbers of third-party software companies offer software services for a fee. In the future, SOA systems may consist of such third-party services combined with others created in-house. This has the potential to spread costs over many customers and customer uses, and promotes standardization both in and across industries. In particular, the travel industry now has a well-defined and documented set of both services and data, sufficient to allow any reasonably competent software engineer to create travel-agency software using entirely off-the-shelf software services. Other industries, such as the finance industry, have also started making significant progress in this direction.
SOA as an architecture relies on service-orientation as its fundamental design-principle. If a service presents a simple interface that abstracts away its underlying complexity, users can access independent services without knowledge of the service's platform implementation.
SOA relies on services exposing their functionality via interfaces that other applications and services can read to understand how to utilize those services.
In order to efficiently use a SOA, one must meet the following requirements:
Interoperability between different systems and programming languages that provides the basis for integration between applications on different platforms through a communication protocol. One example of such communication depends on the concept of messages. Using messages across defined message channels decreases the complexity of the end application, thereby allowing the developer of the application to focus on true application functionality instead of the intricate needs of a communication protocol.
Desire to create a federation of resources. Establish and maintain data flow to a Federated database system(A federated database system is a type of meta-database management system (DBMS) which transparently integrates multiple autonomous database systems into a single federated database). This allows new functionality developed to reference a common business format for each data element.
The following guiding principles define the ground rules for development, maintenance, and usage of the SOA:
Reuse, granularity, modularity, composability, componentization and interoperability.
Standards-compliance (both common and industry-specific).
Services identification and categorization, provisioning and delivery, and monitoring and tracking.
The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behavior of a system and the style of its design:
Attributes of a SOA
Service encapsulation “ Many web services are consolidated for use under the SOA. Often such services were not planned to be under SOA.
Service loose coupling “ Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.
Service contract “ Services adhere to a communications agreement, as defined collectively by one or more service-description documents.
Service abstraction “ Beyond descriptions in the service contract, services hide logic from the outside world.
Service reusability “ Logic is divided into services with the intention of promoting reuse.
Service composability “ Collections of services can be coordinated and assembled to form composite services.
Service autonomy “ Services have control over the logic they encapsulate.
Service optimization “ All else equal, high-quality services are generally preferable to low-quality ones.
Service discoverability “ Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms.
Service relevance “ Functionality is presented at a granularity recognized by the user as a meaningful service.
The following references provide additional considerations for defining a SOA implementation:
SOA Reference Architecture provides a working design of an enterprise-wide SOA implementation with detailed architecture diagrams, component descriptions, detailed requirements, design patterns, opinions about standards, patterns on regulation compliance, standards templates etc..
Life cycle management SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the services lifecycle and provides a detailed process for services management through the service lifecycle, from inception to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best-practices, templates, comments on key SOA standards, and recommended links for more information.
Conceptual model of a SOA architectural style
In addition, one might take the following factors into account when defining a SOA implementation:
efficient use of system resources
service maturity and performance
EAI (Enterprise Application Integration (EAI) is defined as the use of software and computer systems architectural principles to integrate a set of enterprise computer applications.)
Web services approach
Web services can implement a service-oriented architecture. Web services make functional building-blocks accessible over standard Internet protocols independent of platforms and programming languages. These services can represent either new applications or just wrappers around existing legacy systems to make them network-enabled.
Each SOA building block can play one or both of two roles:
1. Service Provider
The service provider creates a web service and possibly publishes its interface and access information to the service registry. Each provider must decide which services to expose, how to make trade-offs between security and easy availability, how to price the services, or (if no charges apply) how/whether to exploit them for other value. The provider also has to decide what category the service should be listed in for a given broker service and what sort of trading partner agreements are required to use the service. It registers what services are available within it, and lists all the potential service recipients. The implementer of the broker then decides the scope of the broker. Public brokers are available through the Internet, while private brokers are only accessible to a limited audience, for example, users of a company intranet. Furthermore, the amount of the offered information has to be decided. Some brokers specialize in many listings. Others offer high levels of trust in the listed services. Some cover a broad landscape of services and others focus within an industry. Some brokers catalog other brokers. Depending on the business model, brokers can attempt to maximize look-up requests, number of listings or accuracy of the listings. The Universal Description Discovery and Integration (UDDI) specification defines a way to publish and discover information about Web services. Other service broker technologies include (for example) ebXML (Electronic Business using extensible Markup Language) and those based on the ISO/IEC 11179 Metadata Registry (MDR) standard.
2. Service consumer
the service consumer or web service client locates entries in the broker registry using various find operations and then binds to the service provider in order to invoke one of its web services. Whichever service the service-consumers need, they have to take it into the brokers, then bind it with respective service and then use it. They can access multiple services if the service provides multiple services.
SOA and Web service protocols
Implementers commonly build SOAs using web services standards (for example, SOAP) that have gained broad industry acceptance. These standards (also referred to as Web Service specifications) also provide greater interoperability and some protection from lock-in to proprietary vendor software. One can, however, implement SOA using any service-based technology, such as Jini, CORBA or REST.
Other SOA concepts
Architectures can operate independently of specific technologies. Designers can implement SOA using a wide range of technologies, including:
Web Services
WCF (Microsoft's implementation of Web service forms a part of WCF)
Implementations can use one or more of these protocols and, for example, might use a file-system mechanism to communicate data conforming to a defined interface-specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without a service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks.[weasel words]Many implementers of SOA have begun to adopt an evolution of SOA concepts into a more advanced architecture called SOA 2.0.
Elements of SOA, by Dirk Krafzig, Karl Banke, and Dirk Slama[9]
SOA meta-model, The Linthicum Group, 2007
Service-Oriented Modeling Framework (SOMF) Version 2.0
SOA enables the development of applications that are built by combining loosely coupled and interoperable services.
These services inter-operate based on a formal definition (or contract, e. g., WSDL) that is independent of the underlying platform and programming language. The interface definition hides of the language-specific service. SOA-based systems can therefore function independently of development technologies and platforms (such as Java,.NET, etc). Services written in C# running on .NET platforms and services written in Java running on Java EE platforms, for example, can both be consumed by a common composite application (or client). Applications running on either platform can also consume services running on the other as web services that facilitate reuse. Managed environments can also wrap COBOL legacy systems and present them as software services. This has extended the useful life of many core legacy systems indefinitely, no matter what language they originally used.
SOA can support integration and consolidation activities within complex enterprise systems, but SOA does not specify or provide a methodology or framework for documenting capabilities or services.
High-level languages such as BPEL and specifications such as WS-CDL and WS-Coordination extend the service concept by providing a method of defining and supporting orchestration of fine-grained services into more coarse-grained business services, which architects can in turn incorporate into workflows and business processes implemented in composite applications or portals
As of 2008 researchers have started investigating the use of Service Component Architecture (SCA) to implement SOA.
Service-oriented modeling is a SOA framework that identifies the various disciplines that guide SOA practitioners to conceptualize, analyze, design, and architect their service-oriented assets. The Service-oriented modeling framework (SOMF) offers a modeling language and a work structure or "map" depicting the various components that contribute to a successful service-oriented modeling approach. It illustrates the major elements that identify the what to do aspects of a service development scheme. The model enables practitioners to craft a project and implimentation plan and to identify the milestones of a service-oriented initiative. SOMF also provides a common modeling notation to address alignment between business and IT organizations.
SOMF addresses the following principles:
business traceability
architectural best-practices traceability
technological traceability
SOA value proposition
software assets reuse
SOA integration strategies
technological abstraction and generalization
architectural components abstraction
SOA definitions
Commentators have provided multiple definitions of SOA. The OASIS group and the Open Group have both created formal definitions.
Organization for the Advancement of Structured Information Standards (OASIS) is a global consortium that drives the development, convergence and adoption of e-business and web service standards. Members of the consortium decide how and what work is undertaken through an open, democratic process.
OASIS defines SOA as the following:
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.
Service contract
A service contract needs to have the following components:
Name “ Name of the service. This should indicate in general terms what the service does, not just its definition
Version “ The version of this service contract
Owner “ The person/team in charge of the service
Responsibility assignment (RACI)
Responsible “ The role/person/team responsible for the deliverables of this contract/service. All versions of the contract
Accountable “ Ultimate Decision Maker in terms of this contract/service
Consulted “ Whom one must consult before action is taken on this contract/service. This is two-way communication. These people have an impact on the decision or the execution of that decision.
Informed “ Who must be informed that a decision or action is being taken. This is a one-way communication. These people are impacted by the decision or execution of that decision, but have no control over the action.
Type “ This is the type of the service: to help distinguish the layer in which it resides. Different implementations will have different service types. Examples of service types include:
Functional Requirement (from Requirements Document) “ Indicates the functionality in specific bulleted items ” what exactly this service accomplishes. The language should encourage test cases to prove the functionality is accomplished.
Service Operations “ Methods, actions etc. Must be defined in terms of what part of the functionality it provides.
Invocation “ Indicates how to invoke the service. This includes the URL, interface, etc. There may be multiple invocation paths for the same service. One may have the same functionality for an internal and some external clients, each with different invocation means and interfaces. Examples:
Events Triggers
Security Constraints “ Defines who can execute this service in terms of roles or individual partners etc. and which invocation mechanism they can invoke.
Quality of Service “ Determines the allowable failure rate
Transactional “ Is this capable of acting as part of a larger transaction and if so, how do we control that
Service Level Agreement “ Determines the amount of latency the service is allowed to have to perform its actions
Semantics “ Dictates or defines the meaning of terms used in the description and interfaces of the service
Process “ Describes the process, if any, of the contracted service
SOA and network management architecture
As of 2008 the principles of SOA are being applied to the field of network management. Examples of service-oriented network management architectures include TS 188 001 NGN Management OSS Architecture from ETSI, and M.3060 Principles for the Management Of Next Generation Networks recommendation from the ITU-T.
Tools for managing SOA infrastructure include:
HP Software & Solutions
HyPerformix IPS Performance Optimizer
IBM Tivoli Framework
Some enterprise architects believe that SOA can help businesses respond more quickly and cost-effectively to changing market-conditions. This style of architecture promotes reuse at the macro (service) level rather than micro (classes) level. It can also simplify interconnection to “ and usage of “ existing IT (legacy) assets.
In some respects, one can regard SOA as an architectural evolution rather than as a revolution. It captures many of the best practices of previous software architectures. In communications systems, for example, little development has taken place of solutions that use truly static bindings to talk to other equipment in the network. By formally embracing a SOA approach, such systems can position themselves to stress the importance of well-defined, highly inter-operable interfaces.
Some have questioned whether SOA simply revives concepts like modular programming (1970s), event-oriented design (1980s) or interface/component-based design (1990s). SOA promotes the goal of separating users (consumers) from the service implementations. Services can therefore be run on various distributed platforms and be accessed across networks. This can also maximize reuse of services
SOA is an architectural and design discipline conceived to achieve the goals of increased interoperability (information exchange, reusability, and composability), increased federation (uniting resources and applications while maintaining their individual autonomy and self-governance), and increased business and technology domain alignment.
Service-Oriented Architecture (SOA) is an architectural approach (or style) for constructing complex software-intensive systems from a set of universally interconnected and interdependent building blocks, called services.
SOA realizes its business and IT benefits through utilizing an analysis and design methodology when creating services. This methodology ensures that services remain consistent with the architectural vision and roadmap, and that they adhere to principles of service-orientation. Arguments supporting the business and management aspects from SOA are outlined in various publications.
A service comprises a stand-alone unit of functionality available only via a formally defined interface. Services can be some kind of "nano-enterprises" that are easy to produce and improve. Also services can be "mega-corporations" constructed as the coordinated work of sub-ordinate services.
Services generally adhere to the following principles of service-orientation:
formal contract
loose coupling
A mature rollout of SOA effectively defines the API of an organization.
Reasons for treating the implementation of services as separate project and implimentations from larger project and implimentations include:
1. Separation promotes the concept to the business that services can be delivered quickly and independently from the larger and slower-moving project and implimentations common in the organization. The business starts understanding systems and simplified user interfaces calling on services. This advocates agility.
2. Separation promotes the decoupling of services from consuming project and implimentations. This encourages good design insofar as the service is designed without knowing who its consumers are.
3. Documentation and test artifacts of the service are not embedded within the detail of the larger project and implimentation. This is important when the service needs to be reused later.
An indirect benefit of SOA involves dramatically simplified testing. Services are autonomous, stateless, with fully documented interfaces, and separate from the cross-cutting concerns of the implementation. The industry has never been exposed to this circumstance before.
If an organization possesses appropriate defined test data, then when a service is being built, a corresponding stub is built that reacts to the test data. A full set of regression tests, scripts, data, and responses is also captured for the service. The service can be tested as a 'black box' using existing stubs corresponding to the services it calls. Test environments can be constructed where the primitive and out-of-scope services are stubs, while the remainders of the mesh are test deployments of full services. As each interface is fully documented, with its own full set of regression test documentation, it becomes simple to identify problems in test services. Testing evolves to merely validating that the test service operates according to its documentation, and in finding gaps in documentation and test cases of all services within the environment. Managing the data state of idempotent services is the only complexity.
Examples may prove useful to aid in documenting a service to the level where it becomes useful. The documentation of some APIs within the Java Community Process provide good examples. As these are exhaustive, staff would typically use only important subsets. The 'ossjsa.pdf' file within JSR-89 exemplifies such a file.
Challenges in adopting SOA
One obvious and common challenge faced involves managing services metadata. SOA-based environments can include many services that exchange messages to perform tasks. Depending on the design, a single application may generate millions of messages. Managing and providing information on how services interact can become complex. This becomes even more complicated when these services are delivered by different organizations within the company or even different companies (partners, suppliers, etc). This creates huge trust issues across teams, and hence SOA Governance comes into picture.
Another challenge involves the lack of testing in SOA space. There are no sophisticated tools that provide testability of all headless services (including message and database services along with web services) in a typical architecture. Lack of horizontal trust requires that both producers and consumers test services on a continuous basis. SOA's main goal is to deliver Agility to Businesses Therefore it is important to invest in a testing framework (build or buy) that would provide the visibility required to find the culprit in the architecture. Business agility requires SOA services to be controlled by the business goals and directives as defined in the Business Motivation Model (BMM).
Another challenge relates to providing appropriate levels of security. Security models built into an application may no longer suffice when an application exposes its capabilities as services that can be used by other applications. That is, application-managed security is not the right model for securing services. A number of new technologies and standards have started to emerge and provide more appropriate models for security in SOA. See SOA Security entry for more information.
As SOA and the WS-* specifications practitioners expand, update and refine their output, they encounter a shortage of skilled people to work on SOA-based systems, including the integration of services and construction of services infrastructure.
Interoperability becomes an important aspect of SOA implementations. The WS-I organization has developed Basic Profile (BP) and Basic Security Profile (BSP) to enforce compatibility. WS-I has designed testing tools to help assess whether web services conform to WS-I profile guidelines. Additionally, another charter has been established to work on the Reliable Secure Profile.
Significant vendor hype surrounds SOA; this can create expectations that may not be fulfilled. Product stacks continue to evolve as early adopters test the development and runtime products with real-world problems. SOA does not guarantee reduced IT costs, improved systems agility or faster time-to-market. Successful SOA implementations may realize some or all of these benefits depending on the quality and relevance of the system architecture and design.
Internal IT delivery organizations routinely initiate SOA efforts, and some of these improperly introduce concepts to the business so it remains misunderstood. The adoption starts meeting IT delivery needs instead of those of the business, resulting in an organization with (say) superlative laptop provisioning services, instead of one that can quickly respond to market opportunities. Business leadership also becomes convinced that the organization is executing well on SOA.
One of the most important benefits of SOA is its ease of reuse. Therefore accountability and funding models must ultimately evolve within the organization. A business unit needs to be encouraged to create services that other units will use. Conversely, units must be encouraged to reuse services. This requires a few new governance components:
Each business unit creating services must have an appropriate support structure in place to deliver on its service-level obligations, and to support enhancing existing services strictly for the benefit of others. This is typically quite foreign to business leaders.
Each business unit consuming services accepts the apparent risk of reusing services outside their own control, with the attendant external project and implimentation dependencies, etc.
An innovative funding model is needed as incentive to drive these behaviors above. Business units normally pay the IT Organization to assist during project and implimentations, and then to operate the environment. Corporate incentives should discount these costs to service providers, and create internal revenue-streams from consuming business units to the service provider. These streams should be less than the costs of a consumer simply building it the old-fashioned way. This is where SOA deployments can benefit from the SaaS(Software as a service) monetization architecture.
Criticisms of SOA
Some criticisms of SOA depend on conflating SOA with web Services. For example, some critics claim SOA results in the addition of XML layers, introducing XML parsing and composition. In the absence of native or binary forms of Remote Procedure Call (RPC), applications could run slower and require more processing power, increasing costs. Most implementations do incur these overheads, but SOA can be implemented using technologies (for example, Java Business Integration (JBI)) that do not depend on remote procedure calls or translation through XML. At the same time, emerging open-source XML parsing technologies (such as VTD-XML) and various XML-compatible binary formats promise to significantly improve SOA performance.
Stateful services require both the consumer and the provider to share the same consumer-specific context, which is either included in or referenced by messages exchanged between the provider and the consumer. This constraint has the drawback that it could reduce the overall scalability of the service provider if the service-provider needs to retain the shared context for each consumer. It also increases the coupling between a service provider and a consumer and makes switching service providers more difficult[26]. Ultimately, some critics feel that SOA services are still too constrained by applications they represent.
Another concern relates to the ongoing evolution of WS-* standards and products (e. g., transaction, security), and SOA can thus introduce new risks unless properly managed and estimated with additional budget and contingency for additional proof-of-concept work.
Some critics regard SOA as merely an obvious evolution of currently well-deployed architectures (open interfaces, etc).
IT system designs sometimes overlook the desirability of modifying systems readily. Many systems, including SOA-based systems, hard-code the operations, goods and services of the organization, thus restricting their online service and business agility in the global marketplace.
The next step in the design process covers the definition of a Service Delivery Platform (SDP) and its implementation. In the SDP design phase one defines the business information models, identity management, products, content, devices, and the end-user service characteristics, as well as how agile the system is so that it can deal with the evolution of the business and its customers.
SOA, Web 2.0, services over the messenger, and mashups
Web 2.0, a perceived "second generation" of web activity, primarily features the ability of visitors to contribute information for collaboration and sharing. Web 2.0 applications often use REST-ful web services and commonly feature AJAX based user interfaces, utilizing web syndication,blogs, and wikis. While there are no set standards for Web 2.0, it is characterized by building on the existing Web server architecture and using services. Web 2.0 can therefore be regarded as displaying some SOA characteristics.[28][29][30]
Some commentators also regard mashups as Web 2.0 applications. The term "Business Mashups" has been coined to describe web applications that combine content from more than one source into an integrated user experience that shares many of the characteristics of service-oriented business applications (SOBAs). SOBAs are applications composed of services in a declarative manner. There is ongoing debate about "the collision of Web 2.0, mashups, and SOA," with some stating that Web 2.0 applications are a realization of SOA composite and business applications.
Web 2.0
Tim O'Reilly coined the term "Web 2.0" to describe a perceived, quickly-growing set of web-based applications. A topic that has experienced extensive coverage involves the relationship between Web 2.0 and Service-Oriented Architectures (SOAs). SOA is considered as the philosophy of encapsulating application logic in services with a uniformly defined interface and making these publicly available via discovery mechanisms. The notion of complexity-hiding and reuse, but also the concept of loosely coupling services has inspired researchers to elaborate on similarities between the two philosophies, SOA and Web 2.0, and their respective applications. Some argue Web 2.0 and SOA have significantly different elements and thus cannot be regarded parallel philosophies, whereas others consider the two concepts as complementary and regard Web 2.0 as the global SOA.
The philosophies of Web 2.0 and SOA serve different user needs and thus expose differences with respect to the design and also the technologies used in real-world applications. However, as of 2008 use-cases demonstrated the potential of combining technologies and principles of both Web 2.0 and SOA.
In an "Internet of Services", all people, machines, and goods will have access via the network infrastructure of tomorrow. The Internet will thus offer services for all areas of life and business, such as virtual insurance, online banking and music, and so on. Those services will require a complex services infrastructure including service-delivery platforms bringing together demand and supply. Building blocks for the Internet of Services include SOA, Web 2.0 and semantics on the technology side; as well as novel business models, and approaches to systematic and community-based innovation.[33]
Even though Oracle indicates that Gartner is coining a new term, Gartner analysts indicate that they call this advanced SOA and refer to it as "SOA 2.0".[34] Most of the major middleware vendors (e. g., Red Hat, web Methods, TIBCO Software, IBM, Sun Microsystems, and Oracle) have had some form of SOA 2.0 attributes for years.[]
Digital Nervous System
SOA implementations have been described as representing a piece of the larger vision known as the Digital Nervous System or the Zero Latency Enterprise.
project report helper
Active In SP

Posts: 2,270
Joined: Sep 2010
14-10-2010, 01:46 PM

.ppt   soa.ppt (Size: 169 KB / Downloads: 119)
Service Oriented Architecture (SOA)

Farhana Zulkernine


Service Oriented Architecture (SOA): Definition, Characteristics
Differences: SOA vs. existing Model Driven Architecture (MDA)
SOA Implementation Framework and Enterprise Service Bus (ESB)
Benefits and reasons for not using SOA
Contribution towards self management
Example of SOA framework
Active In SP

Posts: 1
Joined: Feb 2011
23-02-2011, 09:41 PM

i need to prepare a seminar and presentation report on SOA.....i think may b it'll help me Smile
Active In SP

Posts: 1
Joined: Feb 2011
24-02-2011, 01:06 PM

seminar class
Active In SP

Posts: 5,361
Joined: Feb 2011
04-03-2011, 10:17 AM

presented by:

.ppt   Finalppt.ppt (Size: 1.56 MB / Downloads: 118)
 Getting Started with SOA
 Capabilities of an SOA Application Infrastructure
 Development of an SOA Application
SOA is a architecture for building business applications using loosely coupled services which act like black boxes and can be used to achieve a specific functionality by linking together.
 SOA Basics – Why SOA ?
 Getting Started with SOA
Adopting SOA
 Business Goals of SOA
 SOA Considerations
 SOA Challenges
 Technology Adoption
Business Goals of SOA
 What goals are organizations adopting SOA trying to accomplish?
 Improve B2C communications
 Improve B2B communications
 Create a service oriented architecture for the organization
 Code reuse can reduce development cost
Considerations to make before adopting SOA
 Business Drivers
 Accelerate time to market -
 Reduce Cost
 Increase revenue - Is the business unable to address opportunities because of inflexible IT? Would better IT enable the business to enter new markets?
 Organizational Readiness
 Executive support and sponsorship
 Skills
 Current Arch and environments
 Build and Runtime
 Degree of heterogeneity
 Operational Readiness
 Ability to monitor and manage current operations - How well does IT currently handle production outages? How easily can problems be diagnosed and repaired?
SOA Considerations
Governance - Who pays for the development, especially when multiple departments benefit?
Complexity - The more parts there are to an application and the more machines they run on, the more things that can go wrong. When one part of an application fails, it’s possible for the entire application to stop working.
Reuse - What do we have and what does it do? Common functionality is often developed repeatedly by teams who are unaware of each other
Process - SOA is a new way of thinking. SOA development is similar to but not the same as traditional object-oriented and procedural development. Teams need to learn new development techniques
Team communication - development teams communicate to share reusable assets effectively

In SOA we can divide any architecture in two layers. The first which has direct relevance to business as it carries out business functions. The second layer is a technical layer which talks about managing computer resources like database, web server etc. This division is needed to identify a service. Consider the figure 'Simple order system'. It has various components which interact with each other to complete the order system functionality.
Role of the ESB
The ESB is an important component of the overall SOA . The implementation and use of ESB is much more than just technology. It is also an architectural approach. The ESB is intended for designing and assembling loosely coupled applications and services.

Just as in the dictionary definition, the ESB is well suited to resolve different assumptions about data format, data location and exchange protocols among applications or components in a distributed environment.
 An ESB could facilitate these processes
 Conversion of incoming scanned documents
Incoming non-XML documents can be converted into a standard XML format as described by a specified schema definition, or incoming XML documents can be converted to different XML schema definitions.
 Document validation
Often the first step in a typical business process would be to validate an incoming XML document structure against the defined XML schema to ensure the correctness of the document. The ESB can determine the document type received and can use the correct XML schema to do the necessary document validation checking.

 Content validation
The next step often is to validate the actual data values via interaction with external systems. As long as an ESB is based on open standards, it can leverage open-source components extensively as part of its internal architecture. These components can be “dragged and dropped” into a sequence providing maximum reuse of existing components.

 Persistence
Incoming XML documents can be stored to RDBMS databases. This can happen at various stages of the business process and allow for the reuse of the XML documents in other sequences of business processes at a later stage. This caching mechanism can be used to improve performance and throughput.

 Transformation
A transformation of the XML document could be invoked at any time during the business process. This is very helpful when the end user/customer requires the data to be in a specific format.
 External gateways
An ESB usually provides a number of external gateways or adapters allowing a business process to send XML documents and communications to customers, end users, external Web services or applications. These gateways allow a very flexible and effective means to communicate with the end user and external Web services as part of the business process.
 Content-based routing
The contents of an XML document, in process, can be evaluated. Based on this evaluation, content decisions can be made as to whether the document should be stored or to which customer it should be routed.
SOA components
The central pillar of SOA is the service. A Service should provide a distinct function. It should implement at least all the functionality promised by the contracts it exposes.
The collection of all the messages supported by the Service is collectively known as the service's contract.
End Point
The Endpoint is an address, a URI, a specific place where the service can be found and consumed. A specific contract can be exposed at a specific endpoint.
The unit of communication in SOA is the message. Messages can come in different forms and shapes, for instance, http messages, and even SMTP messages are all valid message forms.
Policy represents the conditions for the semantic specification availability for service consumers. The unique aspects of policy are that it can be updated in run-time and that it is externalized from the business logic.
Service Consumer
A service consumer is any software that interacts with a service by exchanging messages with the service.
Service definition
 Services must be identified, their functionality described, their behavior scoped, and their interfaces designed. The governance CEO may not perform these tasks, but it makes sure that the tasks are being performed.
Service development life cycle
 Services don't come into being instantaneously and then exist forever. Like any software, they need to be planned, designed, implemented, deployed, maintained, and ultimately, decommissioned
Service development life cycle has five main stages:
 Planned. A new service that is identified and is being designed, but has not yet been implemented or still being implemented.
 Test. Once implemented, a service must be tested (more on testing in a moment). Some testing may need to be performed in production systems, which use the service as if it were active.
 Active. This is the stage for a service available for use and what we typically think of as a service. It's a service, it's available, it really runs and really works, and it hasn't been decommissioned yet.
 Deprecated.This stage describes a service which is still active, but won't be for much longer. It is a warning for consumers to stop using the service.
 Sunsetted. This is the final stage of a service, one that is no longer being provided. Registries may want to keep a record of services that were once active, but are no longer available. This stage is inevitable, and yet frequently is not planned for by providers or consumers.
Service versioning
No sooner than a service is made available, the users of those services start needing changes. Bugs need to be fixed, new functionality added, interfaces redesigned, and unneeded functionality removed. The service reflects the business, so as the business changes the service needs to change accordingly.
Service registries
Is like a reference database of services. It describes what each services do, where are they located and how can they communicate.
Service message model
 In a service invocation, the consumer and provider must agree on the message formats. When separate development teams are designing the two parts, they can easily have difficultly finding agreement on common message formats.
Service monitoring
 If a service provider stops working, how will you know? Do you wait until the applications that use those services stop working and the people that use them start complaining?
 Service providers must be monitored to ensure that they're meeting their defined SLAs
service testing
 The service deployment life cycle includes the test stage, during which the team confirms that a service works properly before activating it. If a service provider is tested and shown to work correctly, does the consumer need to retest it as well? Are all providers of a service tested with the same rigor? If a service changes, does it need to be retested?
 To leverage the reuse benefits of SOA, service consumers and providers need to agree on an adequate level of testing of the providers and need to ensure that the testing is performed as agreed
Service security
 Should anyone be allowed to invoke any service? Should a service with a range of users enable all users to access all data? Does the data exchanged between service consumers and providers need to be protected?
 SOA creates services that are easily reusable, even by consumers who ought not to reuse them. Even among authorized users, not all users should have access to all data the service has access to.
Web Services Security Server
 The role of the Web services security server is to protect XML and Web service traffic according to a set of configurable security rules. It protects XML- and Web service-based applications by ensuring that only authorized users and applications are allowed to send data or connect to the services provided, that the appropriate level of encryption is applied and so on
Here’s a general overview of the features and functions of Web services security servers:
 Policy-driven security: A Web services security server can be configured with appropriate policies to combine content filtering with identity-based rules. This allows both the control of user identities (accessing the XML and Web service-based applications) as well as the data they transmit. The server blocks unauthorized access, malicious attacks and malformed data.
 Identity management: Web services security servers usually integrate or synchronize with the existing identity management infrastructure, to perform authentication and authorization for XML- and Web service related traffic.
 Real-time monitoring: Web services security servers also provide real-time alert and intrusion detection. This information can be useful when monitoring XML- and Web service-related traffic and performance. The servers log incoming traffic as well as any intrusion attempts. They also notify security personnel of attacks in progress so personnel can act appropriately.
 Threat awareness: Web services security servers include support for a wide range of rules related to content filtering and traffic analysis. These rule sets are designed to protect the XML and Web service applications from malicious or malformed XML data.
Connected Systems Architectures – What is it?
 CSA describe a class of applications that are connected
 CSA is a subset of SOA
 Often called “system of systems”
 Very large systems are built this way to reduce complexity
 Each “part” isn’t meant to be used on it’s own.
A practical example in SOA
 Military applications: Headquarters application is connected to several field level applications.
 Commands go from the HQ to the field
 Updated mission status go from the field to the HQ
 Updated global state is published from the HQ to the field
 The client is also the service
 Business applications: Marketing app publishes new products, Sales updates price lists, Web brings orders in
 Each system was developed separately. Now need to work together.
 Every app that can be updated by other systems needs a separate module to handle messages coming in.
 In order to minimize app rewrite, the new module listens for messages and updates the app’s database.
 Messages can NOT be lost, even if a service is down. Each order is money in the bank.
The enterprise is changing to adapt to the huge amount of information available and the need to react as the environment changes. This means that enterprise applications have to follow the same rules, and change to adapt to these new requirements.
We have obtained very promising performance figures of an implementation prototype. More work needs to be done in the standardization arena to establish a universal set of requirements for a QoS-aware middleware in real-time SOA, but we hope to have highlighted some of the issues and possibilities in this area.
seminar class
Active In SP

Posts: 5,361
Joined: Feb 2011
11-04-2011, 04:49 PM

A major paradigm shift has been experienced in the way the software applications are designed, architected, delivered and consumed. Service Oriented Architecture is the emerging paradigm for distributed computing and e-business processing that has evolved from object-oriented and component computing to enable building agile networks of collaborating business applications distributed within and across organizational boundaries.
Services are more than just software components as they are generic enough to be platform neutral and self-describing and particularly their ability to enable business. So these are autonomous platform-independent computational elements that can be described, published, discovered, orchestrated and programmed using XML artifacts for the purpose of developing massively distributed interoperable applications. Thus Reusability and Interoperability are buzzwords in the perspective of SOA.
Combined with recent developments in the area of distributed systems, workflow management systems, business protocols and languages, services can provide the automated support needed for e-business integration both at the data and business logic level. They also provide a sound support framework for developing complex business transaction sequences and business collaboration applications.
Adopting the service oriented computing paradigm has the potential to bring about reduced programming complexity and costs, lower maintenance costs, faster time-to-market, new revenue streams and improved operational efficiency.
Besides there are number of challenging issues - service modeling and design methodologies, architectural approaches, service development, deployment and composition, programming and evolution of services and their supporting technologies and infrastructure.
Remya Raj
Active In SP

Posts: 3
Joined: Jul 2011
29-07-2011, 03:22 PM

I need some references based on SOA..............
smart paper boy
Active In SP

Posts: 2,053
Joined: Jun 2011
29-08-2011, 04:47 PM

.docx   soareport.docx (Size: 652.13 KB / Downloads: 278)
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.

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 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
seminar paper
Active In SP

Posts: 6,455
Joined: Feb 2012
16-02-2012, 12:15 PM

to get information about the topic Service-oriented architecture full report ppt and related topic refer the link bellow

http://seminar and presentationproject and


Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Tagged Pages: reporte for service orieted articher, soa seminar ppt, abstract on service oriented architecture, seminor about secure service oriented architecture for mobile services, service oriented architecture seminar report for computer science, a seminar on serviceorientedarchietecture, complete technical seminar documentation of service oriented architecture,
Popular Searches: service oriented architecture pdf vtu notes, secure service oriented architecture for mobile transactions ieee paper, oasis com eg loc es, wibree archietecture, technical seminar topics on service oriented architecture, integration of parallel database in service oriented architecture, cobol,

Quick Reply
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  web spoofing full report computer science technology 13 8,857 20-05-2016, 11:59 AM
Last Post: Dhanabhagya
  edi layered architecture in e-commerce jaseelati 0 191 19-02-2015, 03:02 PM
Last Post: jaseelati
  computer oriented numerical methods ppt jaseelati 0 221 13-02-2015, 01:15 PM
Last Post: jaseelati
  wireless video service in cdma systems wikipedia jaseelati 0 359 13-01-2015, 04:29 PM
Last Post: jaseelati
  Calling a Web Service from an ASP.NET Web Page ppt study tips 1 512 19-10-2014, 11:24 PM
Last Post: LICjKYTCf
  android full report computer science technology 57 73,046 24-09-2014, 05:05 PM
Last Post: Michaelnof
  Object Oriented Programming with Java seminar paper 2 1,055 18-09-2014, 03:24 PM
Last Post: Radhika.m
  steganography full report project report tiger 23 25,693 01-09-2014, 11:05 AM
Last Post: computer science crazy
  3D PASSWORD FOR MORE SECURE AUTHENTICATION full report computer science topics 144 92,192 13-05-2014, 10:16 AM
Last Post: seminar project topic
Video Random Access Memory ( Download Full Seminar Report ) computer science crazy 2 2,380 10-05-2014, 09:44 AM
Last Post: seminar project topic