Service-Oriented Computing (SOC) and Service-Oriented Architecture (SOA) W. T. Tsai Department of Computer Science and Engineering Arizona State University Tempe, AZ 85287 [email_address]
Definition of Service
A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners.
A service in SOA can be a web service (WS), but not necessarily be. Any self-contained well-defined components, not necessarily on the web, can be used in an SOA application.
Definition of SOA
A Service-Oriented Architecture (SOA) is a system consisting of modular software components with standardized component-access and usage interfaces that are independent of any specific platform or implementation technology.
At its most basic, an SOA is simply a collection of standardized services on a network that communicate with one another in the context of a business process.
Example of SOA
This definition of SOA is a bit too abstract, but SOA is actually everywhere.
Let's look at an example of SOA which is likely to be found in your living room. Take a CD for instance. If you want to play it, you put your CD into a CD player and the player plays it for you. The CD player offers a CD playing service. Which is nice because you can replace one CD player with another. You can play the same CD on a portable player or on your expensive stereo. They both offer the same CD playing service, but the quality of service is different.
Difference from OO Programming
The idea of SOA departs significantly from that of OO programming, which strongly suggests that you should bind data and its processing together. So, in OO programming style, every CD would come with its own player and they are not supposed to be separated. This sounds odd, but it's the way we have built many software systems.
Difference from Web Service
Web services does not equal service-oriented architecture . Web services is a collection of technologies, including XML, SOAP, WSDL, and UDDI, which let you build programming solutions for specific messaging and application integration problems.
Over time, you can reasonably expect these technologies to mature, and eventually be replaced with better, more efficient, or more robust ones.
They are, at the very least, a proof of concept that SOAs can finally be implemented. So what actually does constitute a SOA?
Difference from Web Service (Cont.) * The above table is from Microsoft’s website 
Difference from Web Service (Cont.)
SOA is just an architecture. It is more than any particular set of technologies, such as Web services; it transcends them, and, in a perfect world, is totally independent of them. Within a business environment, a pure architectural definition of a SOA might be something like "an application architecture within which all functions are defined as independent services with well-defined invokable interfaces which can be called in defined sequences to form business processes". Note what is being said here:
All functions are defined as services.
All services are independent.
In the most general sense, the interfaces are invokable;
Why we need SOA for IT management?
Systinet  discusses the advantages to apply SOA on IT management.
An SOA enables software components to become standard services that can be invoked at runtime or on demand.
A business-driven SOA strategy will help focus on the goal of Dynamic Business Interoperability and lead to achievement of desired business outcomes.
Advantages of SOA
First, SOAs make interoperability an innate characteristic of IT systems and applications built using this approach because the resulting loosely coupled and modular components share common communication and interface description mechanism. Organizations don’t have to invest inordinate amounts of time and resources writing code to connect applications, only to have to rewrite code again if small changes are made to the system.
Second, SOAs make IT more agile and more responsive to business process changes. Since services represent high-level business logic, IT is encouraged to think in terms of business functions. With SOA, IT systems begin to accurately and quickly adapt to organizational goals and processes. SOAs also make IT highly tolerant of change because reconfiguring loosely coupled services is simple, fast and low-cost. With an SOA, IT is able to react quickly to changing business demands, new requirements, or new processes.
What you need to think about when building SOA?
Understand the Business Model
Focus on Interoperability
Focus on Business Agility
Define and Enforce Application Interoperability Policies
How Web services will be used?
What standards and interoperability policies must be defined and enforced?
How these will be driven within a SOA context?
Change IT Procurement Policies
Ongoing management of your SOA will demand vendor compliance to your SOA strategy and interoperability policy.
What you need to think about when building SOA? (Cont.)
Transform Your IT Development Processes and Policies
The compliance to WS-I and internal standards should be enforced at design and runtime using available WSM and SOA enforcement tools.
Define and Enforce Your Business Interoperability Policies
Monitor, Measure and Analyze SOA Service Network
Are the services leveraging one another in a symbiotic network fashion?
Are we getting the maximum interoperability and services reuse from our SOA? If not, why not? Are policies being enforced at design and run-time?
Do we have a truly interoperability-based SOA or do we have islands of business and Web services? How can we unite these services?
Finally, were your initial SOA business goals met? How can we improve our performance? If our goals were not met, why not? What must be done?
The process of delivering the service implementation
Web Services automated by tools
The provisioning of the service—the life cycle of the service as a reusable artifact
Internal and External View
Service Level Management
The consumption process
Business Process Driven
Service Consumer could be internal or external
Solution assembly from Services, not code
Increasingly graphical, declarative development approach
Could be undertaken by business analyst or knowledge worker
SOA business services are defined and created based on the business model.
Standards-based business service registry.
Supporting infrastructure such as Web services management, identity management, and service-oriented messaging services.
Definition of the procedures and policies, like:
Who is allowed to publish a service to the registry?
What release procedures must be followed?
How will various designs, standards and security policies be approved, certified and enforced in the SOA?
SOA Process (Cont.)
Building and deploying the ability to understand and manage relationships between business services
Component versioning and dependencies
Effecting reconfiguration of various aspects of a deployment such as location, transport, security and policy parameters
Monitoring and feedback mechanisms to help optimize SOA and ultimately, enable an organization’s business processes by SOA
Monitoring services status, users, usages, and metrics that indicate relative success of various business services in the SOA services portfolio
Providing impact and dependency analysis of individual services, groupings of services based on custom taxonomies (enabled by the registry)
Reporting on a wide variety of issues – business, IT, SOA, reuse, policy violations or compliance reporting, and so on
SOA Dynamic Discovery
Dynamic discovery is an important piece of SOA. At a high level, SOA is composed of three core pieces: service providers, service consumers, and the directory service. The role of providers and consumers are apparent, but the role of the directory service needs some explanation. The directory service is an intermediary between providers and consumers. Providers register with the directory service and consumers query the directory service to find service providers. Most directory services typically organize services based on criteria and categorize them. Consumers can then use the directory services' search capabilities to find providers. Embedding a directory service within SOA accomplishes the following:
Scalability of services; you can add services incrementally.
Decouples consumers from providers.
Allows for hot updates of services.
Provides a look-up service for consumers.
Allows consumers to choose between providers at runtime rather than hard-coding a single provider.
A Typical Architecture for a Service-Oriented Application
Like any distributed application, service-oriented applications are multi-tier applications and have presentation, business logic, and persistence layers. The two key tiers in SOA are the services layer and the business process layer.
SOA Architectural Perspective
The following three SOA architectures need to be considered:
The Application Architecture . This is the business facing solution which consumes services from one or more providers and integrates them into the business processes.
The Service Architecture . This provides a bridge between the implementations and the consuming applications, creating a logical view of sets of services which are available for use, invoked by a common interface and management architecture.
The Component Architecture . This describes the various environments supporting the implemented applications, the business objects and their implementations.
SOA Architectural Perspective (Cont.)
Basic Components of SOA Architecture
Service providers . A service provider is a component or set of components that execute a business function in a stateless fashion, accepting predefined inputs and outputs.
Service consumers . A service consumer is a set of components interested in using one or more of the services provided by service providers.
Service repository . A service repository contains the descriptions of the services. Service providers register their services in this repository and service consumers access the repository to discover the services being provided.
Basic Components of SOA Architecture (Cont.)
SOA Challenges and Solutions
While implementing a SOA, a company faces up to eight key challenges. These challenges align to the steps in a typical project deployment plan:
Service identification . What is a service? What is the business functionality to be provided by a given service? What is the optimal granularity of the service?
Service location . Where should a service be located within the enterprise?
Service domain definition . How should services be grouped together into logical domains?
Service packaging . How is existing functionality within legacy mainframe systems to be re-engineered or wrapped into reusable services?
Service orchestration . How are composite services to be orchestrated?
Service routing . How are requests from service consumers to be routed to the appropriate service and/or service domain?
Service governance . How will the enterprise exercise governance processes to administer and maintain services?
Service messaging standards adoption . How will the enterprise adopt a given standard consistently?
Another Challenge of Current SOA
However, current SOA can not satisfy the survivability requirements. It fails to discover and rebind to available services automatically upon the failure or overload of the on-duty service.
Mission-critical systems will be subjected to various attacks including physical attacks as well as electronic attacks.
One key feature of survivability is that the system is able to dynamically reconfigure in case of failures or overload.
The solution of this problem is service-oriented distributed dynamic reconfiguration.
Potential Application: NCES Vision Core Enterprise Services (CES) Comms Backbone Community-of-Interest (COI) Capabilities Users Messaging ESM Discovery Collaboration Mediation Security/IA App Storage User Asst Levels of Services above core level Support real-time & near-real-time warrior needs and business users 05/06/10 C2 Intel Weapon Systems Dynamically Created COIs Logistics Sensors Personnel Finance Etc.
Requirements for the distributed dynamic reconfiguration.
Efficiency: the reconfiguration algorithm should introduce minimum disruption to the system
Consistency: the reconfiguration action should maintain the consistency of related components after reconfiguration.
Correctness: Reconfiguration constraints must be satisfied at all the times.
Real time: Reconfiguration must be carried out in real time at runtime for mission-critical C2 system .
Real time means within a time limit
Runtime means that the reconfiguration must be carried out while the system is still in operation.
Requirements for the distributed dynamic reconfiguration (cont’)
Policy driven: system is governed by business policy, possibly distributed policies.
Distributed and parallel execution.
Reconfiguration actions are executed by the distributed agents and the reconfiguration actions are done in parallel among these agents.
The dynamic reconfiguration server or agents are themselves services in the SOA, so that they can be reconfigured too in case of their own failures.
Dynamic Reconfiguration with hierarchical and layered system
This promotes survivability
Solution: Dynamic Reconfiguration Model for SOA
A Layered Partitioning of System with Dynamic Reconfiguration– A Systematic View Network Services
A Layered Partitioning of System with Dynamic Reconfiguration– A Systematic View (cont’)
Dynamic Reconfigurability is embedded in each layer of the entire system, and at each level multiple DRS synchronized with each other to avoid any single point of failure.
Hierarchic System Composition with Dynamic Reconfiguration
Hierarchic System Composition with Dynamic Reconfiguration
For large scale applications, hierarchic dynamic reconfiguration allows the distributed systems to be constructed in a hierarchical manner.
A composite system can be constructed from primitive systems with dynamic reconfigurability and these in turns can be constructed into more complex composite system with dynamic reconfigurability.
SOA with Dynamic Reconfiguration
Every participating service, including DRS, is a service and each service is treated the same. As a service, the DRS provides the following functions:
Dynamic service lookup, service publication, service binding, and service profiling,
Registration and de-registration,
Runtime services verification including constraint verification such as security verification, interoperability checking, and performance monitoring.
SOA with Dynamic Reconfiguration (cont’)
The Dynamic Reconfiguration Service (DRS) is implemented as a critical service with redundancy and the reconfiguration strategies and algorithms can be changed at runtime to fit the warfighting needs.
With this kind of mechanism, the behavior of the SOA can be changed in real time at runtime, and even the behavior of DRS can be changed too.
Architecture of DRS and its Distributed Agents DRS Coordination Services Clients Services Business Polices Proxy Services Auditing Services Service Register COIs Access Control
Architecture of DRS (cont’) Major Agents
Service Directory (SD): This stores and organizes services in a hierarchical tree with internal tree node representing a group of related services.
Proxy Agents: An Proxy Agent (PA) is responsible for interoperability and integration between DRS, services and their clients. In addition, it also enforces security accessing control.
Auditing Agents: An Audit Agent (AA) monitors and checks the performance and user concerned properties of the participating services at runtime and updates their profiles.
Cyclic Flow of Dynamic Reconfiguration Process Services Dynamic Reconfiguration Services Monitoring Services Data COIs Human Participation Real-time Data Reconfiguration Actions Reconfiguration Actions Policies
Dynamic Policy Adaptation and Validation
Dynamic Policy Adaptation
Through the cyclic flow of situation aware of environment data collect and monitoring, reconfiguration policy formation, policy validation and reconfiguration execution.
Commander in the loop
Reconfiguration Constraints are represented by Meta Business Policy and it will validate the reconfiguration policy in real time at runtime
GIG Enterprise Services SOADR Supports real-time & near-real-time warrior needs DoD (Title 10) IC (Title 50) Users Users Business Domains Warfighter Domains Domain/ COI Capabilities IC Org Spaces National Intelligence Domain Transformational Communications (TC) & Computing Infrastructure ICSIS Community Space Technical Infrastructure Domain Levels of Services Above Core Level Capability Integrator Installations & Environment Human Resources Management Acquisition Strategic Planning & Budget Logistics Accounting & Finance Governance COI’s COI’s Capability Integrator Command & Control Battlespace Awareness Force Application Precision Logistics Protection Governance Net-Centric Enterprise Services (NCES) Application User Assistant Storage Messaging IA/Security IA/Security ESM IA/Security ESM IA/Security ESM Discovery IA/Security ESM Collaboration IA/Security ESM Enterprise Service Management (ESM) Mediation IA/Security ESM IA/Security ESM ESM IA/Security
Cyclic Flow of Dynamic Reconfiguration Process (cont’)
The dynamic reconfiguration mechanism is controlled by a set of business policies, and these policies specify appropriate actions to take under various situations.
These policies can be pre-specified before system operations, but also they can be updated during runtime in real-time by the COI (community of interest) within the system.
The distributed situation-aware COI monitoring agent detects the changes in the operation environment, it informs the concerned COIs and then these COIs may update their polices to adjust to the changing environment.
Cyclic Flow of Dynamic Reconfiguration Process (cont’)
Once the business policies are changed, the dynamic reconfiguration is changed as it is ruled by the policies, even though the overall reconfiguration mechanism remains the same.
In this way, commanders and decision makers make high-level decisions, based on the latest situation assessment, and let the SOA to actually implementation the transition plan.
Multiple monitoring agents, COIs, and DRS can participate in this process, and this process is done in a distributed but collaborative manner.
Why do we use ontology?
To describe the semantics of the data (which we name as Meta-Data)
Why do we describe the semantics?
In order to provide a uniform way to make different parties to understand each other
Any data (on the web, or in the existing legacy databases)
Why Do We Need Ontology in SOA?
First reason is that ontology can be used to represent the relationship and dependencies between services as well as service interactions. It is also useful to perform dynamic service matching.
Another reason is that, the use of ontology can greatly enhance the service reusability in SOA. A typical example is FERA , a collaboration framework proposed by Intel, which enables enterprises to expose their business processes across a federation of enterprises through SOA and therefore enhance the service reusability. One of the weapon to achieve this goal is via ontology. In FERA, the context of collaboration needs to be defined using open standard semantics, while the ontology of contents needs to be consistent across all shared meta-data definitions. This enables the processes to be configured as they fit the business needs and reconfigured when the needs change.
Problems on Testing SOA
Even small changes can cause major disruptions in today’s highly interactive and independent applications.
Unfortunately, the pace of changes means traditional testing architectures with lengthy development and testing will not work.
But the testing must be done.
Several SOA testing frameworks have been proposed. Worksoft’s Certify  will be discussed as the test management repository and framework solution to this testing problem for XML-based applications.
A Typical SOA-architected Service Solution
The following figure shows a typical SOA-architected service solution for an insurance company.
Indirect testing and standardization have traditionally provided ways to work around at least some of difficulties associated with these problems.
But both traditional solutions doesn’t work well on SOA testing.
Problem of Indirect Testing
Can these services be tested indirectly? Won’t exercising the provider and consumer applications – those that enable or use the services allow us to uncover problem? The problem is one of timing and data. Such indirect testing can’t be done until late in the development cycle when the cost of correction is very high. Nor does indirect testing provide an effective way to find the source of a problem. These is no enough data about an incorrect transaction or failed result to identify with of at least five places caused the problem: the provider application, the encoding, the transport, the message content or the consumer application.
Another frustration to indirect testing is found in the ‘boundless’ nature and fundamental promise and power of SOA. A significant part of the attractiveness of SOA comes from the unpredictability of its utilization. SOA applications can be utilized by any application including those not yet developed and accessed by consumers outside the enterprise. It has boundless potential for use. Can’t standards provide us a way out of this dilemma? The answer is not completely.
Standards Don’t Always Help
While this standard makes applications integration much more flexible than previously hard-wired connections, it makes testing more complex. A traditional monolithic application has a user interface to allow verification of business functionality, but the layers of an SOA do not offer such an interface – yet they must be tested individually as they are developed and together as they are integrated.
The only way to test the business functionality of XML messages is through a test interface that allows messages to be created, sent, received and verified either simulated or live. Without it, there is no means of verifying functionality at each integration point.
Until now, each development group has had to write customized code to provide a test interface to the messaging layer. This adds time and cost to the overall project as well as ongoing maintenance into the future. Further, testing the integration of all layers requires an interface that allows business processes be executed end to end, across applications, platforms and perhaps enterprises.
Is there no way out of this testing trap? Let’s examine one approach from Worksoft.
Introducing Worksoft’s Certify
Worksoft introduced Certify™ to bring the power of a proven test automation repository and framework to the testing of XML messages. Certify provides a straightforward interface for developers, testers, business analysts and expert users to define the format and content of the messages they want to send and receive, whether across a transport protocol or between files. Layers can be tested either standalone or together. Certify can be used to configure the enterprise environment, define the messages, and start exercising business process functionality at every level and interface.
A central repository for all test assets
Business process automation and verification across both the UI and services
Exercise messaging either emulated or live
Test object management and maintenance
Traceability from business processes to messages to applications
End-to-end execution across platforms, applications and layers
Detailed result logs, management reports and analysis
Certify’s approach has the potential to deliver dramatic productivity gains in automating and maintaining XML test cases. User of Certify means that custom code does not need to be developed. All test cases are developed in a repository using a standard, structured format. Test coverage can be quickly extended using data variations.
Certify’s operational process
The first step is for the systems architect to configure the transport that will be used to send and receive XMl messages. While XMl is a standard, the implementation of the messaging layer is not. There are a number of transports and protocols, including both public and private APIs.
Next, the architect constructs a set of shared Certify processes that handle the sending and receiving of messages so that analysts can simply call them. This removes the need for analysts to understand the system infrastructure or transport protocol.
The next step is to import the schema or messages into the Certify application map, then rationalize the object names so they are useful and meaningful for test or business analysts. The message itself is presented to the user as a window, and each element within the message becomes an object.
Business Meaningful Element Names in All Messages
Perform Edit/Execute Command
The message map provides users with a point and click editor for defining message data content to be sent or verified. As shown in Figure 4, the analyst selects the message, then the element within the message, then the action to be performed, such as to set or verify the value. Once the message contents are defined, the message can be generated and sent or received and verified.