Service Oriented Architecture SOA Glossary

IBM Service Oriented Architecture SOA Glossary

BPM - Business Process Management (BPM) is a discipline combining software capabilities and business expertise through people, systems, and information to accelerate time between process improvements, facilitating business innovation.

Composite Business Services - Composite business services are collections of individual business and IT services that work together, along with a client’s existing applications, to provide specific business solutions that support the industry and semantic standards common to each industry, such as HIPAA in Healthcare, ACORD in Insurance, and SWIFT in Banking.

Connectivity - SOA connectivity enables you to exchange information between all your assets within and outside of your business through a secure, reliable, and scaleable messaging backbone for seamless communication among applications, people, and information sources.

Dashboard - Dashboards use SOA to provide a single view into how your business is operating – unifying fragmented sources of information and applications for monitoring, analysis, decision making, and execution

Entry Points - SOA Entry Points are five distinct but interrelated ways of undertaking SOA projects that encompass both a business and an IT component. They are: People, Process, Information, Connectivity, and Reuse

ESB - An Enterprise Service Bus (ESB) is a flexible connectivity infrastructure for integrating applications and services by performing the following actions between services and requestors: ROUTING messages between services, CONVERTING transport protocols between requestor and service, TRANSFORMING message formats between requestor and service, and HANDLING business events from disparate sources.

Event - An event is a significant real world action or instance which does or does not occur in a specific period of time. Services respond to events in accordance with business rules.

Governance - SOA governance helps organizations meet their SOA goals and vision by establishing decision rights, measurement, policy and control mechanisms around the services lifecycle.

Information - Information as a service is an approach that unlocks information in all its forms from its repository, process, and application silos, providing it as a trusted service to the applications, processes and decision makers who need it.

Management - SOA Management helps Deploy, Monitor, Secure, Control and Enable business processes, SOA_based services and composite applications, and the supporting IT environment.
People - People can interact with SOA-based business services and composite applications through an enabling framework of tools, and practices.

Process - A process is a set of related business tasks spanning people, systems, and information to produce a specific service or product. The process entry point provides specific tools and services to help streamline and improve processes across the enterprise. The Process entry point provides the foundation for IBM's business process management with SOA.

Registry & Repository - A central reference point within a service oriented architect that stores and manages services information (metadata). It stores information about what the services are, how they are used, and how they are interconnected with other components. This information can be used to foster reuse of services assets and to govern services throughout the lifecycle.

Reuse - Reuse addresses methods of creating the services needed to execute business tasks by service-enabling existing IT assets, consuming reusable services from an external service provider, and creating net-new reusable services from scratch.

SCA - SCA provides an open, technology-neutral model for implementing IT services that are defined in terms of a business function and make middleware functions more accessible to the application developer. SCA also provides a model for the assembly of business solutions from collections of individual services, with control over aspects of the solution such as access methods and security. Vendors working to create SCA include BEA Systems, IBM, IONA, Oracle, SAP, Siebel, and Sybase.

SDO - SDO complements SCA by providing a common way to access many different kinds of data. The specification reduces the skill levels and time required to access and manipulate business data. Today, a multitude of APIs are used to manipulate data. These APIs tend to tightly couple the source and target of the data making their use error-prone and subject to breaking as business requirements evolve. SDO makes it easier to use and realize the value of these APIs without having to code directly to them. Vendors working to create SDO include BEA Systems, IBM, Oracle, SAP, Siebel, Sybase, and Xcalia.

Security - SOA Security helps create a consistent infrastructure to support SOA projects by enableing user-centric, policy driven authentication, authorization and access to applicaitons, information and data, and consistent enforcement and auditing of corporate compliance and security policy.

Service - Services are self-contained, reusable software modules that are independent of applications and the computing platforms on which they run. Services have with well-defined interfaces and allow a 1:1 mapping between business tasks and the exact IT components needed to execute the task.

Service orientation - A way of thinking about your business processes as linked, loosely coupled tasks supported by services.

