Service-Oriented Computing and Service-Oriented Architecture
Week 3 Lecture 5 M. Ali Babar
Lecture Outline
• Service-Oriented Computing (SOC)
• Service-Oriented Architecture (SOA)
• Designing service-based systems and quality attributes
• Some of the implementation technologies
Service-Oriented Computing
• Development of rapid, low cost, & interoperable systems that are independent of programming languages and operating systems
• Help create compound solutions using legacy systems and enterprise information systems exposed as loosely coupled services residing on remote networks
• Organization can programmatically offer their business processes over the Internet or on various networks
What is a Service?
A service is an implementation of a well-defined piece of business functionality, with a published interface that is discoverable and can be used by service consumers when building different applications and business processes.
Acquiring and Consuming Web Services
• Look for suitable services in a directory, e.g., UDDI
• Analyze the specifications of the potentially relevant services by reading something like WSDL
• Select the most relevant service and get it do something of value to the service consumer using something like SOAP
• Exploit the standards (e.g., WS-* standards) for ensuring quality attributes security and reliability.
Principles of Identifying Services
• A Service should:
– Represent a tangible business concept
– Consist of a series of organization-wide analysis, where a process can decompose into several small set of processes
– Reusable processes - within or outside an organization, identify possible inputs and outputs (should be generic) for these
business processes
– Identify dependencies among services and their impact on internal or external to a system
Source: Gupta, S., Service Orietned Architecture, http://javaboutique.internet.com/tutorials/
serv_orient/ , last accessed, 7 November, 2010.
A Use Case Model for Identifying Services
Taken from assignment submission by Jensen, Tindbæk, 2010.
An Example Set of Services
Taken from assignment submission by Jensen, Tindbæk, 2010.
Service-Oriented Architecture (SOA)
“A service-oriented architecture (SOA) is an application framework that takes everyday business applications and breaks them down into individual business functions and processes, called services. An SOA lets you build, deploy, and
integrate these services independent of applications and the computing platforms on which they run.” – IBM
“Service-Oriented Architecture is an approach to organizing information technology in which data, logic, and infrastructure resources are accessed by routing
messages between network interfaces.” – Microsoft
An SOA is “a set of components which can be invoked, and whose interface descriptions can be published and discovered.” – W3C.
“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.” – The OASIS Group
Some of the Servies in an SOA
User
Arch
Authenticator Patterns
Repository Calender Provider
<<ServiceContract>>
IProject, IArtifact, ITask, IUserLogIn
<<ServiceContract>>
IAuthenticator <<ServiceContract>>
IPatternRepository
<<ServiceContract>>
ICalendar, IUserNotification
ServiceArchitecture
Taken from assignment submission by Tell, Birkebæk, Olsen, Wamsler, 2010.
Architecture of a Web Retail System
Taken from assignment submission by Jensen, Tindbæk, 2010.
Motivators of SOA
• Increasing nature of distributed systems
• Heterogeneity of systems and computing environments
• Dynamics of operating environments
• Transparency of communication infrastructure details
• Process-orientation requires multiple services
Service Provision and Consumption
http://enterprisearchitecture.nih.gov/NR/rdonlyres/79383B38-4E84-4BCA-A8F2-EEB1F7FEC875/0/SOAPattern2006.jpg
Some Important Questions
• Interfaces and contracts
• Communication styles available, content and semantics
• Service lookup and registration
• State information and activation issues
• Processes and their implementation – coordination and orchestration
What to Do about It?
Common Design Principles
Design Principles 1/3
• Services are reusable
– Business functionalities exposed as services are designed with the intention of reuse whenever and where they are required
• Services share a formal contract
– Services interact with each other through a formal contract which is shared to exchange information and terms of usage
• Services are loosely coupled
– Services are designed as loosely coupled entities able to interact while maintaining their state of loose coupling.
• Services abstract underlying logic
– The business logic underpinning a service is kept hidden from the outside world. Only the service description and formal
contract are visible for the potential consumers of a service
Design Principles 2/3
• Services are composable
– Services may be composed of other services. Hence, a service’s logic should be represented at different levels of granularity and promotes reusability and the creation of abstraction layers.
• Services are autonomous
– A service should be independent of any other service
• Services are stateless
– A service shouldn’t be required to maintain state information rather it should be designed to maximize statelessness
• Services are discoverable
– A service should be discoverable through its description, which can be understood by humans and service users. A service can be discovered by the use of a directory provider, or,
implementation mechanism or hard-coded address
Design Principles 3/3
• Services have a network-addressable interface
– A service should be invoked from the same computer or remotely – through a local interface or Internet
• Services are location transparent
– A service should be discoverable without the knowledge of its real location. A requestor can dynamically discover the location of a service looking up a registry
The core principles are autonomy, loose coupling, abstraction, formal contract
What to Do about It?
Impact of SOA on Quality Attributes
Source: O’Brien, L., Bass, L., Merson, P., Quality Attributes and Service-Oriented Architectures, Technical Report No. CMU/SEI-2005-TN-014.
Impact of SOA on Quality Attributes 1/3
• Interoperability
– Standard based services provide good interoperability. But semantic inoperability remains an issue as standards are still immature (G)
• Reliability
– Use of standards (WS-Reliability and WS-ReliableMessaging) means reliable message. Service reliability is still a problem (Y)
• Availability
– Service users can negotiate SLA – built-in contingency for discovering another service if the desired service is not available (Y)
• Usability
– Service user and provider need to build support for usability into their systems (Y)
Impact of SOA on Quality Attributes 2/3
• Security
– Need for encryption, authentication, and trust within SOA requires detailed attention – many immature standards (R)
• Performance
– SOA can negatively affect performance because of network delays, overhead of looking up services, processing XML, intermediaries (R)
• Scalability
– Many ways of dealing with increased users and need for more services but it may negatively affect other QA - performance (Y)
Impact of SOA on Quality Attributes 3/3
• Extensibility
– SOA supports extensibility by adding new services,
incorporating additional capabilities. Its easily as long as
interface/formal contract doesn’t need to be changed or can be easily extended (G)
Implementation Technologies
• XML Web Services
• Common Object Request Broker Architecture (CORBA)
• Java Remote Method Invocation (RMI)
• .Net Remoting
• Message Orietned Middleware (MOM) – IMB’s
MQSeries, Microsoft Message Queuing (MSMQ), or Java Message Service
• TCP/IP
Implementation Technologies
• XML Web Services
• Common Object Request Broker Architecture (CORBA)
• Java Remote Method Invocation (RMI)
• .Net Remoting
• Message Orietned Middleware (MOM) – IMB’s
MQSeries, Microsoft Message Queuing (MSMQ), or Java Message Service
• TCP/IP
Examples of REST and SOAP
• REST
@GET
@Path("{location}/{id}/{pwd}/{tenantid}") @Produces("application/xml")
public String getUserProjects(@PathParam("location") String location,
@PathParam("id") String id, @PathParam("pwd") String pwd, @PathParam("tenantid") String tenantId) {
// some code }
• SOAP
@WebMethod(operationName = "generateDiagramImage")
public Image generateDiagramImage(@WebParam(name = "diagramDescription") String diagramDescription,
@WebParam(name = "destination") String destination) { // some code
}
Protocol Stack for SOA
Reproduced from course text book: Cloud Computing Bible by Sosinkey, B., 2011.
Service Orchestration or Choreography
Reproduced from course text book: Cloud Computing Bible by Sosinkey, B., 2011.
Cloud Computing Reference Architecture
Taken from NIST Cloud Computing Reference Architecture by Liu, F., et al., 2011.
Someo f the Services for Cloud Consumers
Taken from NIST Cloud Computing Reference Architecture by Liu, F., et al., 2011.
References
• Chapter 13 of the book by Sosinsky, B., 2011.
• Papazoglou, M., Traverso, P., Dustdar, S., Leymann, F., 2007, Service-Oriented Computing: State of the Art and Research Challenges, IEEE Computer, 40(11), pp.
38-45.
• O’Brien, L., Bass, L., Merson, P., Quality Attributes and Service-Oriented Architectures, Technical Report No.
CMU/SEI-2005-TN-014.
