(2) Abstract

The organizing systems designed and operated by enterprises to perform systematic business activities and implement business models face challenging requirements for application integration, process management, reliability, security other ilities and ities that (some people think) are not easily met with plain web and REST architectures.

(3) The Web Service Idea of 2001

(4) The Vision: Dynamic Service Discovery and Composition

• Many business processes have become global and involve widely dispersed parts of an enterprise or multiple enterprises
• An agile, adaptive, on demand [insert other buzzwords here] enterprise needs to be able to quickly and cost-effectively change how it does business and who it does business with (suppliers, business partners, customers)
• So ideally, the component services that come together in composite applications can be dynamically discovered and combined from different firms

(5) Requirements for Dynamic Composition

• Do I know what service I'm looking for?
  • (do I understand my to-be business model at an appropriate component granularity)
• Do I know where to look? Can I find the service I'm looking for?
  • (is there a directory/registry or set of them I can search)(what's the web services specification that describes how this is supposed to work? (Universal Description, Discovery, and Integration)(white, yellow, green pages — announced with great fanfare in 2001, appears in all the web services books, no one uses it except internally)
• Is the service compatible from a business perspective?
  • level of abstraction of processes, terms and conditions, does it fit the choreography that my composite application requires?
  • (all the usual problems about how something is described — different words for same thing, same for different things, ontology
• Is the service technically compatible? (technical interface compatibility)
• can I transform the service inputs or outputs to achieve compatibility?
• Does the service meet my quality and performance requirements?
  • Could be dependencies between services, timing requirements — if credit check takes too long, seller may not want to hold goods…
  • So how do the answers to these questions for internal composite applications compare to those for external composite applications

(6) Web Services and Composite Applications

• A common use of web services is to create a single interactive user experience by combining multiple business functions or information sources
• The composite application reuses the computation or processing done by these existing applications / sources by exposing or wrapping some existing functionality with an interface that conforms to WS-* specifications
• This interface is usually a coarse, document-sized transactional message represented in XML rather than a fine-grained API to ensure loose coupling and enable many different uses of the same interface
• The constituent services/sources are not changed, and they can still function independently in their original contexts
  • AND TO REMIND YOU FROM LAST WED LECTURE ON ERPR one solution to this problem was to replace separate applications with a single enterprise-wide application that contained all the functionality needed by the company (ERP systems) – but these haven't been as successful in practice as in theory; ERP was simply too heavyweight a platform for doing this in an ad hoc or incremental way

(7) Why Build a Composite Application?

• The most common goal of a composite application is to bring together functions or services that have some common semantics and can satisfy some related goals for the service consumer
• The set of composed services aren't necessarily related in existing value chains or processes — if they were, they might already be combined in legacy applications
• The composite application is driven by document-based workflow between the different services — long-lived message-based conversations
• Example: a composite travel service that lets the consumer select a flight, hotel, and rental car satisfies a set of related goals for the traveler, but the most important relationships among the choices are temporal and geographical, not causal or process ones
• Example: buying a house
• Example: investigating and planning a residential solar energy project
  • Business strategy perspective — can provide improved and new services to customers by combining customer information, order management, product information, etc.
  • Business operation perspective — Reduce errors and time for information to flow from one stovepipe system or process to another by replacing manual methods of information sharing like re-typing or phone with automated interchange
  • Technology perspective — reuse of legacy applications extends their useful lives and can be technically easier than reimplementing their functionality in a new application
  • Business strategy perspective — can focus on core competencies by using services provided by other firms in plug and play business models

(8) Stovepipe Applications

• The business functions or information sources that are the reused components of composite applications are often stovepipe or legacy applications that solve a discrete set of problems without sharing information with each other
• Stovepipe applications naturally occur whernever functional units of a firm like engineering, manufacturing, sales, marketing, etc. are separated into different departments with limited interactions except when they hand off finished work to each other
• A similar situation occurs with the functions and applications performed by different government agencies or offices that don't normally cooperate or exchange information in an explicit or automated way
• Stovepipe systems accumulate over years or decades because they may have been developed using different technologies or purchased from different vendors OR acquired as the information systems of an acquired or merged company

(9) Principles of E-government Architecture

• In what ways are public sector IT concerns and priorities similar to those of large private sector firms?
  • E-government initiatives typically span multiple agencies, and at minimum are likely to involve several systems. — just as many integration projects in big firms try to combine different systems (ERP — central nervous systems of firms)
  • So INTEGRATION and INTEROPERABILITY issues will be important
• In what ways do public sector concerns and priorities differ from those of commerical enterprises?
  • Longer time horizons — planning in decades rather than quarters.
  • Equality of access — the need to reach all citizens. — can't just serve the profitable customers…
  • Respecting boundaries — between departments and public and private sectors.
  • Serving the public interest — including data protection and privacy issues

(10) Service-Oriented Architecture for E-Government in Ireland

• The McGrath and Murray paper describes the use of SOA and Web Services to implement e-Government services in Ireland
• Uses a hub architecture to make services more readily reusable / composable
• Abstractions of service, message, and hub make it easy to understand technology and business benefits and their interrelationships

(11) An Emphasis on the Data

• The only way to build an integration infrastructure to last is to base it on the one thing least likely to become obsolete — the data
• No matter what happens to technology, people will be born. They will be get birth certificates and passports and drivers licences. They will work and pay taxes and receive healthcare. They may get married and have children…

(12) The E-Government Hub or Public Service Broker

(13) The PSB Architecture

• The Service & Data Exchange Catalog is a registry that contains the models that define the structure and semantics of the messages exchanged to request and satisfy a service
• The PSB hub is hollow in functionality, doing little more than message routing and security functions — but it provides the platform into which other value-added services are plugged in
• Among the most important of these plugged-in services are the adaptors that transform message content and protocols to ensure interoperability and composability of services
  • this language should be familiar to you from the last lecture

(14) Services from the Customer's Perspective

• A customer facing service is split into three distinct components:
  • The user interface through which people interact with the service
  • The integration part (at the hub) that orchestrates the routing of messages to the (one or more) services that provide the information to the user interface
  • The fulfillment part — where the work gets done to create/compute/process information that gets put into a message

(15) A Network of Hubs

• Each organization or agency can use the same hub technology for internal service composition and integration
• These hubs can then be interconnected by multi-hub routing as long as there is a directory service that explains the addresses…

(16) Some Example Messages and Integrated Services

• Messages like:
  • This child has been born…
  • Please look up the following car registration…
  • Is the person with the following identifier entitled to a free telephone allowance…
  • This person has died…
• Instead of requiring a new mother to apply for benefits when her child is born, the new child message can be directly sent to the agency responsible for child benefits
  • This made 30,000 annual applications for benefits unnecessary

(17) Incremental Automation

(18) RESTful Web Services vs Big Web Services

• different ways of making applications work together
• how do you get information out of one and into another?

(19) The Big Web Service Stack

(20) The Fundamental Differences

• WS-* applications use the web as a transport medium for messages, and URIs are used to specify message destinations
  • Critical focus on the design of the XML vocabulary used to build the messages
  • Additional focus on the design of the process choreography that specifies the sequence or workflow of the message exchanges between the services in an external XML representation
  • Expectations that the message vocabulary and process specifications will change over time — versioning, etc.
• REST applications directly use web protocols and use URIs to point directly to the resources used by the applications
  • Critical focus on the resources and their identifiers
  • Workflow or choreography is built into the resources as links to other resources

(21) The Argument for REST

• RESTful web services are perceived to be simple because REST leverages existing well-known standards
• The effort required to build a clinet to a RESTful service is very small as developers can beging testing such services from an ordinary web browser
• Given the expressivity of the WS-* stack of standards, early implementation have been plagued by interoperability problems

(22) The Argument for WS-*

• Message-driven workflow is better suited for building composite applications that reuse functionality from heterogeneous, autonomous, and distributed applications
• Interoperability issues can be avoided by following profiles like those developed by the WS-I consortium and OASIS
• WS-* architectures are robust and can ensure message delivery even if the destination service is temporarily down or otherwise unavailable
• WS-* architectures can handle the partial automation scenario in which some services are provided by people rather than computational processes
• WS-* architectures can use SOAP header extensions to implement the *-ility requirements typical of complex distributed applications

(23) Two Weeks Left…

• Please send us an interim work product for your term paper by midnight Friday April 29 so we can assess your progress and provide advice. We will meet with anyone who requests this week and early next week…
• No new readings for next Tuesday May 3… We will have an end of semester review discussion to figure out what we've learned
• Your term papers are due 6pm on Monday May 9
• Present your work on Tuesday May 10… There are 9 papers — 9 talks of 9 minutes, including questions…