SOA - Service Oriented Architecture (SOA) is a business-driven IT architectural approach that supports integrating your business as linked, repeatable business tasks, or services. SOA helps today’s businesses innovate by ensuring that IT systems can adapt quickly, easily and economically to support rapidly changing business needs. SOA helps customers increase the flexibility of their business processes, strengthen their underlying IT infrastructure and reuse their existing IT investments by creating connections among disparate applications and information sources.

SOA foundation - Integrated, open-standard-based set of software, best practices and patterns that is designed to provide what you need to get started with your SOA.

SOA infrastructure - As clients adopt SOA this new simplified, virtualized and distributed application frameworks pose challenges for infrastructures that must be addressed. To ensure the new applications can meet their performance, availability, scalability, security and management requirements, the infrastructure needs to be assessed and transformed to support SOA.

SOA infrastructure solution - The SOA infrastructure solution from IBM is designed to help you increase business flexibility, responsiveness and performance by enabling your IT infrastructure for SOA. We start by leveraging your existing IT assets, then evaluate, design and implement the enhancements needed to establish a more flexible and robust infrastructure.

SOA lifecycle - The SOA Lifecycle defines a methodology for conducting successful SOA projects by modeling the business process and the services that will support them, assembling the services into a composite application, deploying the services in a robust, scaleable environment, managing and monitoring key IT resources and business metrics, and doing all of these lifecycle steps while adhering to solid governance and best practices.

SOA Reference Archictecture - SOA Reference Architecture defines the comprehensive IT services required to support your SOA at each stage in the SOA life cycle.

SOA Scenarios - SOA Scenarios define specific SOA projects customers can implement while focusing on a very small number of targeted software products and/or services per project.

SOA Introduction - Fundamental Design Terminology and Concepts

Fundamental Design Terminology and Concepts - SOA Service Oriented Architecture Introduction

SOA Introduction : Before we can begin exploring the details of service-oriented computing, we first need to establish some basic design terminology. The books in this series use a common vocabulary comprised of the following design-related terms:

- Design Characteristic
- Design Principle
- Design Paradigm
- Design Pattern
- Design Pattern Language
- Design Standard
- Best Practice

Depending on your sources, you will find differing definitions for these terms. More often than not, though, you will notice that they all are somewhat intertwined. The upcoming pages explain each term and the following figure illustrates how they inter-relate.

Figure: Fundamental design terms establish a basic taxonomy used throughout the upcoming chapters. This diagram hints at how some parts of a basic design framework can relate to each other.

Source: http://www.whatissoa.com/

Defining SOA service-oriented architecture

Defining SOA service-oriented architecture

This section will address defining SOA service-oriented architecture and look at what makes it unique.

Key elements

It's important to understand the key elements of service-oriented architecture SOA. With that goal in mind, let's begin by breaking down the service-oriented architecture SOA acronym into its core elements. We'll start with the last part first: architecture.

Let's look at the architecture in the context of service-oriented architecture SOA. Typically in software, architecture defines the overall definition and intercommunication of various high-level components. In simple terms, it's how we break down a solution into logical units and how they'll interoperate. In this sense, SOA represents an architectural approach that's focused on the definition and interaction of services.

Because service-oriented architecture SOA is a set of architectural principles, you can't go out and buy one. You may be able to buy middleware components that provide enabling technologies and core services. But by themselves, they aren't an SOA.

Let's move on to another piece of SOA: service-oriented. Service-oriented means that we'll center our solution architecture on a collection of services. If you've had experience with Object Oriented Design (OOD), this may seem familiar. In fact, these two approaches have many elements in common.

A service is a way of thinking about and organizing business functionality so it can effectively stand on its own. The service-oriented architecture SOA approach considers this functionality in terms of service providers and service consumers.

Service providers offer functionality as a set of interfaces to the service capabilities they provide. Service consumers will access the service capabilities provided by the service provider. These consumers may be an application or even a service provider. For example, a checking account service may offer a set of functionality relating to a checking account. This account may offer the ability to make a deposit, make a withdrawal, create a new account, etc. Notice that the capabilities we've described are very specific to the concept of checking account service. Also notice that we haven't yet said whether this service is provided by some banking software, by an ATM machine, by a teller in a bank, or all of the above.

