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 ServiceArchitecture User Calender Provider <<ServiceContract>> IProject, IArtifact, ITask, IUserLogIn <<ServiceContract>> ICalendar, IUserNotification Arch <<ServiceContract>> IAuthenticator <<ServiceContract>> IPatternRepository Authenticator Patterns Repository 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 Email
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 Email
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, // some code } @WebParam(name = "destination") String destination) {
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.