Service Framework Reference Models Bill Olivier Director, CETIS

Overview This presentation tries to provide some answers to the following questions: What is a Reference Model for? What do we mean by a Reference Model? What more is needed for a Service Oriented Reference Model? Can we agree a common format? – as a starting point for discussion…

What is a Reference Model for? There are many types of Reference Model and no two seem to be the same But they seem to have a common role: They provide a standardised way of a) Achieving a given goal, or b) Solving a given type of problem c) Using the means specified in the model d) … in order to provide a common approach Specs & Standards are arrived at through a political process and so serve a variety of ends –A Spec may be to much (or too little) for a set purpose, so a Reference Model may constrain or extend them

What do we mean by a Reference Model? In the realm of Specifications and Standards, a Reference Model: –Identifies a purpose to be served –Adopts one or more Specification(s) &/or Standard(s) –If several, shows how these can work together –Adapts (profiles) them, if necessary, to meet the needs of the given purpose and the demands of common real world constraints: Cost Current state of technology/systems Ease of use etc.

What do we mean by a Reference Model? A Reference Model thus bridges : –the World of Users and their Work –the underlying Technical Services and their associated Specs (The Wall) We therefore need to make clear: –The Human Context: Purposes, Processes & Practices –The Machine Context Applications & Services involved The Specifications that integrate them

In the Context of a Service Framework? In the context of a catalogue of Service Components (the Wall of Bricks), a Reference Model also: –Selects the Component Services –Orchestrates &/or Choreographs them (Orchestration: several services working together for a user) (Choreography: several users working together ) See: Eric Newcomer & Greg Lomow, Understanding SOA with Web Services, Addison Wesley, 2005 (integrates both and covers business processes, up-to-date) We therefore need to identify: –The human level tasks and workflows (which may be revised and redesigned in the process) Show how these relate to the Service infrastructure Identify the Service level Workflows

Reference Model Call Briefing 1) Domain Scope and Aim of Reference Model A clear definition of the domain-area of the reference model and the aims and scope of the Reference Model. 2) Use Cases and Business Processes for the Domain-Area This section defines the domain area by breaking it into use-cases and business processes. These will be comprised of UML use case diagrams and narrative descriptions of the elements/actors and processes involved in the domain area and the potential interactions between them. 3) Identification of the Services Relevant to the Domain-Area Using the existing ELF model determine a selection of services which could be used to fulfil the use-cases and business- processes (identified in 2 above). If necessary, additional or re-factored services may be required. Produce a service-profile for the domain area (a cut of the framework showing only the chosen services). 4) Factoring of Services Each service in the domains service-profile should be factored using the following hierarchy: Definition of functional scope Abstract model of data and behaviour Data representation specification (i.e. XML binding) Application Programming Interface (API) Specification Web service specification (i.e. WSDL)

Can we Agree a Common Template? 1.An Understandable Name (just a name) 2.The Domain of Use (evolve a searchable vocabulary) (just a name, e.g. Assessment, PDP, Repositories, etc.) 3.What Purpose/s the Reference Model addresses (some text) 4.The Human Context (tasks/workflow supported) (some text + UML Activity diagram) 5.The Machine Context (apps & services involved) (UML Deployment diagram & links to Framework boxes) 6.(Web) Service Orchestration / Choreography (UML Activity diagram & links to (e.g.) WS-BPEL spec) 7.Specs / Standards / Application Profile Used (link) 8.Spec Binding adopted (link)

Can we Agree a Common Template? For each (Web) Service specification used, specify: A Link to the Service Specification or Standard (either existing, or a prototype specification created for the Reference Model - it should contain Service Use Cases, an Abstract UML Model/s of the Input & Output Data and Operations, and a Binding, e.g. an XML Schemas for Data & a service WSDL) OR A Link to the Application Profile of a Specification adopted for the Reference Model including: 1.Subset used &/or extensions &/or additional constraints 2.Reasons for the Profile in the context of Reference Model 2.Add any new Specs or Application Profiles developed or adopted for the Reference Model to the appropriate service box in (or if no box is available propose adding a new box to) the Framework (Grow the Framework!)