Some may argue that this definition of service-oriented architecture SOA is just the latest way to describe and model application functionality. But it is important to realize that most applications today have been built with an end user in mind. To that end, an application may encapsulate a group of tasks that are related in some ways but are also discrete.

One of the key distinctions of an SOA service-oriented architecture is the fact that the consumer of some application functionality may in fact be another application or service. While human users tend to prefer all functionality aggregated together and accessible through one user interface, other applications don't have the same requirement. As a result, it makes sense to have functionality organized around a set of services that can be self-contained and yet can be woven together to create higher level functionality or services.

Once you apply these architectural principles, you'll end up with a set of services that can interact to provide a specific set of functionality with a business benefit. And now re-use comes into play: You could rapidly build another solution that reuses some of these services as well as some additional services that may be required to satisfy the business requirements. In the end, these services are woven into a kind of software ecosystem. Here, they cooperate to achieve a business objective but may also participate in other ecosystems that offer the same service capability for potentially different end solutions.

Why SOA Service Oriented Architecture?

Why SOA?

Most IT organizations today must justify their projects with an expected return on investment. IT now faces pressures on a number of fronts:

Requirements to be more responsive and flexible to shifting business needs
Challenges of handling often-incompatible, heterogeneous software systems
Demands to bring new business services to a broader array of consumers ranging from customers accessing services via web interfaces, to partners sharing information to improve working relationships and deliver increasing value to mutual customers, to companies sharing information with the supply chain to decrease manufacturing time and costs
Understandably, IT organizations are seeking solutions to help them meet these increasing demands in the most cost-effective way.

The value of SOA Service Oriented Architecture has perhaps been oversold as a methodology and has often been mistakenly promoted as a technology that will solve all of the problems discussed above. However, an SOA approach can in fact bring numerous benefits to an IT organization. Let's look at these potential benefits within three categories:

Standarized interfaces and data models: SOA Service Oriented Architecture can help reduce costs of building new functionality from heterogeneous software systems and incompatible data by providing standardized interfaces and data models.

Re-use: If done properly, these service definitions and data models enable the ability for re-use, thereby reducing the overall cost of application development projects built on these principles. This is especially true for ongoing maintenance and building new applications built by leveraging existing services.

Composability: SOA Service Oriented Architecture enables the idea of composability. This means that new services can be rapidly built from existing services. This ability makes IT organizations more agile than ever before, as they can then respond to continuously evolving business objectives. This may make it possible for you to leverage not only your own services, but also services from other organizations, from partners, or from suppliers with whom you contract to provide these services.

What is SOA service-oriented architecture?

What is SOA service-oriented architecture? An introduction to SOA By Raghu R. Kodali

Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. An application's business logic or individual functions are modularized and presented as services for consumer/client applications. What's key to these services is their loosely coupled nature; i.e., the service interface is independent of the implementation. Application developers or system integrators can build applications by composing one or more services without knowing the services' underlying implementations. For example, a service can be implemented either in .Net or J2EE, and the application consuming the service can be on a different platform or language.

SOAService-oriented architectures have the following key characteristics:

Service-oriented architecture SOA services have self-describing interfaces in platform-independent XML documents. Web Services Description Language (WSDL) is the standard used to describe the services.

Service-oriented architecture SOA services communicate with messages formally defined via XML Schema (also called XSD). Communication among consumers and providers or services typically happens in heterogeneous environments, with little or no knowledge about the provider. Messages between services can be viewed as key business documents processed in an enterprise.

Service-oriented architecture SOA services are maintained in the enterprise by a registry that acts as a directory listing. Applications can look up the services in the registry and invoke the service. Universal Description, Definition, and Integration (UDDI) is the standard used for service registry.

Each SOA service has a quality of service (QoS) associated with it. Some of the key QoS elements are security requirements, such as authentication and authorization, reliable messaging, and policies regarding who can invoke services.

