Shahid Bahonar University of Kerman An Introduction to Service Oriented Development with respect to Reusability
Shahid Bahonar University of Kerman
An Introduction to
Service Oriented Development
with respect to
Reusability
Shahid Bahonar University of Kerman
Prof. H. Sanat NamaProf. of Computer Science Dept. at Shahid
Bahonar University of Kerman
Supervised by:
Shahid Bahonar University of Kerman
Ali ShakibaLecture#1Hamid Bahrol OlumLecture#2ArabLecture#3GhainiLecture#4
Group 2Service-Oriented
Development
Table of Contents
Introduction to Service Oriented
Reusability and its relation with SOA
SOA Tools
SOA Case Studies 33
00
11
22
Green IT
کارآییاقتصادی
کارآییاجتماعی
کاراییاکولوژی
؛ استفاده بهینه و موثر Green ITهدف از منابع رایانه ای به منظور رسیدن به سه هدف فوق می باشد. یعنی در کنار
تالش برای رسیدن به کارآیی اقتصادی؛ همزمان کارآیی محیط زیست و اجتماع
نیز منظور شود.
Green IT
Shahid Bahonar University of Kerman
Introduction to Service-Oriented
Lecture # 1
Shahid Bahonar University of Kerman
presented by:
Ali Shakiba<a.shakiba.iran@gmail.
com>// I can guarantee no fast responses!
Table of Contents
Overview of Service Oriented Architecture
Service Oriented Computing
Web Services Technology for SOA
SOA Lifecycle 44
11
22
33
SOA Design Patterns 55
Shahid Bahonar University of Kerman
Overview of Service Oriented Architecture
Part I
Incremental approach to an SOA
Monolithic Applications In software
engineering, a monolithic application describes a single-tiered software application in which the user interface and data access code are combined into a single program from a single platform.
• From wikipedia.org
Incremental approach to an SOA
Intermediate stage: Individual services broken out
Incremental approach to an SOA
Service-oriented architecture
An Example: Bank Teller Analogy Different types of tellers offer different services
Tellers specialized to perform only certain types of transactions (which are typically closely related)
Example partitioning:• Account Management (Opening and closing accounts)• Credits (inquiry about conditions, consulting, applying for
mortgages)• Cash Register (Withdrawals, deposits, funds transfers)• Currency exchange (buy and sell foreign currencies)
There may be several tellers offering the same set of services (for load balancing / failover)
What happens behind the counter is not your business (bulletproof glass, iron bars)
If you require a complex transaction, you may have to visit several tellers (customer as transaction coordinator)
It’s all about service! What do you mean?
A service is a package of closely related standardized functions, which are called repeatedly in a similar fashion, and should therefore be implemented by a dedicated facility, which can be specialized to perform them. Example: Account Management
A service can be partitioned and have multiple service functions. Example: Open new account
The smallest subunits within service functions are called service primitives (also sometimes called the service). Example: Generate next available account number
Characteristics To Describe A Service
Service requester (“client”) Who/which components use or need the service? For the service requester, the provided service is most
important, and not how it is implemented (principle of information and implementation hiding)
Service provider (“server”) Who/which components implement or provide the
service? is responsible for hosting the service, and ensuring the
promised QoS may charge for service usage
Qualities of Service (QoS) What are the parameters that allow to distinguish good
service provisioning from bad? Examples: Reliable, predictable execution, cost,
execution time, level of privacy, other guarantees
Service, a picture rather a million words!
Request Response
How Services relate
How services communicate
Logic encapsulation by service
Example
Interface (Def.) An interface constitutes the specification of a service,
that is implemented by a certain component. The interface defines a contract, to which the component that implements it has to comply.
Interfaces can be described using formal languages Web Services Description Language (WSDL) OMG/ISO Interface Definition Language (IDL) (for
CORBA) UML Object Constraint Language (OCL) But also: Java, C++ headers, . . .
Type-safe interfaces sometimes introduce tight coupling Web Services don’t force you into type-safe interfaces Different message types may be acceptable to a service
So you said WSDL! What is it?
A WSDL document describes a web service using these major elements
<portType>• The operations performed by the web
service <message>
• The messages used by the web service <types>
• The data types used by the web service <binding>
• The communication protocols used by the web service
The main structure of a WSDL Document
<definitions><types>
…</types><message>
…</message><portType>
…</portType><binding>
…</binding>
</definitions>
Hey WSDL! Give me synonyms in my world!
<portType> is the most important thing! Syn. To a function library, a class or a
module<message>
Syn. To parameters of a function<types>
Defines data types that web service uses!<binding>
Desc. The protocol details and message format for each port!
OK! I know it’s hard!A simplified part of WSDL code!
<message name="getTermRequest"><part name="term" type="xs:string"/>
</message><message name="getTermResponse">
<part name="value" type="xs:string"/> </message><portType name="glossaryTerms">
<operation name="getTerm"><input message="getTermRequest"/><output
message="getTermResponse"/></operation>
</portType> Source: W3Schools.org
Software Architecture (Def.)
Software architecture encompasses the set of significant decisions about the organization of a software system selection of the structural elements from which
the system is composed, and the interfaces to these
behavior as specified in collaborations among those elements
(de/-)composition of these structural and behavioral elements into a larger system
architectural style that guides this organization• Def. from Mary Shaw at Carnegie Mellon Univ.
Architectural Style (Def.)
An architectural style defines a family of systems in terms of a pattern of structural organization [Garland/Shaw 96]
An architectural style defines: a vocabulary of design elements
• components (client, server, filter, layer, adapter…), and connector types (pipe, broadcast, queue,...)
a set of configuration rules (constraints) on how they can be combined
Example styles in Software Architecture: Event-based, Repository-based, virtual machines, layered.
Service-Oriented Architecture (SOA)
The architectural style is service-oriented if: It is not monolithic; common blocks of functionality are
broken out of the applications and are instead provided by services
• A significant part of the overall functionality is implemented by services, which exist otherwise independent of the application
Design elements for an SOA are:• Components: services (can be composites), consumers,
providers• Connector type: (remote) service invocations
Configuration rules for an SOA are:• No strict layering (service implementations can use other
services) • No centralized control entity• Services are designed for shared use, and for use that may
not even have been anticipated at design time
Service Orientation (Def.)
Service-Orientation is an organizational principle. A set of principles for building large systems
which is not tied to any particular technology. Examples:
• Common “horizontal” services:– Logging, authentication/single-sign-on, systems
management, Directory lookup of services, event notification
• “Vertical” services, specific to your business domain– Product feature search service, Address management,
Order Status Tracking Service, Truck/trailer tracking service
As in organizations, there is always more than one way to structure a large system
Quality criteria for (software) architecture
Criteria to evaluate a decomposition:1. Derived from top rank use cases (adequateness)2. Balanced with existing assets: platform
technology, frameworks, components3. Balanced with requirements (trade-offs,
performance vs. security,…)4. Compliance with (domain-specific) industry
standards and reference models (interoperability, readiness for merging)
5. Designed to make the system more resilient to future changes (20 years?) (maintainability)
6. Designed for substantial reuse, and with substantial reuse
7. Intuitively understandable (people buy-in!) (usability)
Forces and quality factors for software arch.
A Real-world SOA Project! ( A Dream )Large-scale distributed systems, such as
healthcare systems, are difficult to develop due to their complex and decentralized nature. The Service Oriented Architecture facilitates the development of such systems by supporting modular design, application integration and interoperation, and collaboration between independent software systems. Using open standards, such as XML, SOAP, WSDL and UDDI, the Service Oriented Architecture supports interoperability between services operating on different platforms, and between applications implemented in different programming languages. We designed and implemented distributed e-healthcare system that uses the Service Oriented Architecture as a basis for designing, implementing, deploying, invoking and managing healthcare services. The e-healthcare system that we have developed provides support for physicians, nurses, pharmacists and other healthcare professionals, as well as for patients and medical devices used for monitoring patients. Multi-media input and output, with text, images, speech and keyboard, make the system more user friendly than existing healthcare systems.
www.uweb.ucsb.edu/~fkart/research.htm
Challenges and problems Technology heterogeneity of existing applications Many integration projects during the last three years
Have been tactical, not strategic (no enterprise focus) Only solved problems for one project (e.g. for one
channel) Result: Stovepipe integrations
Large organizations run 100s of apps and multiple ERPs These systems were designed independently of each
other They overlap in functionality
• They overlap in the data they manage Integration does not remove any overlap
• Consolidation would be better SOA helps to address these issues
Benefits of SOA Design More flexibility (“business agility”)
Assumption: business process logic and business rules are no longer buried inside applications
Result:• Since they are now explicit, processes can be changed
easier• Existing services can be used in different contexts• Shorter time-to market for changed processes
Reduced cost of operation through consolidation Assumption: Redundant functionality is eliminated Result:
• Fewer servers• Fewer licenses• Fewer assets to manage• Lower maintenance cost
Benefits of SOA Design (contd.)
Higher quality Eliminating redundancy reduces inconsistent data and
behavior More transparency Improved system architecture – easier to understand
Reduced risk, cost and complexity for development Clean architecture reduced cost and risk Increased developer productivity through reuse Projects can leverage existing services “Black box” reuse instead of copy&paste reuse
Lessen the dependencies on vendors Service implementations can be replaced if interfaces stay
the same Services can be relocated from one platform to another Services can even be outsourced to an external provider
Benefits of SOA Design (contd.)
Good service design (partitioning) will outlive your middleware or implementation technology All you have to do is to put a wrapper around it, if required Many mainframe systems today provide many useful
services that should be made available to applications elsewhere in the enterprise
Commoditizing more and more parts of the IT infrastructure Off-the-shelf infrastructure components are moving up the
layers and coming closer to the application! Due to existing industry standards and available products,
developers stop building this stuff themselves:• 1990: DBMS, TP Monitors• 1992: Networking stacks• 1995: CORBA, RPC Middleware, Reliable Messaging• 1998: Naming Service, Publish and Subscribe, Event Notification• 2000: Various J2EE Services
SummaryPrecise terminology helps
to understand and handle the problem to identify and debunk unbaked concepts
Service-orientation is an architectural styleSOA benefits us by
Reduced risk, cost and complexity for development
Reduced cost of operation through consolidation
business agility
Summary (Contd.)A Service is formally characterized by
Client Server QoS
It’s an incremental approach to reach SOA.
Shahid Bahonar University of Kerman
Part II
Service Oriented Computing
SOC DefinitionSOC is an emerging cross-disciplinary
paradigm for distributed computing that is changing the way software applications are designed, architected, delivered and consumed
SOC is a new computing paradigm that utilizes services as the basic constructs to support the development of rapid, low-cost and easy composition of distributed applications even in heterogeneous environments
SOC vs. Object OrientedThe major innovation of SOC is the move
from OO paradigm into a SO one! Object Oriented
• Stateful Service Oriented
• Stateless
A Deeper Comparison!Methodology
OO• Application development by identifying
tightly coupled classes. • Application architecture is hierarchical based
on the inheritance relationships. SO
• Application development by identifying loosely coupled services and composing them into executable applications.
A Deeper Comparison! (contd.)
Level of abstraction and cooperation OO
• Application development is often delegated to a single team responsible for the entire life cycle of the application.
• Developers must have knowledge of application domain and programming.
A Deeper Comparison! (contd.)
Level of abstraction and cooperation SO
• Development is delegated to three independent parties
– application builder– service provider – service broker.
• Application builders need to understand application logic and may not know how individual services are implemented.
• Service providers can program but do not have to understand the applications that use their services.
A Deeper Comparison! (contd.)
Code sharing and reuse OO
• Code reuse through inheritance of class members and through library functions.
– Library functions have to be imported at compilation time and are platform dependent.
SO• Code reuse at the service level. • Services have standard interfaces and are published
on Internet repository. – They are platform-independent and can be searched and
remotely accessed. • Service brokerage enables systematic sharing of
services.
A Deeper Comparison! (contd.)
Dynamic binding and re-composition OO
• Associating a name to a method at runtime. – The method must have been linked to the
executable code before the application is deployed. SO
• Binding a service request to a service at runtime.
• The services can be discovered after the application has been deployed.
– This feature allows an application to be recomposed at runtime.
A Deeper Comparison! (contd.)
System maintenance OO
• Users need to upgrade their software regularly.
– The application has to be stopped to perform the upgrading.
SO• The service code resides on service
providers' computers. • Services can be updated without users‘
involvement.
Who is using SOC?All major computer corporations, including
IBM, HP, Oracle, Intel, Cisco, Sun and Microsoft have moved toward SOC.
SOC is being adopted by major computer uses including Banks
• Web Banking Services Retailers
• Web Shopping Services Airlines
• Web Booking Services
SOC ElementsService Oriented ArchitectureService OrientationService Oriented Solution LogicServicesService CompositionsService Inventory
Service CompositionServices can be composed of other servicesServices can be composed by using other
services in a business logic
Service InventoryA service inventory is an independently
standardized and governed collection of complementary services within a boundary that represents an enterprise or a meaningful segment of an enterprise
Service orient . {ation + ed solution logic}
Service orientation: Is a design paradigm comprised of a
specific set of design principles Specifies the creation of automation logic
in the form of servicesService oriented solution logic:
The application of these design principles to the design of solution logic results in service oriented solution logic
Model
SummaryService Oriented Computing is a new
approach for software development; just like Object Oriented.
Shahid Bahonar University of Kerman
Part III
Web Services Technology for SOA
Basic Web Tech required for WS
XML eXtensible Markup Language Documents are based on XML XML docs are described by XML Scheme
SOAP A simple way to send docs A way to format XML docs for transmission
WSDL Defines Implementation details about a service
UDDI Universal Description, Discovery and Integration Store, advertise and discover services!
What’s a Web Service?Web services are application components Web services communicate using open
protocols Web services are self-contained and self-
describing Web services can be discovered using UDDI Web services can be used by other
applications XML is the basis for Web services
How does it work?Basic WS platform is XML + HTTPOther Elements
SOAP UDDI WSDL
The future of WSWS platform is
Simple Interoperable Messaging
… framework but it lacks Security Routing
… but they’ll be provided as SOAP advances!
Why Interoperability is so important?
All different major platforms can access Web using Web browsers; different platforms can interact! An Idea! Developing Web Applications to
make these platforms work together.Web Applications are simple applications
run on the web. Built around web browser standards so
they can be used by any browser on any platform.
WS is an advanced Web Application
Using WS; the web application Publish its
• Function• Message
… to the rest of the world!WS uses
XML• To code/decode data
SOAP• To transport it through open protocols
Two types of uses for Web Services
Reusable Application Component Offering Application Components
• Like– Currency conversion– Weather report– Language translation– …
Connect Existing Software Make it possible to exchange data
between different applications and platforms.
What is SOAP?SOAP stands for Simple Object Access Protocol SOAP is a communication protocol SOAP is for communication between
applications SOAP is a format for sending messages SOAP is designed to communicate via Internet SOAP is platform independent SOAP is language independent SOAP is based on XML SOAP is simple and extensible SOAP allows you to get around firewalls
WSDL (Reminder)WSDL stands for Web Services Description
Language WSDL is written in XML WSDL is an XML document WSDL is used to describe Web services WSDL is also used to locate Web services
What’s UDDI?UDDI stands for Universal Description,
Discovery and Integration UDDI is a directory for storing information
about web services UDDI is a directory of web service
interfaces described by WSDL UDDI communicates via SOAP
SummaryWS is a way for converting applications into
Web Applications.WS uses XML to send messages between
applications.WS = exporting a function from an
application.WSDL is an XML based language for
describing services.SOAP is an XML based protocol for
exchanging data through HTTP.
Shahid Bahonar University of Kerman
Part IV
SOA Lifecycle
SOA LifecycleLogical steps to implement an SOA system.
1. Model2. Assemble3. Deploy4. Manage
Model PhaseModeling the current business processesOptimizing Business processes for agility
and more performanceModeling the result of optimization for
target business processesSimulating the models and evaluating
possible outcomes Helps in agility of the enterprise
Assemble PhaseIt’s splited into 3 sub-phases
Service Design Service Building Service Integration
In this phase, in fact, Services are implemented; then they are assembled Means discovered
… and composed to implement the bussiness processes that are tested for requirements. Functional or Non-functional
Deploy PhaseThe assembled business processes are
deployed on the operating run-time environment.
What’s a run-time?After Assemble phase; the BPs are ready to
be deployed into a run-time. It should support the execution of
Dynamic BPs It should provide open-standards based
execution environment to allow services to readily invoke other services.
Execution Environment3 basic must support features:
Protocol translation between various service invocations
Routing between appropriate service providers
Mediation to provide features like security, auditing, logging, and so on
Manage PhaseThe services and the business processes
that are executing on the run time are monitored and analyzed to ensure their smooth operations.
IT metrics like security, performance, and availability are also measured.
The services and business processes are further monitored to ensure compatibility with the business metrics and service-level agreements (SLA) that are supposed to be met.
Manage PhaseIt can be broken out into 4 sub-categories
Manage Business Processes Manage Service Layer Manage Transaction performance Manage Service Security
Shahid Bahonar University of Kerman
Part V
Design Patterns for SOA
SOA Scenarios IBM has found 8 common design patterns for SOA
It names them as SOA Scenarios They can be classified into 5 classes according to their
entry points People
• Enabling human and process interaction Process
• Enabling and achieving greater efficiency and effectiveness through business model innovation
Information• Delivering trusted information to enable business processes
Connectivity• Achieving an on-demand flexibility by connecting software
systems and services
SOA Scenarios (contd.) Reuse
• Minimizing complexity of SOA adoption and implementation by fostering reuse of high-value enterprise assets
Each scenario is further broken down into realizations They are specific development tasks
design to solve a particular problemScenarios can be categorized into 2 parts
Functional Supporting
SOA Scenarios (contd.)The functional scenarios map directly to
one or more SOA entry points.The supporting scenarios cut across all the
entry points.
Functional ScenariosService CreationService ConnectivityInteraction and Collaboration ServicesBusiness Process ManagementInformation as a Service
Supporting ScenariosSOA DesignSOA GovernanceSOA Security and Management
Service CreationCreating flexible, service-based business
applications. A new service-oriented application exposes
business behavior as a service and also reuses business logic, which is exposed as a service.
The scenario also provides guidelines on how to provision the services as soon as they are created.
The identification and realization of services are the first steps in implementing the vision of a set of optimized business processes
Service Creation (contd.)Services can be identified essentially from
three main sources Existing assets
• Services that are identified from high-value business functions already deployed in existing systems
– for example, legacy or packaged applications External service provider
• Services that are provided by an external vendor, most likely a vendor who provides services in a specific area
Service Creation (contd.) New services identified using a "top-
down" approach• Services that are identified through a top-
down decomposition technique– process decomposition
» These services fill the gaps that are not addressed by the first two sources; they are new services that need to be implemented from scratch
Service ConnectivityBuilds on the Service Creation scenario
According to which services have been identified, designed, and built, and focuses on the underlying connectivity used to support a business-centric SOA.
This scenario enables users to have the flexibility of independently changing the service consumer or the service consumer in a manner that is nondisruptive to either.
Service Connectivity (contd.) The scenario helps in identifying the characteristics
Such as routing, transformation, mediation of an Enterprise Service Bus (ESB) that may be used to provide decoupled connectivity between service providers and consumers.
The scenario also provides guidance on how to create a logical as well as physical realization of a service gateway pattern That provides mediation capabilities to enable
transparent interoperations across mismatched and evolving systems, both at the protocol and interface level.
The service gateway pattern also provides guidance on how to enforce security on service invocations.
Interaction and Collaboration Services
Presents a service or set of services to a human user through a browser, PC, mobile device, voice response system, etc.
It focuses on usability issues such as offering single sign-on to multiple systems
and providing role-based portals to consolidate access to information and applications within the enterprise and between enterprises.
The key drivers for this scenario are improving productivity of the people who use the system and consumability of the applications and content that make up the system. The content can be personalized in the aggregated
portal page based on the user role.
Business Process Management
Assists in the optimization and automation of business processes and aligns an organization's core assets people, process, information, and technology
… in order to create a single integrated view, real-time intelligence, and appropriate business and IT metrics that enable operational efficiency.
This scenario concentrates mainly on process modeling and simulation, process integration, process monitoring (also called business activity monitoring, or BAM), process-oriented content aggregation, business rules management, and effective collaboration between people, process, and technology.
Enterprises that are process-centric can gain from using this scenario in their SOA transformation.
Information as a Service Makes information usable in an SOA by expanding the
business value of data. This scenario is especially applicable when an
enterprise: Has too much information but is not sure of its
business relevance Stores multiple versions of information, making it
difficult to determine which information source to use Does not rigorously enforce data quality in its
store(s) of information Maintains disconnected silos of information that may
duplicate each other or contain different sets of data that cannot be reconciled
Information as a Service (contd.)
The crux of this scenario is the virtualization and centralization of information to create a set of consistent, reliable data. That virtual single version of data can
then be made available as a service to the entire SOA system, which can use it in a standardized way for business process enablement.
SOA DesignA cross-cutting scenario that focuses on
methodologies for modeling, design, and architecture of an SOA-based software development.
This scenario aligns the modeling of business design and IT solution design through a set of roles, methods, and artifacts. Once this is accomplished, business
processes can be optimized and realized as services so that the services are aligned with the business and offer true business value.
SOA GovernanceA cross-cutting scenario focusing on a
decision-making and enforcement process to oversee SOA planning and execution.
It is based on a decision rights and management framework that includes the establishment of chains of authority, roles, controls, and so forth, for the four phases of the SOA life cycle.
This scenario also focuses on defining high-value business services and measuring their effectiveness at run time.
SOA Security and Management
A cross-cutting scenario focusing on management of services at run time and ensuring secure external consumer access to high-value business services.
The management of services focuses on automating and simplifying IT processes, managing service levels of services and applications, and predicting and managing change across interdependent and composite services.
SOA Security and Management (contd.)
Service security focuses on managing the federated identity and access control across services, securing access to services and applications, and consistently enforcing security policies for services.
SOA scenarios and their relationships
IBM recommends a process for SOA Scenario usage
SummaryThe SOA scenarios represent a set of
generic business scenarios in which SOA is being used in typical customer engagements.
The SOA scenarios are representative of common scenarios of use of IBM products and solutions that are used in SOA engagements to solve real-world problems.
Shahid Bahonar University of Kerman
Reusability and its relation with SOA
Lecture # 2
Shahid Bahonar University of Kerman
presented by:
Hamid Bahrol Olum
Table of Contents
************
************
*****************
************** 33
00
11
22
Shahid Bahonar University of Kerman
SOA Tools
Lecture # 3
Shahid Bahonar University of Kerman
presented by:
Arab
Table of Contents
************
************
*****************
************** 33
00
11
22
Shahid Bahonar University of Kerman
SOA Case Studies
Lecture # 4
Shahid Bahonar University of Kerman
presented by:
Ghaini
Table of Contents
************
************
*****************
************** 33
00
11
22
Shahid Bahonar University of Kerman
Part VI
References
Refrence1. SOA: Principles of Service Design; Thomas Erl;
Prentice-Hall2. Introduction to Service oriented computing;
W.T.Tsai, Yinong Chen3. Service oriented computing: Key concepts and
principles; Michael N. Huhns, Munindar P.Singh
4. Introduction to Web Services (WS) & Service-Oriented Architecture (SOA); Eric Newcomer; Presented at SOA, MDA, and Web Services Workshop: Integrating the Enterprise, and Beyond, 2006 by OMG
Reference (contd.)
5. Architecture in practice; 7 parts; by Tilak Mitra; at IBM developerWorks.
6. W3School at www.w3school.org
Shahid Bahonar University of Kerman
Thanks & Ready for
Questions and NO ANSWERS!