| Service Oriented Architecture |
Article Index for Service |
Website Links For Architecture |
Information AboutService Oriented Architecture |
| CATEGORIES ABOUT SERVICE-ORIENTED ARCHITECTURE | |
| web services | |
| enterprise application integration | |
| information technology | |
| service-oriented business computing | |
|
Service Oriented Architecture (SOA) is an evolution of Distributed Computing and Modular Programming . SOAs build applications out of software services. Services are relatively large, intrinsically unassociated units of functionality, which have no calls to each other embedded in them. They typically implement functionalities most humans would recognize as a service, such as filling out an online application for an account, viewing an online bank statement, or placing an online book or airline ticket order. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. This architecture then relies on a business process expert to link and sequence services, in a process known as orchestration, to meet a new or existing business system requirement. Relative to earlier attempts to promote software reuse via modularity of functions, or by use of predefined groups of functions known as classes, SOA's atomic level objects are 100 to 1,000 times larger, and are associated by an application designer or engineer using orchestration. In the process of orchestration, relatively large chunks of software functionality (services) are associated in a non-hierarchical arrangement (in contrast to a class's hierarchies) by a software engineer, or process engineer, using a special software tool which contains an exhaustive list of all of the services, their characteristics, and a means to record the designer's choices which the designer can manage and the software system can consume and use at run-time. Underlying and enabling all of this is Metadata which is sufficient to describe not only the characteristics of these services, but also the data that drives them. XML has been used extensively in SOA to create data which is wrapped in a nearly exhaustive description container. Analogously, the services themselves are typically described by WSDL , and communications protocols by SOAP . Whether these description languages are the best possible for the job, and whether they will remain the favorites going forward, is at present an open question. What is certain is that SOA is utterly dependent on data and services that are described using some implementation of metadata which meets two criteria. The metadata must be in a form which software systems can consume to dynamically configure to maintain coherence and integrity, and in a form which system designers can understand and use to manage that metadata. The goal of SOA is to allow fairly large chunks of functionality to be strung together to form ad-hoc applications which 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 be granular enough to be easily reused. 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 is that the marginal cost of creating the n-th application is zero, as all of the software required already exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application. The key is that there are no interactions between the chunks specified within the chunks themselves. Instead, the interaction of services (all of whom are unassociated peers) is specified by humans in a relatively ad-hoc way with the intent driven by newly emergent business requirements. Thus the need for services to be much larger units of functionality than traditional functions or classes, lest the sheer complexity of thousands of such granular objects overwhelm the application designer. The services themselves are developed using classical languages like Java, C#, C++, C or COBOL. SOA services are loosely coupled, in contrast to the functions a linker binds together to form an Executable , a DLL , or an assembly. SOA services also run in "safe" wrappers such as Java or .NET , which manage memory allocation and reclamation, allow ad-hoc and late binding, and provide some degree of indeterminate Data Typing . Increasing numbers of third-party software companies are offering 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, are also making significant progress in this direction. There is no widely agreed upon definition of SOA other than its literal translation. It is an architecture that relies on DeveloperWorks'', 16 Dec 2003 These concepts can be applied to business, software and other types of producer/consumer systems. SERVICE-ORIENTED ARCHITECTURE Service-oriented architecture (SOA) is an architectural style where existing or new functionalities are grouped into atomic Services . These services communicate with each other by passing data from one service to another, or by coordinating an activity between one or more services. Companies have long sought to integrate existing systems in order to implement Information Technology (IT) support for business processes that cover all present and prospective systems requirements needed to run the business end-to-end. A variety of designs can be used to this end, ranging from rigid point-to-point Electronic Data Interchange (EDI) interactions to Web auctions. By updating older technologies, such as Internet-enabling EDI-based systems, companies can make their IT systems available to internal or external customers; but the resulting systems have not proven to be flexible enough to meet business demands. A flexible, standardized architecture is required to better support the connection of various applications and the sharing of data. SOA is one such architecture. It unifies business processes by structuring large applications as an ad-hoc collection of smaller modules called services. These applications can be used by different groups of people both inside and outside the company, and new applications built from a mix of services from the global pool exhibit greater flexibility and uniformity. One should not, for example, have to provide redundantly the same personal information to open an online checking, savings or IRA account, and further, the interfaces one interacts with should have the same look and feel and use the same level and type of input data validation. Building all applications from the same pool of services makes achieving this goal much easier and more deployable to affiliate companies. An example of this might be interacting with a rental car company's reservation system even though you are doing so from an airline's reservation system. REQUIREMENTS FOR A SOA In order to efficiently use a SOA, one must meet the following requirements:
WEB SERVICES APPROACH TO A SERVICE-ORIENTED ARCHITECTURE Web services implement a service-oriented architecture. A major focus of Web services is to make functional building blocks accessible over standard Internet protocols that are independent from platforms and programming languages. These services can be new applications or just wrapped around existing legacy systems to make them network-enabled. A service can rely on another service to achieve its goals. Each SOA building block can play one or more of three roles:
OTHER SOA CONCEPTS Architecture is not tied to a specific technology. It may be implemented using a wide range of technologies, including SOAP , RPC , DCOM , CORBA , Web Services or WCF . SOA can be implemented using 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 the service having foreknowledge of the calling application, and without the application having or needing knowledge of how the service actually performs its tasks. SOA can also be regarded as a style of information systems architecture that enables the creation 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 The Implementation of the language-specific service. SOA-based systems can therefore be independent 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, which facilitates reuse. Many COBOL legacy systems can also be wrapped by a managed environment and presented as a software service. This has allowed the useful life of many core legacy systems to be extended indefinitely no matter what language they were originally written in. 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 Language s 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 in turn can be incorporated into workflows and business processes implemented in Composite Applications or Portals . The use of Service Component Architecture (SCA) to implement SOA is a current area of research. SOA DEFINITIONS 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). OASIS (the Organization For The Advancement Of Structured Information Standards ) 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.'' There are multiple definitions of SOA, the OASIS group and the Open Group have created formal definition with depth which can be applied to both the technology and business domains.
Though many definitions of SOA limit themselves to technology or just web services, this is predominantly pushed by technology vendors; in 2003 they talked just of web services, while in 2006 the talk is of events and process engines. WHY SOA? Enterprise Architect s believe that SOA can help businesses respond more quickly and cost-effectively to changing market conditionsChristopher Koch A New Blueprint For The Enterprise , ''CIO Magazine'', Mar 1 2005 . 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. SOA Practitioners Guide: Why Services-Oriented Architecture? provides a high-level summary on SOA. In some respects, SOA can be considered an architectural evolution rather than a revolution and captures many of the best practices of previous software architectures. In communications systems, for example, there has been little development of solutions that use truly static bindings to talk to other equipment in the network. By formally embracing a SOA approach, such systems are better positioned to stress the importance of well-defined, highly inter-operable interfaces. Some have questioned whether SOA is just a revival of 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 PRINCIPLES The following guiding principles define the ground rules for development, maintenance, and usage of the SOAYvonne Balzer Improve your SOA project plans , '' IBM '', 16 July 2004 :
The following specific architectural principles for design and service definition focus on specific themes that influence the intrinsic behaviour of a system and the style of its design:
In addition, the following factors should also be taken into account when defining a SOA implementation:
SERVICE-ORIENTED DESIGN AND DEVELOPMENT The modelling and design methodology for SOA applications has become known by the terms DeveloperWorks'', 02 Jun 2004. SOAD is a design methodology for developing highly-agile systems in a consumer/producer model that abstracts implementation from process, such that a service-provider can be modified or changed without affecting the consumer. Service contract A service contract needs to have the following components:
SOA AND WEB SERVICE PROTOCOLS SOA may be built on Web Service s standards (e.g., using 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 . ''Service-oriented architecture'' is often defined as services exposed using the Web Services Protocol Stack . The base level of web services standards relevant to SOA includes the following:
Note, however, that a system does not necessarily need to use any or all of these standards to be "service-oriented." For example, some service oriented systems have been implemented using Corba , Jini and REST . SOA, WEB 2.0, AND MASHUPS Web 2.0 refers to a "second generation" of web sites, primarily distinguished by the ability of visitors to contribute information for collaboration and sharing. Web 2.0 applications use Web services and may include Ajax , Flash , Silverlight or JavaFX user interfaces, Web Syndication , Blogs , and Wikis . While there are no set standards for Web 2.0, it is characterised by building on the existing web server architecture and using services. Web 2.0 can therefore be regarded as displaying some SOA characteristicsDion Hinchcliffe Is Web 2.0 The Global SOA? , ''SOA Web Services Journal'', 28 October 2005. Mashups are also regarded by some as Web 2.0 applications. The term "enterprise mashup" has been coined to describe Web applications that combine content from more than one source into an integrated experience, which share many of the characteristics of Service-oriented Business Application s (SOBAs), which 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 realisation of SOA composite and business applications. Jason Bloomberg Mashups and SOBAs: Which is the Tail and Which is the Dog? , ''Zapthink'' SOA 2.0 OR ADVANCED SOA Amid much negative reaction, Oracle is taking up SOA 2.0 as "the next-generation version of SOA" combining service-oriented architecture and Event Driven Architecture , and categorizing the first iteration of SOA as client-server drivenPaul Krill Make way for SOA 2.0 , ''InfoWorld '', May 17, 2006 . Even though Oracle indicates that and TIBCO Software ) have had SOA 2.0 attributes for years. SOA 2.0 can therefore be regarded as "more marketing noise than anything else"Sandra Rogers Patience Grasshopper…It’s a Learning Process , ''Business Trends Quarterly'', Q4, 2006 and product evangelism rather than a new "way of doing things". However, other industry commentators have criticized attaching a version number to an application architecture design approach, while others have stated that the "next generation" should apply to the evolution of SOA techniques from IT optimization to business developmentJoe McKendrick Anti-SOA 2.0 petition nears 400 , ''ZDNet.com'', June 29, 2006 . WHAT ARE THE CHALLENGES FACED IN SOA ADOPTION? One obvious and common challenge faced is managing services Metadata . SOA-based environments can include many services which 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 is a complicated task. Another challenge is providing appropriate levels of security. Security model built into an application may no longer be appropriate when the capabilities of the application are exposed 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 are emerging to provide more appropriate models for security in SOA. See SOA Security entry for more info.
Interoperability is another important aspect in the SOA implementations. The WS-I organization has developed Basic Profile (BP) and Basic Security Profile (BSP) to enforce compatibility. Testing tools have been designed by WS-I to help assess whether web services are conformant with WS-I profile guidelines. Additionally, another Charter has been established to work on the Reliable Secure Profile. There is significant vendor hype concerning SOA that can create expectations that may not be fulfilled. Product stacks are still evolving 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 realise some or all of these benefits depending on the quality and relevance of the system architecture and design Is There Real Business Value Behind the Hype of SOA? , ''Computerworld'', June 19, 2006 . ''See also:'' WS-MetadataExchange OWL-S Abrobit Roy CRITICISMS OF SOA Some criticisms of SOA are based on the assumption that SOA is just another term for 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)) which do not depend on remote procedure calls or translation through XML. However, there are emerging and open-source XML parsing technolgies, such as ''' VTD-XML ,''' and various XML-compatible binary formats (http://vtd-xml.sf.net/persistence.html) that promise to significantly improve the 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. The drawback of this constraint is that it could reduce the overall scalability of the service provider because it might need to remember 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.
An informal survey by Network Computing placed SOA as the most despised buzzword (November 2006). Some critics feel SOA is merely an obvious evolution of currently well-deployed architectures (open interfaces, etc). A SOA being an architecture is the first stage of representing the system components that interconnect for the benefit of the business. At this level a SOA is just an evolution of an existing architecture and business functions. SOAs are normally associated with interconnecting back end transactional systems that are accessed via web services. The real issue with any IT "architecture" is how one defines the information management model and operations around it that deal with information privacy, reflect the business's products and services, enable services to be delivered to the customers, allow for self care, preferences and entitlements and at the same time embrace identity management and agility. On this last point, system modification (agility) is a critical issue which is normally omitted from IT system design. Many systems, including SOAs, hard code the operations, goods and services of the organisation thus restricting their online service and business agility in the global market place. Adopting SOAs is therefore just the first (diagrammatic) step in defining a real business system. The next step in the design process is the definition of a Service Delivery Platform (SDP) and its implementation. It is in the SDP design phase where 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 AND BUSINESS ARCHITECTURE One area where SOA has been gaining ground is in its power as a mechanism for defining business services and operating models and thus provide a structure for IT to deliver against the actual business requirements and adapt in a similar way to the business. The purpose of using SOA as a business mapping tool is to ensure that the services created properly represent the business view and are not just what technologists think the business services should be. At the heart of SOA planning is the process of defining architectures for the use of information in support of the business, and the plan for implementing those architectures (Enterprise Architecture Planning by Steven Spewak and Steven Hill). Enterprise Business Architecture should always represent the highest and most dominant architecture. Every service should be created with the intent to bring value to the business in some way and must be traceable back to the business architecture. Within this area, SOMA (Service-Oriented Modelling And Architecture) was announced by IBM as the first SOA-related methodology in 2004. Since then, efforts have been made to move towards greater standardization and the involvement of business objectives, particularly within the OASIS standards group and specifically the SOA Adoption Blueprints group. All of these approaches take a fundamentally structured approach to SOA, focusing on the Services and Architecture elements and leaving implementation to the more technically focused standards. SOA AND NETWORK MANAGEMENT ARCHITECTURE The principles of SOA are currently being applied to the field of Network Management . Examples of Service-Oriented network management architectures are TS 188 001 ''NGN Management OSS Architecture'' from ETSI , and the recently published M.3060 ''Principles for the Management Of Next Generation Networks'' recommendation from the ITU-T SOA. Tools for managing SOA infrastructure include:
JARGON SOA is an architectural style rather than a product. Several vendors offer products which can form the basis of, or enable, SOA--particularly Enterprise Service Bus (ESB) products. ESBs provide infrastructure that can be purchased, implemented and leveraged for SOA-based systems. SOA relies heavily on metadata design and management. Metadata design and management products are also critical to implementing SOA architectures. See the List Of SOA Related Products for an overview and ideas. LITERATURE ==Books, non-technical ==Books, technical ==Articles/Papers, non-technical ==Articles/Papers, technical ==Standards REFERENCES SEE ALSO
EXTERNAL LINKS
|
|
|