Why SOA Service-oriented architecture?

The reality in IT enterprises is that infrastructure is heterogeneous across operating systems, applications, system software, and application infrastructure. Some existing applications are used to run current business processes, so starting from scratch to build new infrastructure isn't an option. Enterprises should quickly respond to business changes with agility; leverage existing investments in applications and application infrastructure to address newer business requirements; support new channels of interactions with customers, partners, and suppliers; and feature an architecture that supports organic business. Service-oriented architecture SOA with its loosely coupled nature allows enterprises to plug in new services or upgrade existing services in a granular fashion to address the new business requirements, provides the option to make the services consumable across different channels, and exposes the existing enterprise and legacy applications as services, thereby safeguarding existing IT infrastructure investments.

Service-oriented architecture (SOA) definition

Service-oriented architecture (SOA) definition

A service-oriented architecture SOA is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.

Service-oriented architectures SOA are not a new thing. The first SOA service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification. For more on DCOM and CORBA, see Prior service-oriented architectures (new window).

Services
If a SOA service-oriented architecture is to be effective, we need a clear understanding of the term service. A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. See Service (new window).

Connections
The technology of Web services (new window) is the most likely connection technology of SOA service-oriented architectures. Web services essentially use XML (new window) to create a robust connection.

The following figure illustrates a basic SOA service-oriented architecture. It shows a service consumer at the right sending a service request message to a service provider at the left. The service provider returns a response message to the service consumer. The request and subsequent response connections are defined in some way that is understandable to both the service consumer and service provider. How those connections are defined is explained in Web Services explained (new window). A service provider can also be a service consumer.

10 steps to SOA

10 steps to SOA - Service-oriented architecture begins and ends with business process marshaling a sprawling set of technologies along the way. Don’t know where to start? Try Step 1
By Oliver Rist

SOA is an idea, not a technology.

True, SOA (service-oriented architecture) builds on the stack of protocols that define Web services, but it is hardly limited to that stack and draws as much on time-honored notions of business “re-engineering” as it does on XML, SOAP, and WSDL. Simply put, SOA is a broad, standards-based framework in which services are built, deployed, managed, and orchestrated in pursuit of new and much more agile IT infrastructures that respond swiftly to shifting business demands.

The breadth of that vision is what makes service-oriented architecture SOA seem so maddeningly vague. Nonetheless, the potential benefits of reduced IT costs and greater business agility have spurred many organizations to start down the path to service-oriented architecture SOA, to the point where most large enterprises now have some sort of SOA initiative under way. One reason for that extraordinary traction: SOA service-oriented architecture may ultimately have a transformative effect on the entire enterprise, but in contrast to other “big bang” endeavors, most of the applications and infrastructure you’ve already deployed can remain in place.

Throughout the past two years, InfoWorld has interviewed countless enterprise architects, developers, and officers who are guiding their organizations toward service-oriented architecture SOA deployment -- and who are learning hard lessons, gaining insight, and encountering infuriating technology gaps along the way. Many are already enjoying service-oriented architecture SOA’s early benefits of easy integration and code reusability. Based on their experiences, and the advice of industry technologists and analysts, we offer this step-by-step guide to planning, building, deploying, and managing an SOA service-oriented architecture.

As you’ll see, service-oriented architecture SOA provokes many of the same questions that dog most grand IT schemes. Should you buy and deploy service-oriented architecture SOA-related technology from a single vendor with which you already have a close relationship, or should you mix and match best-of-breed solutions? And, as with any standards-based initiative, what do you do when many of the standards necessary to achieve the real benefits aren’t fully cooked yet?

Such questions lack easy answers, and missing pieces of technology, industry disagreements, and vendor lock-in all threaten to dampen service-oriented architecture SOA’s much-ballyhooed benefit of hyperagility. Nonetheless, you’ll find most of the key concepts underlying SOA, a number of which may be familiar, right here -- although not necessarily in exactly the right order for you. Just as with service-oriented architecture SOA itself, how you put it all together depends on what you’ve got and where you want to go.