Compare: DLF Reference Model Template I. Definition of Business Requirement Articulate the nature and scope of the business requirement addressed by the reference model. This section should also explain the importance of the business requirement in relation to digital libraries (i.e., in context of the over-arching framework), and to stakeholders in digital library services (i.e., the value proposition). II. Use Cases and Business Processes Collect a portfolio of use cases for the business requirement. Use cases will then provide context for identifying a set of well-defined business processes which, in aggregate, constitute the scope of the business requirement. III. Identification of Abstract Services For each business process identified in (II), enumerate a list of abstract services which, in aggregate, constitute the scope of the business process. IV. Service Description For each abstract service identified in (III), identify and describe the service instantiation needed to fulfill the business requirement. Descriptions should also make reference to any standards, protocols, or best practices that would be relevant to implementation. V. Pain Points Given the service-oriented description of the business requirement, identify pain points – i.e., gaps in current capacity that impede progress from the reference model to design. Create a development agenda listing priority activities that will address these pain points.

Comments on DLF Reference Model It could be argued that what is defined as a business process in the DLF Reference Model Template is treated as a use case, or that it doesnt distinguish between the two, or that it states that use cases provide the context for business processes, whereas it should be the other way around: business processes provide the context for use cases. Most developers understand a use case to relate directly to the system they are to develop For an example of a DLF Reference Model, developed by Andy Powell of UKOLN covering an aspect of the JISC IE Architecture, see: NOTE: Andy posted this as a trial attempt to illustrate the concept. He notes that DLF is changing its definition, and he is likely to rework it. However it provides a useful example for exploring the issues.

Comments on DLF Reference Model Ivar Jacobson, who originated the use case concept, defines it as: A use case specifies a sequence of actions, including variants, that the system can perform (to) yield an observable result of value to a particular actor. Jacobson, Booch & Rumbaugh, The Unified Development Process, Addison Wesley, 1999 In this definition of a use case, the system is a black box and the sequence of actions is set out as a sequence of both the actions carried out by an actor and the responses made by the system. The value of the observable result is typically defined in terms of the larger context in which the use-case is being performed, and this is normally a business process of some kind. The confusion arises because people also talk of business level use cases, in which an organisation, team or service is treated as a black box that delivers some value to the customer or client.

Sorting out Use Case Levels We thus have different levels of use case, the business level use case and the machine level use case. It would seem that in the DLF model: use case = business use case Organisation Business Use case Business (/ Learning / Support) Process Computer System Use case Computer System Use case Computer System Use case Let us use Business Use Case at this level and Use Case (unqualified) where a user is working with a computer application

Sorting out Use Case Levels In the context of a Service Oriented Architecture, we have still lower level use cases relating to the use of the underlying services Business (/ Learning / Support) Process Computer System Use case Computer System Use case Computer System Use case BPEL Orchestrator Service A Use case Service B Use case Let us refer to service level use cases as Service Use Cases

Levelling is Tricky However Andys Reference Model is pitched at a very low level, where the business requirement, Discovery to Delivery, is more like a (user application level) use case, and the business process is more like the sequence of steps within the use case. (Only if the whole completes successfully does it deliver value to the user.) So, for Andys example the Business Requirement might be Learning, Course Preparation and/or Research, and the Business Process (or user context scenario) might be: 1.The user is authoring an essay, learning resource or paper 2.They have broken it down into topic, sub-topics and related topics 3.They are searching for resources related to one of these topics 4.They enter a system that implements Andys D2D RM(/use case?) 5.On retrieving resources they view them, and then: store copies of some, store references/links to some reject the rest as not relevant. 6.They repeat for other topics 7.They use or reference the resources in what they are authoring

Comparison of Proposed and DLF Templates Comparison with DLF (Digital Libraries Foundation) JISC Reference Model FormatDLF 1.An Understandable Name 2.The Domain of Use 3.What Purpose/s Business Requirement 4.Tasks / workflow supportedBusiness Processes 5.The Machine Context (included in Andys example) 6.Orchestration / Choreography (included in Andys example) 7.Specs/Standards/App ProfileAbstract Services Deployed Services 8.Spec Binding adoptedService Bindings