What are the benefits of SOA?

What are the benefits of Service Oriented Architecture SOA?

Service-oriented architecture is, first and foremost, a means of attaining greater business agility from existing IT investments. Service Oriented Architecture SOA-based solutions connect systems and thereby automate previously manual information-transfer processes whether the goal is to develop new applications; to connect systems, workgroups, or geographically distributed subsidiaries; or to collaborate with trading partners. At the same time, Service Oriented Architecture SOA solutions build in the essential services required to ensure that the appropriate resources are accessed by the appropriate users.

Service Oriented Architecture SOA benefits accrue for the organization at two different levels, that of the IT organization and that of the business user; in the end, all benefits add up to a dramatic increase in agility and productivity.

From the IT department’s point of view, Service Oriented Architecture SOA-based integration simplifies management of distributed resources across multiple platforms, requires less hardware, is more reliable, is standards-based, and is less costly.

From the business point of view, Service Oriented Architecture SOA enables development of a new generation of dynamic applications addressing a number of top-level business concerns that are central to growth and competitiveness. Service Oriented Architecture SOA solutions promote:

• Stronger connections with customers and suppliers. By making dynamic applications and business services available to external customers and suppliers, not only is richer collaboration possible, but also customer/partner satisfaction is increased. Service Oriented Architecture SOA unlocks critical supply and demand chain processes—such as outsourcing of specific business tasks—from the constraints of underlying IT architectures, thereby enabling better alignment of processes with organizational strategy.

• Enhanced business decision making. By aggregating access to business services and information into a set of dynamic, composite business applications, decision makers gain more accurate and more comprehensive information. They also gain the flexibility to access that information in the form and presentation factor (Web, rich client, mobile device) that meets their needs.

• Greater employee productivity. By providing streamlined access to systems and information and enabling business process improvement, businesses can drive greater employee productivity. Employees can focus their energies on addressing the important, value-added processes and on collaborative, semi-structured activities, rather than having to conform to the limitations and restrictions of the underlying IT systems.

What is the SOA life cycle?

What is the Service Oriented Architecture SOA life cycle?

The core IT assets of any organization include its data, legacy systems, line-of-business applications, packaged applications, and trading partners. Each of these resources is a service provider responsible for producing numerous highly specific outputs, such as inventories and customer data.

Service orientation ties together these disparate and autonomous sources of information, bridging a wide range of operating systems, technologies, and communication protocols. The process by which it does this is an iterative one of creating (“exposing”) new services, aggregating (“composing”) these services into larger composite applications, and making the outputs available for consumption by the business user.

Expose

The expose phase of the service oriented architecture SOA approach focuses on which services to create from the underlying applications and data. Service creation can be fine-grained (a single service that maps to a single business process) or coarse-grained (multiple services come together to perform a related set of business functions).

The expose phase is also concerned with how the services are implemented. The functionality of underlying IT resources can be made available natively if they already speak Web services, or can be made available as Web services though the use of an adapter.

Compose

Once services are created, they can be combined into more complex services, applications, or cross-functional business processes. Because services exist independently of one another as well as of the underlying IT infrastructure, they can be combined and reused with maximum flexibility. And as business processes evolve, business rules and practices can be adjusted without constraint from the limitations of the underlying applications.

Consume

Once a new application or business process has been created, that functionality must be made available for access (consumption) by either other IT systems or by end users. The goal of the consumption process is to deliver new, dynamic applications that enable increased productivity and enhanced insight into business performance. Users can consume the composed service through a number of avenues, including Web portals, rich clients, Office business applications, and mobile devices.

Before starting a SOA

Before starting a SOA Service Oriented Architecture

Before a developer writes a single line of code, it is critical to identify both specific business drivers of the service oriented architecture SOA endeavor and the dependencies between the business and the underlying technologies. Neglecting the business context can result in a project in which service oriented architecture SOA infrastructure is pursued for its own sake, or where investments are made that do not line up well with the needs and priorities of the business.

Two approaches are commonly pursued for implementing service oriented architecture SOA: top-down and bottom-up. Both approaches have possible pitfalls that can prevent success. Many organizations that have attempted to roll out service oriented architecture SOA infrastructure through a top-down approach have discovered that when the infrastructure is finally delivered it is out of sync with the needs of the business. Likewise, a bottom-up approach can fail as well, because it can lead to a chaotic implementation of services created without regard to organizational goals.

The “middle-out” approach is a successful hybrid of the two other approaches. Business drivers and strategic vision are first employed to set clear direction and priorities. Based on these, the organization takes multiple iterative steps to build out slices of end-to-end capabilities, with each iteration delivering a new, dynamic application back to the business that is used to create business return. Microsoft has long advocated this “real-world” approach to leveraging service-oriented architectures: The approach is focused on rapid time-to-value, and it delivers business results through iterative, incremental steps that facilitate close alignment of IT resources with changing business conditions.

What SOA isn’t

What SOA isn’t

There are numerous misconceptions about what service oriented architecture SOA is—that it is a product that can be purchased (it is not; it is a design philosophy that informs how the solution should be built); that the goal is to build a Sservice oriented architecture OA (it is not; SOA is a means to an end); or that SOA requires a complete technological and business process overhaul (it doesn’t; SOA solutions should be incremental and built on current investments).

SOA is also often equated with Web services, and the terms used interchangeably. While it is true that service oriented architecture SOA is made easier and more pervasive through the broad adoption of Web services–based standards and protocols, the two are distinct. SOA service oriented architecture is an approach to designing systems—in effect the architectural drawings or blueprint—that directs how IT resources will be integrated and which services will be exposed for use. In contrast, Web services is an implementation methodology that uses specific standards and language protocols to execute on a service oriented architecture SOA solution.

Who does SOA?

Who does SOA Service Oriented Architecture?

Strictly speaking, service oriented architecture SOA is done by developers and solution architects. However, stakeholders in a service-oriented solution span a range of roles, and it is critical that their interests not only be taken into account but that they actively drive the design of the service oriented architecture SOA solution.

Starting with those interests, the business analyst is concerned with bringing IT investments more in line with the business strategy. For the developer, this means that the service oriented architecture SOA solution must map the sources of business information—systems, staff, trading partners—into a unified and comprehensive view such that the business analyst has greater insight into the costs and benefits of various investments.

The chief technology officer (CTO) of the organization will work with developers to ensure that when designing a solution to meet the needs of the business analyst, the integrity of existing IT systems and applications resources are preserved, even as new capabilities are developed.

And the IT manager, concerned with effectively integrating distributed systems such that management is simplified, will work with the developer to ensure that these goals are also met.

Ultimately, the developers and solution architects are concerned with creating dynamic collaborative applications that meet the goals of the various stakeholders. The service orientation approach enables them to do so in a way that meets the needs of the organization as a whole.

Why SOA?

Why SOA Service Oriented Architecture?

Complex, distributed IT resources are a concern for businesses. Too frequently, the existing IT portfolio does not adequately meet specific business needs, is costly to manage and maintain, and is inflexible in the face of business growth and change. The solution, however, is not to rip and replace systems or applications, nor to completely renovate them, but rather to find a way to leverage existing IT investments so that overall organizational goals are effectively supported.

Service orientation helps to accomplish these goals by making systems more responsive to business needs, simpler to develop, and easier to maintain and manage. Implementing a solution architecture based upon service orientation helps organizations plan ahead for change, rather than responding reactively.

SOA defined

SOA defined

Service orientation is a means for integrating across diverse systems. Each IT resource, whether an application, system, or trading partner, can be accessed as a service. These capabilities are available through interfaces; complexity arises when service providers differ in their operating system or communication protocols, resulting in inoperability.

Service orientation uses standard protocols and conventional interfaces—usually Web services—to facilitate access to business logic and information among diverse services. Specifically, service oriented architecture SOA allows the underlying service capabilities and interfaces to be composed into processes. Each process is itself a service, one that now offers up a new, aggregated capability. Because each new process is exposed through a standardized interface, the underlying implementation of the individual service providers is free to change without impacting how the service is consumed.

What is Service Oriented Architecture?

What is Service Oriented Architecture SOA?

IT departments are managing increasingly complex IT portfolios. Yet as business needs change, these departments must still ensure that their technologies remain aligned with business goals. Failure to do so compromises organizational agility.

The problem for IT departments is typically not insufficient functionality; rather, it is that critical business systems such as customer relationship management (CRM) and enterprise resource planning (ERP) operate in isolation from other critical business systems—despite the fact that business processes often span multiple applications. To obtain an end-to-end view of a complex business process necessitates integration of information and process silos. In the past, this has been accomplished either though time-consuming manual interventions, or through hard-coded solutions that are difficult to maintain.

Service orientation is an approach to organizing distributed IT resources into an integrated solution that breaks down information silos and maximizes business agility. Service orientation modularizes IT resources, creating loosely coupled business processes that integrate information across business systems. Critical to a well-designed service-oriented architecture is producing business process solutions that are relatively free from the constraints of the underlying IT infrastructure, because this enables the greater agility that businesses are seeking.

Service Oriented Architecture (SOA) ultimately enables the delivery of a new generation of dynamic applications (sometimes called composite applications). These applications provide end users with more accurate and comprehensive information and insight into processes, as well as the flexibility to access it in the most suitable form and presentation factor, whether through the Web or through a rich client or mobile device. Dynamic applications are what enable businesses to improve and automate manual tasks, to realize a consistent view of customers and partner relations, and to orchestrate business processes that comply with internal mandates and external regulations. The net result is that these businesses are able to gain the agility necessary for superior marketplace performance.

at's the difference between SOA and web services?

What's the difference between SOA and web services?

SOA Service Oriented Architecture is the overarching strategy for building software applications inside a company—think of an architectural blueprint—except that in this case, the architecture calls for all the pieces of software to be built using a particular software development methodology, known as service-oriented programming.

Web services, meanwhile, are a set of standard communication mechanisms built upon the World Wide Web. Web services are a linking and communications methodology. SOA is an overall IT strategy.

Source: http://www.cio.com

What is SOA and Service?

What is Service-Oriented Architecture (SOA)?

SOA Service Oriented Architecture is a confusing term because it describes two very different things. The first two words describe a software development methodology. The third word, architecture, is a picture of all the software assets of a company, much as an architectural drawing is a representation of all the pieces that together form a building. Therefore, service-oriented architecture SOA is a strategy that proclaims the intention to build all the software assets in the company using the service-oriented programming methodology.

What is a service?

Services are software chunks, or components, constructed so that they can be easily linked with other software components. The idea behind these services is simple: Technology should be expressed in chunks that business people can understand rather than as an arcane application such as ERP or CRM.

At the core of the services concept is abstraction, the idea that you can assemble software code into a chunk meaningful enough that it can be shared and reused in many different areas of the company. For example, there is a lot of software code that goes into creating an automated task such as sending a query to a credit reporting website to find out if a customer qualifies for a loan. But if the programmers at a bank can abstract all that code to a higher level—that is, take all the code that was written to perform the credit rating check and package it into a single unit called "get credit rating"—the programmers can reuse that chunk the next time the bank decides to launch a new loan product that requires the same information rather than having to write the code from scratch.

Developers create the abstraction by building a complex wrapper around the bundled code. This wrapper is an interface that describes what the chunk does and how to connect to it. It's an old concept that dates back to the 1980s, when object-oriented programming first appeared; the only difference is that today, the ambition for the size and sophistication of these software objects is far more grand.

For example, at telecom company Verizon, the service called "get CSR" (get customer service record) is a complex jumble of software actions and data extractions that uses Verizon's integration infrastructure to access more than 25 systems in as many as four data centers across the country. Before building the "get CSR" service, Verizon developers who needed that critical lump of data would have to build links to all 25 systems—adding their own links on top of the complex web of links already hanging off the popular systems. But with the "get CSR" service sitting in a central repository on Verizon's intranet, those developers can now use the simple object access protocol (SOAP) to build a single link to the carefully crafted interface that wraps around the service. Those 25 systems immediately line up and march, sending customer information to the new application and saving developers months, even years, of development time each time they use the service.

There are many different ways to connect services, such as custom programming links or integration software from vendors, but since 2001, a set of software communication mechanisms known as web services, which are built upon the ubiquitous World Wide Web, have become an increasingly popular method for linking software components together.

Source: http://www.cio.com

SOA Service-oriented design and development

SOA Service-oriented design and development

The modelling and design methodology for Service Oriented Architecture SOA applications has become known by the terms service-oriented analysis and design and SOAD [8]. 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:

Header
Name - Name of the service. Should indicate in general terms what it does, but not be the only definition
Version - The version of this service contract
Owner - The person/team in charge of the service
RACI
Responsible - The role the person/team is responsible for the deliverables of this contract/service. All versions of the contract
Accountable - Ultimate Decision Maker in terms of this contract/service
Consulted - Who must be consulted before action is taken on this contract/service. This is 2-way communication. These people have an impact on the decision and/or the execution of that decision.
Informed - Who must be informed that a decision or action is being taken. This is a 1-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:
Presentation
Process
Business
Data
Integration
Functional
Functional Requirement (From Requirements Document) - Indicates the functionality in specific bulleted items what exactly this service accomplishes. The language should be such that it allows 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 the invocation means of the service. This includes the URL, interface, etc. There may be multiple Invocation paths for the same service. We may have the same functionality for an internal and external clients each with a different invocation means and interface. Examples:
SOAP
REST
Events Triggers
Non-Functional
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

Source: http://en.wikipedia.org/wiki/Service-oriented_architecture
Home: SOA Service Oriented Architecture

SOA principles

SOA Service Oriented Architecture principles

The following guiding principles define the ground rules for development, maintenance, and usage of the Service Oriented Architecture SOA.

Reuse, granularity, modularity, composability, componentization, and interoperability
Compliance to standards (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 behaviour of a system and the style of its design:

- Service Encapsulation
- 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 what is described 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 considered 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.

In addition, the following factors should also be taken into account when defining a SOA implementation:

- Service Oriented Architecture SOA Reference Architecture SOA Practitioners Guide Part 2: SOA Reference Architecture covers the SOA Reference Architecture, which provides a worked design of an enterprise-wide Service Oriented Architecture 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 Service Oriented Architecture SOA Practitioners Guide Part 3: Introduction to Services Lifecycle introduces the Services Lifecycle and provides a detailed process for services management though the service lifecycle, from inception through to retirement or repurposing of the services. It also contains an appendix that includes organization and governance best practices, templates, comments on key Service Oriented Architecture SOA standards, and recommended links for more information.
- Efficient use of system resources
- Service maturity and performance
- EAI Enterprise Application Integration

Source: http://en.wikipedia.org/wiki/Service-oriented_architecture
Home: SOA Service Oriented Architecture

Why SOA?

Why Services-Oriented Architecture SOA?

The main drivers for Services-Oriented Architecture SOA adoption are that it links computational resources and promotes their reuse. Enterprise architects believe that Services-Oriented Architecture SOA can help businesses respond more quickly and cost-effectively to changing market conditions[5] . This style of architecture promotes reuse at the macro(service) level rather than micro(objects) level. It can also simplify interconnection to - and usage of - existing IT (legacy) assets.

Services-Oriented Architecture SOA Practitioners Guide: Why Services-Oriented Architecture? provides a high-level summary on SOA.

In some respects, SOA Services-Oriented Architecture 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.[citation needed]

Some have questioned whether Services-Oriented Architecture SOA is just a revival of modular programming (1970s), event-oriented design (1980s) or interface/component-based design (1990s)[citation needed]. 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

Source: http://en.wikipedia.org/wiki/Service-oriented_architecture