Information System Architecture

Information System Architecture

Information system The data is the raw material of any I.S.
Before becoming information, the data must be created, stored, processed, analyzed and distributed. Information systems can be characterized by their functions: the generation, storage, presentation, exchange, interpretation, transformation, and transportation of information.

An application-centric view of IS
Applications, developed independently of each other, provided functionality that can only be used within the boundaries of each application. Differences between platforms, programming languages, and protocols created technology boundaries that are not easy to cross. As a result enterprises lost the flexibility the agility they need in the marketplace; IS stopped being part of a solution and became more of a problem; enterprises ISs locked them into specific ways of, and created barriers to, carrying out Business.

Architecture Design 1/3 “An architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”IEEE STD Is used to: Make buy decisions. Discriminate between options. “Discover” the true requirements. Drive one or more systems to a common “use” or purpose. Develop system components. Build the system. Understand and conduct changes in the system as the BP is modified.

Architecture Design 2/3 It focuses on the creation of new systems designed to play a role in some business environments. A key factor is the systematic, controlled and coordinated development of systems’ components and the ability to keep overview over the complexity of the system. The way to do this is to use models to describe parts or aspects of a system. A set of models that together define the essentials of a system is called the architecture of the system. The architecture of a system plays different roles, in the development process and during the life cycle of a system.

Architecture Design 3/3 Besides the development of totally new systems it becomes more and more important to consider the renewal or renovation of existing systems. This requires different approaches and introduces new challenges. One of the major issues is that the systems engineers have to understand the system that has to be renovated. An existing system puts extra constraints on the development of new parts which makes renovation different from development from scratch.

Architecture Framework
“An architecture framework is a tool… It should describe a method for designing an information system in terms of a set of building blocks, and for showing how the building blocks fit together. It should contain a set of tools and provide a common vocabulary. It should also include a list of recommended standards and compliant products that can be used to implement the building blocks.” [TOGAF 8, OpenGroup]

Enterprise engineering
Resources management, enterprise organization, production management.

Business Management Economiy, cognitive, trust management… etc.

Computer science Information system, decision making systems…etc.

Architecture Products: Graphic, Textual, and Tabular…
Dictionary Relationships Organizations Locations Functions Applications Entities Database/file Technology Platforms Tech Platform X Systems Node Name System Name Function Component Operational Activity Link Name/ID Needline Name Interface Use products to: Capture Analyze Communicate

Enterprise competitive edge
An enterprise’s competitive edge and ultimate success are enabled by its ability to rapidly respond to changing business strategies, governance, and technologies. The competitive edge translates into higher levels of customer satisfaction, shorter work cycles, and reductions in schedules, maintenance costs, and development time, all resulting in lower overall cost of ownership.

Enterprise Architecture
Enterprise Architecture is the key facilitating ingredient providing a holistic view and a mechanism for enabling the design and development as well as the communication and understanding of the enterprise. The goals of enterprise architecture are to manage the complexity of the enterprise, align business strategies and implementations, and facilitate rapid change in order to maintain business and technical advantages. IS Enterprise Architecture is like urban planning.

City planning metaphor

Urban planning …..What!!? Consists of cutting out IS in autonomous modules, of more and more small size, in a way similar to the city. Between these modules we establish zones of information exchange, which render possible to decouple the various modules.

Urbanisation: the goal?
They can be evolved/removed separately while preserving their ability to: Interact with the remainder of the system. Replace some of these subsystems (inter- changeability). Guarantee the possibility to integrate subsystems of various origins (integration). Strengthen the capability to interact with others ISs (Interoperability).

Important rules of Urbanisation
The autonomy of functional system’s components. The crosscutting nature of the functionalities applied on all system components should be thought to provide an end to end homogenous solutions. Avoiding the “spaghetti” effect in the enterprise’s information system. These principles enable the agility of the information system to align with the changes in the enterprise organisation and strategy entrained by markets’ changes.

Urbanization, the what and why?
City planning metaphor: How to re-organize or evolve a city while keeping a normal life for city’s inhabitants during the construction or re- construction? In the same way: how to re-organize the IS without totally destroying the existing applications and while maintaining IS functionalities during the re- construction; IS must be reorganized to facilitate its evolution while protecting its informational legacy.

Urbanisation : what else?
Allows establishing the link between: mission of the organization, exchanges, internal and external actors, business event, business process, information, applications and infrastructure. Provide a complete description of IS on functional, organisational and technical levels. Being a decision-making support tool to understand change impacts during the evolutions (business, functional, applicative, and technical).

Non-Urbanized City 

Urbanized city 

Non-Urbanized IS 

Urbanized IS 

Multilayer approach

Multilayer approach! The methodology is based on a reference framework integrating four views from the information system: Business view: it describes all the business activities of the enterprise that the information system must support. Functional view: it describes the information system functions which support the business process. Applicative view: it describes all the applicative elements of a data processing system. Technical view: it describes all the hardware, software and technologies used to support the functionality of the information system.

Ishikawa diagram The strategy is modelled by a hierarchy of goals represented by ISHIKAWA diagrams, breaking up them into sub-objectives until reaching the lower level in which all the objectives are achieved by at least one process. This diagram is constrained by the following rules (urbanisation rules for the diagram of objectives): The same objective appears once and only once in the diagram. If an objective is divided in sub-objectives the list of those must be exhaustive. An objective of the lower level must be associated to one or more of performance indicators.

Urbanisation and strategy

Urbanisation and BP Tiré des cours: C. Costaz

Urbanisation Modeling
Tiré des cours: C.Costaz

Processes Identification
Operational processes Monitoring and Governance Support

Urbanization rules IS urbanization initiative should satisfy the following rules: Affiliation: in the hierarchical decomposing of an information system, each component belongs to one and only one unit. Autonomy: no dependency should exist between units; a unit can deal with an Event from start to end, without the need for treatment in another unit. Asynchronism: a unit can handle an event and send the result without waiting for the response from the receiver. Data Normalization: the results produced by each unit are based on recognized standards. Single Exit Point: the information in each unit is sent by a single point. Data Ownership: each unit is responsible for its own data; updates of these data are carried out by each individual unit. Passage Point: units communicate indirectly via an Entity which is responsible for data flow management.

Urbanisation Business Functions
Tiré des cours: C.COSTAZ

Service Oriented Architecture
Today, component based development is considered to be the most promising way of developing information systems. The idea is instead of constructing the software from scratch; we achieve a selection, re-configuration and assembly of existing components. Of course there is always a need for new components. The idea is to reuse existing components to compose different functions using particular mechanisms in order to satisfy specific needs of a given business domain or environment.

What is SOA? Applications must open up their capabilities for use by other existing/new applications. It must be possible to combine the services offered by different applications to create higher-level services or composite applications. Technology differences must not matter; interoperability must be a key goal. Open standards must be adopted to enable integration across enterprises. Attention must be paid to governance and manageability in order to make sure that flexibility granted by the first three principles does not lead to chaos.

What is SOA? Services: distinct units of loosely coupled technical or business functions, which can be distributed over a network and can be invoked, combined and reused to create new business processes. These services communicate with each other by passing messages from one service to another, and by coordinating their activities using an orchestrator. Orchestrator: a part of the middleware assembling published services and coordinating their interactions into business flows.

SOA principals? The use of explicit implementation-independent interfaces to define services (adaptors). The use of communication protocols that stress location transparency and interoperability. The definition of services that encapsulate reusable business function.

Middleware!

Middleware capabilities
Security. Transformation (Data). Mediation (functional and semantic). Routing. Monitoring. Tracing. End to end QoS. Searching and matching. Invocation.

Middleware

Middleware!

What qualifies as a service?
A service is defined at the right level of granularity, from the point of view of a service consumer. A service is discoverable. Consumers looking for a service can discover its presence, usually by looking up a service registry (as la the yellow pages in a phone directory). A service is self-describing. Potential consumers can learn by themselves how to invoke the service. A service is technology-agnostic. Potential consumers are not constrained from using the service because of a mismatch in hardware or software platforms. A service can be composed with other services to create a higher-level service.

SOA « typical » standards
UDDI: Universal Description, Discovery and Integration. WSDL: Web Services Description Language. SOAP: Simple Object Access Protocol.

Services Client Services directory (UDDI) 2 - HTTP Get
Seache a service Services directory (UDDI) 3 – WSDL (encapsulaed in a SOAP) 1 service Publication 4 - request “Soap” service Invocation Service Provider 5 - response “Soap”

? Composite service Services geographic Info. touristy Info.
I want to pass tow weeks in a cold, dry, not very far, and cheap country with a lot of touristy views Services geographic Info. touristy Info. Weather Info. Plane tickets Travel Agency Hotels Car rental

What is 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. For more information see:

How can UDDI be Used? If the industry published an UDDI standard for flight rate checking and reservation, airlines could register their services into an UDDI directory. Travel agencies could then search the UDDI directory to find the airline's reservation interface. When the interface is found, the travel agency can communicate with the service immediately because it uses a well-defined reservation interface.

UDDI structure A business or company can register three types of information into a UDDI registry. This information is contained into three elements of UDDI. These three elements are : White pages: contains: information which allows others to discover your web service based upon your business: Basic information about the Company and its business. Basic contact information including business name, address, contact phone number etc. A unique identifiers for the company. Yellow pages, contains: More details about the company, and includes descriptions of the kind of electronic capabilities the company can offer to anyone who wants to do business with it. It uses commonly accepted industrial categorization schemes, industry codes, product codes, business identification codes and the like to make it easier for companies to search through the listings and find exactly what they want. Green pages, contains technical information about a web service. This is what allows someone to bind to a Web service after it's been found. This includes: The various interfaces The URL locations Discovery information and similar data required to find and run the Web service.

UDDI data structure UDDI includes an XML Schema that describes four core data structures: businessEntity businessService bindingTemplate

BusinessEntity data structure
The business entity structure represents the provider of web services. Within the UDDI registry, this structure contains information about the company itself, including contact information, industry categories, business identifiers, and a list of services provided. Here is an example of a fictitious business's UDDI registry entry: <businessEntity businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40" operator=" authorizedName="John Doe"> <name>Acme Company</name> <description> We create cool Web services </description> <contacts> <contact useType="general info"> <description>General Information</description> <personName>John Doe</personName> <phone>(123) </phone> </contact> </contacts> <businessServices> ... </businessServices> </businessEntity>

BusinessService data structure
The business service structure represents an individual web service provided by the business entity. Its description includes information on how to bind to the web service, what type of web service it is, and what taxonomical categories it belongs to. Here is an example of a business service structure for the Hello World web service: <businessService serviceKey="uuid:D6F1B765-BDB D E5A2A" businessKey="uuid:C0E6D5A8-C446-4f01-99DA-70E212685A40"> <name>Hello World Web Service</name> <description>A friendly Web service</description> <bindingTemplates> ... </bindingTemplates> </businessService> Notice the use of the Universally Unique Identifiers (UUIDs) in the businessKey and serviceKey attributes. Every business entity and business service is uniquely identified in all UDDI registries through the UUID assigned by the registry when the information is first entered.

bindingTemplate data structure
Binding templates are the technical descriptions of the web services represented by the business service structure. A single business service may have multiple binding templates. The binding template represents the actual implementation of the web service. Here is an example of a binding template for Hello World: <bindingTemplate serviceKey="uuid:D6F1B765-BDB D E5A2A" bindingKey="uuid:C0E6D5A8-C446-4f01-99DA- 70E212685A40"> <description>Hello World SOAP Binding</description> <accessPoint URLType="http"> </accessPoint> </bindingTemplate> Because a business service may have multiple binding templates, the service may specify different implementations of the same service, each bound to a different set of protocols or a different network address.

Web Services Description Language. Written in XML.
WSDL Web Services Description Language. Written in XML. Used to describe and to locate Web services. For more information see:

The main structure of WSDL
It contains set of definitions to describe a service. 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.

WSDL PortType The <portType> element is the most important WSDL element. It defines for a web service, the operations that can be performed, and the messages that are involved in these operations. The port defines the connection points to a web service. It can be compared to a functions library in a traditional programming language(or a class in OO language). Each operation can be compared to a function in a traditional programming language.

WSDL Messages The <message> element defines the data elements of an operation. Each message can consist of one or more <part>. Parts can be compared to the parameters of a function call in a traditional programming language.

WSDL Types The <types> element defines the data type that are used by the web service. For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.

Example <message name="getVoyageRequest"> <part name="Destination" type="xs:string"/> <part name="Date" type="xs:string"/> </message> ---- <message name="getVoyageResponse"> <part name=" Price" type="xs:string"/> <portType name="VoyageDirectory"> <operation name="getVoyage"> <input message="getVoyageRequest"/> <output message="getVoyageResponse"/> </operation> </portType>

In this example <portType> element defines " VoyageDirectory " as the name of a port, and " getVoyage " as the name of an operation. The "getTerm" operation has an input message called "getVoyageRequest " and an output message called " getVoyageResponse ". The <message> elements define the parts of each message and the associated data types. Compared to traditional programming, "VoyageDirectory" is a functions’ library, "getVoyage" is a function with "getVoyageRequest" as the input parameter and "getVoyageReponse" as the return parameter.

Operation Types One-way: The operation can receive a message but will not return a response. Request-response: The operation can receive a request and will return a response. Solicit-response: The operation can send a request and will wait for a response. Notification: The operation can send a message but will not wait for a response

One-Way Operation An example: <message name="newVoyageValues">
<part name=“Date" type="xs:string"/> <part name=“Destination" type="xs:string"/> <part name=“Price" type="xs:string"/> </message> <portType name=" VoyageDirectory "> <operation name="setVoyage"> <input name="newVoyage" message="newVoyageValues"/> </operation> </portType > In this example the port " newVoyageValues " defines a one-way operation called "setVoyage". The " setVoyage " operation allows input of new voyage items messages using a "newVoyageValues" message with the input parameters “Date“,“Destination“ and “ Price“ . However, no output is defined for the operation.

WSDL bindings (1) Defines the message format and protocol details for a service, example binding to SOAP a request-response operation : <binding type=" VoyageDirectory " name="bi"> <soap:binding style="document“ transport=" /> <operation> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding>

WSDL bindings (2) The binding element has two attributes - the name attribute and the type attribute. The name attribute (you can use any name you want) defines the name of the binding, The type attribute points to the port for the binding, in this case the "VoyageDirectory " port. The soap:binding element has two attributes - the transport attribute and the style attribute. The transport attribute defines the SOAP protocol to use. In this case we use HTTP. The style attribute defines the message style, it can be "rpc" or "document". In this case we use document. The operation element defines each operation that the port exposes. For each operation the corresponding SOAP action has to be defined. You must also specify how the input and output are encoded. In this case we use "literal".

SOAP SOAP is transport neutral; SOAP can be used across HTTP, FTP, SMTP …etc. SOAP includes a whole stack of “composable” WS- * specifications; WS-Security for inserting security tokens into SOAP headers, WS-ReliableMessaging, WS-Transactions, ….etc. For details see:

SOAP Used for both Messaging and RPC Simple structure Envelope
Header (optional) Body

The SOAP Header Element
The optional SOAP Header element contains application specific information (like authentication,) about the SOAP message. If the Header element is present, it must be the first child element of the Envelope element. The SOAP mustUnderstand attribute can be used to indicate whether a header entry is mandatory or optional for the recipient to process. If you add "mustUnderstand="1" to a child element of the Header element it indicates that the receiver processing the Header must recognize the element. If the receiver does not recognize the element it must fail when processing the Header.

The Actor Attribute A SOAP message may travel from a sender to a receiver by passing different points along the message path. Not all parts of the SOAP message may be intended for the ultimate endpoint of the SOAP message but, instead, may be intended for one or more of the endpoints on the message path. The SOAP actor attribute may be used to address the Header element to a particular endpoint.

The SOAP Body Elements The SOAP Envelope element is the root element of a SOAP message. It defines the XML document as a SOAP message. It should always have the value of: The required SOAP Body element contains the actual SOAP message intended for the ultimate endpoint of the message.

SOAP over HTTP An HTTP client connects to an HTTP server using TCP. Client sends an HTTP request message to the server, example: POST /item HTTP/1.1 Host: Content-Type: text/plain Content-Length: 200 The server then processes the request and sends an HTTP response back to the client. The response contains a status code that indicates the status of the request: 200 OK Content-Length: Or: 400 Bad Request Content-Length: 0

SOAP/HTTP Binding A SOAP request could be an HTTP POST or an HTTP GET request SOAP=HTTP + XML, example: POST /login.ispatu-ryukyus, HTTP/1.1 Host: Content-Type: application/soap+xml; charset=utf-8 Content-Length:1000 <soap:Envelope xmlns:soap=" <soap:Header> <user:credentials soap:mustUnderstand="1"> > <username>Layth</username> <password>Okinawa</password> </user:credentials> …………….. </soap:Envelope>

Web Services Standards for SOA The Web Services Platform Architecture
Messaging Quality of Service Transport Description Components Interface + Bindings Composite XML Non-XML Security Policy Discovery, Negotiation, Agreement Atomic Orchestration Protocols State Reliable Messaging Transactions Component Model 74

Service Orientation « review »
Like objects and components, services represent natural building blocks that allow us to organize capabilities in ways that are familiar to us. Similarly to objects and components, a service is a fundamental building block that: Combines information and behaviour. Hides the internal workings from outside intrusion. Presents a relatively simple interface to the rest of the organism. Where objects use abstract data types and data abstraction, services can provide a similar level of adaptability through aspects. Where objects and components can be organized in class or service hierarchies with inherited behaviour, services can be published and consumed singly or as hierarchies and or collaborations.

Other SOA standards UDDI, WS-Addr, Metadata Exch.,… WS-BPEL WS-C WS-N*
Messaging Quality of Service Transport Description Components Interface + Bindings Composite XML Non-XML Security Policy Discovery, Negotiation, Agreement Atomic Orchestration Protocols State Reliable Messaging Transactions Component Model UDDI, WS-Addr, Metadata Exch.,… WS-BPEL WS-C WS-N* SCA WS-RF WS-RM WS-Security* WS-AT WS-BA WS-C: Alle Arten von Koordinaten und Agreement, Auktionen, ... WS-N* = WS-Notification (WS-BaseNotification, WS-Topics, WS-BrokeredNotifcation) SCA = Service Component Architecture WS-RF = Resource Framework SOAP: W3C, ready WSDL: W3C, ready XML: W3C, ready WS-Security: OASIS, ongoing (IBM, MS, ... Published spec) WS-SecureConversation, WS-Federation, WS-Trust: IBM, MS, ... Published specs WS-Authorization, WS-Privacy: Specification required WS-ReliableMessaging: OASIS, ongoing (IBM, MS, ... Published spec) [WS-Reliability: competing spec from Sun and Oracle, but: authors now join OASIS WS-ReliableMessaging TC] WS-TX: WS-Coordination, WS-AtomicTransactions, WS-BusinessAgreement: OASIS, ongoing (IBM, MS, ... Published spec) [WS-CAF (Composed Application Fw): competing spec from Oracle, IONA, Arjuna ... but: IONA, Arjuna now co-author WS-Coordination, WS-AtomicTransactions, WS-BusinessAgreement] WS-Policy: IBM, MS, ... Published spec UDDI: OASIS, ready WS-MetaDataExchange (WS-MEX): IBM, MS, ... Published spec WS-Addressing: W3C, ongoing (IBM, MS, ... Published spec) WS-BPEL: OASIS, ongoing (IBM, MS, ... Published spec) WS-DistributedManagement (WS-DM): IBM, CA, HP [competing spec from MS: WS-Management, but unlikely to win because IBM, CA, HP are dominant in Sys Mgmt market] Security in a Web Services World: A Proposed Architecture and Roadmap WSDL* WS-Policy* SOAP, WS-Addr* JMS, RMI/IIOP, ... HTTP, TCP/IP, SMTP, FTP, … 76

Web Services Standards for SOA The Web Services Platform Architecture
Messaging Quality of Service Transport Description Components Interface + Bindings Composite XML Non-XML Security Policy Discovery, Negotiation, Agreement Atomic Orchestration Protocols State Reliable Messaging Transactions Component Model UDDI, WS-Addr, Metadata Exch.,… WS-BPEL WS-C WS-N* SCA WS-RF WS-RM WS-Security* WS-AT WS-BA SCA: Open Service Oriented Architecture = “informal alliance of industry leaders” WS-C: Alle Arten von Koordinaten und Agreement, Auktionen, ... WS-N* = WS-Notification (WS-BaseNotification, WS-Topics, WS-BrokeredNotifcation) SCA = Service Component Architecture WS-RF = Resource Framework SOAP: W3C, ready WSDL: W3C, ready XML: W3C, ready WS-Security: OASIS, ongoing (IBM, MS, ... Published spec) WS-SecureConversation, WS-Federation, WS-Trust: IBM, MS, ... Published specs WS-Authorization, WS-Privacy: Specification required WS-ReliableMessaging: OASIS, ongoing (IBM, MS, ... Published spec) [WS-Reliability: competing spec from Sun and Oracle, but: authors now join OASIS WS-ReliableMessaging TC] WS-TX: WS-Coordination, WS-AtomicTransactions, WS-BusinessAgreement: OASIS, ongoing (IBM, MS, ... Published spec) [WS-CAF (Composed Application Fw): competing spec from Oracle, IONA, Arjuna ... but: IONA, Arjuna now co-author WS-Coordination, WS-AtomicTransactions, WS-BusinessAgreement] WS-Policy: IBM, MS, ... Published spec UDDI: OASIS, ready WS-MetaDataExchange (WS-MEX): IBM, MS, ... Published spec WS-Addressing: W3C, ongoing (IBM, MS, ... Published spec) WS-BPEL: OASIS, ongoing (IBM, MS, ... Published spec) WS-DistributedManagement (WS-DM): IBM, CA, HP [competing spec from MS: WS-Management, but unlikely to win because IBM, CA, HP are dominant in Sys Mgmt market] Security in a Web Services World: A Proposed Architecture and Roadmap WSDL* WS-Policy* SOAP, WS-Addr* JMS, RMI/IIOP, ... HTTP, TCP/IP, SMTP, FTP, … 77

SOA and BPM SOA is about constructing software components that can be reused in context unknown at design time Composition. BPM is about being able to precisely model and possibly change the context in which enterprise components are used But how the two meet?

Services Composition

Elements of BPM Initiates Activity Event changes State Entity performs
Content Actor generates Services Represented by

BPEL “BPEL is an XML language for defining the composition of (web) services into (new) services” (Paul Brown, FiveSight) BPEL is above all a simple Orchestration language not a Business Process Language. A process is composed of a large set of orchestration definitions interacting with each other. BPEL assumes that business processes can be fully captured in a single definition, including all possible exception paths.

A business process does not have a “center”…it is de facto “peer-to-peer”
OAGIS 8.1 Scenario 50 © attachmate 2004

A very simple example A buyer orders some goods from a supplier.
The supplier performs a series of steps to fulfill the order. Approve the order Update the order entry system Update the billing system …

Orchestration languages
They allow us to implement complex services which involve: Long running (from a few hours to a few months), And event driven business logic They are not about modeling Business Processes by themselves Different orchestration (i.e. different services) can run within the same business process And vice versa © attachmate 2004

A Business Process can be Viewed as a Multi-Party Choreography of Peer Services. A Choreography Provides a Model of the Event Flow Between Activities. Start Sales person Buyer Supplier SFA Events Activity ERP Mapping Routing Accounts Account RFQ Quote RFQ User Activity RFQ Order CreditCheck.com SalesTax.com Order Orders Billing Invoice Sales Order Order Invoice © attachmate 2004

Services in a SOA are orchestrated (BPEL) !
Quote Service Orchestration Definition Entity State <<receive>> RFQ RFQ <<invoke>> GetQuote RFQ Quote No Ok? Nack sendNack <<invoke>> calculateSalesTax Sales Tax Quote <<send>> quote updateDB Order Transition Ok? No © attachmate 2004 Message flow

Orchestration vs. Choreography
« … is a concept that gives programmers a way to formally describe processes underlying business applications so that they can be exposed and linked to processes in other applications » Choreography Is a concept that specifies how these processes are linked together across the enterprise or between enterprises. They are both a form of Coordination © attachmate 2004

Business Process Execution Language (BPEL)
Web Services Business Process Execution Language (WS-BPEL) is a language for describing business processes based on Web Services Processes described using WS-BPEL execute functionality by using Web Service interfaces exclusively WS-BPEL Specification is administered by OASIS WS-BPEL is an orchestration language, not a choreography language Orchestration specifies an executable process that involves message exchanges, such that that the message exchange sequences are controlled by the orchestration designer. Choreography specifies a protocol for peer-to-peer interactions, defining the legal sequences of messages exchanged with the objective of guaranteeing interoperability A choreography is not directly executable A choreography can be implemented through an orchestration (i.e. a BPEL process) 88

Executable process vs. Abstract process
Business processes may be classified as either executable or abstract. These and other related terms are defined as follows. Executable process An executable process defines a coordinated set of activities that are performed within a single scope of control in response to a business event. The single scope of control aspect is important because it allows an executable process to be controlled directly by a system. In an electronic commerce context, executable processes exist within business entity boundaries, and their details are not visible externally. Hence they are also referred to as private. The term orchestration has come into common use to refer to the coordination of Web services in a private executable context. Abstract process An abstract process defines the interaction between two or more independent systems via their external interfaces in response to a business event. It can also be referred to as a business protocol. An abstract process is by definition not directly controlled by any of its participating entities, and hence cannot be implemented as an executable system. In an electronic commerce context, abstract processes exist between business entity boundaries and are visible externally. Hence they are also referred to as public. The term choreography has come into common use to refer to the coordination of Web services in a public abstract context. BPEL exploits the synergy between abstract processes and executable processes by defining a core set of common constructs with extensions added to support each of these distinct process types.

WS-BPEL Design Goals Business processes defined using an XML-based language Web services are the model for process decomposition and assembly. The same orchestration concepts are used for both the external (abstract) and internal (executable) views of a business process. An identification mechanism for process instances is provided at the application message level. The basic lifecycle mechanism is in implicit creation and termination of process instances. A long-running transaction model is defined to support failure recovery for parts of long-running business processes. Language built on compatible Web services standards in a composable and modular manner. 90

BPEL Standard Sponsorship
91

BPEL key elements 1/2 The language includes the following key elements: Partner link type A partner link type defines the relationship between two Web services by specifying the role played by each of the services and the port types used in the interaction. Variable A variable is used to store a local copy of a message or data in a process instance. Correlation set A correlation set defines the message properties (aliases for message parts) to be used to match incoming messages to the correct process instance. A correlation set is needed if a process has more than one receive or pick activity. A correlation set, once initialized, acts as a constant for the rest of the process lifetime. Receive A receive is used to wait for a request message sent to a Web service implemented by the process. Reply A reply is used to send a response message to the sender of the request message that initiated the process instance. Pick A pick is used to receive a message via one or more port types and select a branch based on message type received.

BPEL key elements 2/2 Sequence
A sequence is used to perform a set of activities in a series. Flow A flow is used to perform a set of activities in parallel. Link A link is used to create a synchronization point between parallel activities. Switch A switch is used to select a branch based on the evaluation of an expression. While A while loop is used to iterate under the control of a boolean expression. Invoke An invoke is used to call a Web service. Wait A wait is used to delay for a period of time. Empty An empty activity does nothing. It may be used as a placeholder for an activity yet to be specified, or when a fault needs to be caught and suppressed. BPEL also has constructs for expression handling, defining scope, event handling, fault handling within units of work, and compensation to reverse the effect of committed units of work. BPEL is dependent on the WSDL 1.1 standard:

WS-BPEL Language Constructs
WS-BPEL process definition Recursive composition and partner links Variables Correlation sets Basic and structured activities Scopes Compensation handling Overview of WS-BPEL 2.0 language elements 94

WS-BPEL Process Definition
imports Declare dependencies on external XML Schema or WSDL definitions extensions Declare namespaces of WS-BPEL extension attributes and elements partner links Relationships that a WS-BPEL process will employ in its behavior message exchanges Relationship between inbound and outbound message activities variables Data holding state of a business process or exchanged with partners correlation sets Application data fields that together identify a conversation event handlers Concurrently process inbound messages or timer alarms fault handlers Deal with exceptional situations in a process Elements of a process definition primary activity Perform the process logic – any number of activities may be recursively nested XML schemas WSDL definitions 95

Recursive Composition Model
WS-BPEL processes are exposed as Web services to business partners WS-BPEL processes interact with Web services exposed by business partners Web Service WSDL Loan Approval PortType Web Service Financial institution‘s Web service implementation (Loan Approver) Loan Approval Process invoke receive reply 96

Reference to WDSL portType element
Partner Links Element WDSL describes functionality of services provided by a partner Partner Link describes the shape of the relationship with a partner by describing the Port Types used in a peer to peer relationship Example: <partnerLinks> <partnerLink name=“Invoice” partnerLinkType=“inv:InvoiceType” partnerRole=“InvoiceServiceProvider”/> <partnerLink name=“Employee” partnerLinkType=“emp:EmployeeType” partnerRole=“EmployeeServiceProvider”/> </partnerLinks> Reference to WDSL portType element 97

Partner Links process partner link receive
Inbound request – service provided by the process invoke Outbound request – service required by the process partner link type Peer-to-peer conversational partner relationship Partner links are channels along which peer-to-peer conversations with partners take place WSDL port type myRole Provided port type WSDL port type partnerRole Required port type 98

Message Name from Partner Process Definition
Variable Element Variable construct is used to state information related to workflow logic Variables can contain entire messages and data sets formatted as XML schema types Example: <variables> <variable name=“EmployeeHoursRequest” messageType=“emp:getWeeklyHoursRequestMessage”/> </variables> Message Name from Partner Process Definition 99

Variables xsl:transform 42 42 process WSDL message messages
Variables defined using WSDL messages receive request invoke request response reply response 42 xsl:transform Variables are typed using WSDL messages or XML Schema elements or simple/complex types Activities’ input and output kept in scoped variables Assignment activities move data around assign 42 XML schemas XML Schema elements / types Variables defined using XML schema elements or types 100

Properties and Correlation Sets
How to identify stateful instances via stateless WS interfaces? A process instance is assigned one or more keys Business data is used as key, e.g., customerID A key can be compound, e.g., (customerID, orderNumber) WS-BPEL calls a key a correlation set – it is used to correlate an incoming message with a process instance customerID orderNumber Process 4 (0123,15) Process 3 (0815,42) Process 2 (4711,37) 4711 37 Message 1 Process 1 (0815,12) 0815 42 Message 2 101

Basic Activities process receive reply invoke Invoke a one-way or
request-response operation Do a blocking wait for a matching message to arrive / send a message in reply exit Immediately terminate execution of a business process instance compensate compensateScope Invoke compensation on all completed child scopes in default order Invoke compensation on one completed child scope validate assign Update the values of variables or partner links with new data Validate XML data stored in variables wait Wait for a given time period or until a certain time has passed throw rethrow Generate a fault from inside the business process Forward a fault from inside a fault handler empty No-op instruction for a business process extensionActivity Wrapper for language extensions 102

Structured Activities
process flow Contained activities are executed in parallel, partially ordered through control links pick Block and wait for a suitable message to arrive (or time out) B C A M1 M2 … A sequence Contained activities are performed sequentially in lexical order forEach Contained activity is performed sequentially or in parallel, controlled by a specified counter variable 2. N. 1. … 2. N. 1. … while Contained activity is repeated while a predicate holds repeatUntil Contained activity is repeated until a predicate holds if-elseif-else Select exactly one branch of activity from a set of choices c1 c2 c … scope Associate contained activity with its own local variables, partner links, etc., and handlers c 103

BPEL Syntax Example Partner Definition
<?xml version="1.0" encoding="utf-8"?> <process name="insuranceSelectionProcess" targetNamespace=" xmlns=" xmlns:ins=" xmlns:com=" > <partnerLinks> <partnerLink name="client" partnerLinkType="com:selectionLT" myRole="insuranceSelectionService"/> <partnerLink name="insuranceA" partnerLinkType="ins:insuranceLT" myRole="insuranceRequester" partnerRole="insuranceService"/> <partnerLink name="insuranceB" </partnerLinks> … 104

BPEL Syntax Example Variable Definition
<variables>  <variable name="InsuranceRequest" messageType="ins:InsuranceRequestMessage"/>  <variable name="InsuranceAResposne" messageType="ins:InsuranceResponseMessage"/>  <variable name="InsuranceBResposne"  <variable name="InsuranceSelectionResponse" </variables> ... 105

BPEL Syntax Example Process Steps
<sequence>  <receive partnerLink="client" portType="com:InsuranceSelectionPT" operation="SelectInsurance" variable="InsuranceRequest" createInstance="yes" />  <flow>  <invoke partnerLink="insuranceA" portType="ins:ComputeInsurancePremiumPT" operation="ComputeInsurancePremium" inputVariable="InsuranceRequest" outputVariable="InsuranceAResposne" />  <invoke partnerLink="insuranceB" outputVariable="InsuranceBResposne" /> </flow> … 106

BPEL Syntax Example Process Steps (Cont’)
 <switch> <case condition="bpws:getVariableData('InsuranceAResposn e', 'confirmationData','/confirmationData/Amount') <= bpws:getVariableData('InsuranceBResposne', 'confirmationData','/confirmationData/Amount')">  <assign> <copy> <from variable="InsuranceAResposne" /> <to variable="InsuranceSelectionResponse" /> </copy> </assign> </case> <otherwise>  <assign> <copy> <from variable="InsuranceBResposne" /> <to variable="InsuranceSelectionResponse" /> </copy> </assign> </otherwise> </switch>  <reply partnerLink="client" portType="com:InsuranceSelectionPT" operation="SelectInsurance" variable="InsuranceSelectionResponse"/> </sequence> </process> 107

DoDAF An Integrated Architecture with Three Views
Information Flow Operational Elements Activities/ Tasks Identifies What Needs To Be Done And Who Does It View Systems Data Flow Communications X Y Z Relates Systems and Characteristics to Operational Needs View Prescribes Standards and Conventions Standards Rules Technical Standards View

DODAF Products The DODAF describes a set of 26 work products to ensure uniformity and standardization in the documentation and communication of architecture The 26 DODAF views are designed to document the entire architecture, from requirements to implementation

DODAF Products - Views The list of products is refined into four views: All Views (AV): is the overarching information describing the architecture plans, scope, and definitions Operational View (OV): focuses on the behaviours and functions describing the enterprise mission aspects System View (SV): describes the system and applications supporting the mission functions Technical Standards View (TV): describes the policies, standards and constraints

DODAF Products

DODAF Products - Essential
The current DODAF version indicates a subset of work products that should be developed at a minimum (essential) AV-1: Overview and Summary Information AV-2: Integrated Dictionary OV-2: Operational Node Connectivity Description OV-3: Operational Information Exchange Matrix OV-5: Operational Activity Model SV-1: System Interface Description TV-1: Technical Standards Profile

AV-1 & AV-2

OV-2 – Operational Node Connectivity Description

OV-3 – Operational Information Exchange Matrix
Table Headers Specified in Framework: Name of Operational Needline Supported (from OV-2) Name of Information Exchange Nature of Transaction (Mission/Scenario, Language, Content, Size/Units, Media, Collaborative or One-Way?) Purpose or Triggering Event Information Source (ID of Producing Node Element, Owning Organization of Node, Name of Producing Activity, UJTL ID) Information Destination (ID of Receiving Node Element, Owning Organization of Node, Name of Receiving Activity, UJTL ID) Performance Requirements (Frequency, Timeliness, Throughput, Other) Information Assurance Attributes (Classification Restrictions, Criticality/Priority, Integrity Checks Required, Assured Authorization to Send/Receive) Threats (Physical, Electronic, Political/Economic) Operational Environment (Weather, Terrain, Policy/Doctrine Constraints)

OV-5 – Operational Activity Model

SV-1 – System Interface Description

TV-1 – Technical Standards Profile

References Elements of this presentation are obtained from:
Constructing Software For Service Oriented Architecture Jean-Jacques Dubray, The Pennsylvania State University, The Smeal College of Business Administration. DoD Architecture Framework Overview, Alessio Mosto, OS.html#SA00005_table La première réponse historique à la rationalisation du SI est la démarche dite l’urbanisation . L’urbanisation des SI travaille sur : Processus métiers Communications inter applicative Sur la mise en place d’un référentiel transverses Resulat : Le système d’information d’une entreprise est représenté selon quatre niveaux d’architecture: L’architecture métier : processus métier de l’entreprise L’architecture fonctionnelle : blocs fonctionnels et flux d’information supports à la réalisation des processus métier, indépendamment des technologies mises en œuvre, L’architecture applicative : blocs applicatifs et échanges, supports à la réalisation des blocs fonctionnels et des flux. L’architecture technique : infrastructure sur laquelle sont implémentées et exécutés les blocs fonctionnels . Objectif est d’avoir une vue d’ensemble du SI 122 122

An Introduction to Knowledge Management

Objectives for this session
History & theory of Knowledge Management (KM) KM models Ontology and its design methodology

What is Knowledge Modeling?
Knowledge modeling is a process of creating a computer interpretable model of knowledge or standard specifications about a kind of process and/or about a kind of facility or product. The resulting knowledge model can only be computer interpretable when it is expressed in some knowledge representation language or data structure that enables the knowledge to be interpreted by software and to be stored in a database or data exchange file.

Seek knowledge from the cradle to the grave
Expertise, and skills acquired by a person through experience or education; the theoretical or practical understanding of a subject: Knowing that (facts and information) Knowing how (the ability to do something)

What is Knowledge? Knowledge is justified true belief. Ayer, A.J. (1956). The Problem of Knowledge. Knowledge is a fluid mix of framed experience, values, contextual information and expert insight that provides a framework for evaluating and incorporating new experience and information. It originates and is applied in the minds of knowers. In organizations it often becomes embedded not only in documents or repositories but also in organizational processes, practices and norms. Davenport, T.H. & Prusak, L (1998). Working Knowledge. Knowledge is information in action. O’Dell C. & Grayson Jr., C.J. (1998). If only we knew what we know.

Two types of knowledge Explicit knowledge Implicit (Tacit) knowledge
Know-how & learning embedded within the minds people. Documented information that can facilitate action. Explicit knowledge Formal or codified Documents: reports, policy manuals, white papers, standard procedures Databases Books, magazines, journals (library) Implicit (Tacit) knowledge Informal and uncodified Values, perspectives & culture Knowledge in heads Memories of staff, suppliers and vendors Knowledge informs decisions and actions. Sources: Polanyi, M. (1967). The tacit dimension. Leonard, D. & Sensiper, S. (1998). The Role of Tacit Knowledge in Group Innovation. California Management Review.

Layers of knowledge Explicit Implicit (Tacit) Individual
Personal documents on my C:\ Formalized process for developing curriculum. Corporate polices and procedures. In people’s heads. Undocumented ways of working in teams, teaching. Cultural conventions known and followed but not formalized. Organizational Source: Luan, J & Serban, A. (2002, June). Knowledge management concepts, models and applications. Paper presented at Annual AIR Forum, Toronto.

One Perspective of KM “KM [Knowledge Management] involves blending a company’s internal and external information and turning it into actionable knowledge via a technology platform.” Susan DiMattia and Norman Oder in Library Journal, September 15, 1997.

Understanding KM Understanding Knowledge Management requires an understanding of knowledge and the knowing process and how that differs from information and information management.

Classic Data to Knowledge Hierarchy
Wisdom Knowledge Information Data

From Facts to Wisdom

Data, Information & Knowledge
Source: Luan, J & Serban, A. (2002, June). Knowledge management concepts, models and applications. Paper presented at Annual AIR Forum, Toronto. "We are drowning in information but starved for knowledge" Naisbitt , J. (1984) Megatrends: Ten new directions transforming our lives.

Knowledge Management Models
Document Technology Learning & Communication

History of Knowledge Knowledge management is a new business strategy, but its techniques can be traced to the work of documentalists in the early part of the twentieth century.

Documentalists as Knowledge Managers
In Europe and America in the first part of the twentieth century, documentalists had grand visions of collecting, codifying and organizing the world’s knowledge. KM is seen as in the form of structural linguistics and semiotics.”.

Caution It would be a mistake, though, to define Knowledge Management as solely the domain of documents.

Contentnets and KM As knowledge repositories for tacit knowledge that has been made explicit For best practices databases For expert “yellow pages” Online learning and knowledge sharing Knowledge sharing “boards”

Peoplenets & Processnets
Group learning applications Social networks and Web 2.0 to connect individuals with each other for mentoring and knowledge sharing, decision support & decision making and capturing ideas and turn them into action… etc.

The Challenges of Collaboration & Knowledge Sharing
“Focusing exclusively on the technical issues of knowledge sharing is a vey good way to a very expensive failure.” “A focus on the people issues dramatically increases the potential for success.” David Coleman, IBM Manager, San Francisco in Knowledge Management, a Real Business Guide, London:IBM, nd.

KM advantages Flexibility and the ability to act quickly is necessary in a changing environment New projects can benefit from alliances and learning from in-house experts and creative thinkers. Innovation as a way of life

KM: Learning and Communication Process
In simple language KM is an effort to capture not only explicit factual information about the system and the organization but also the tacit information and knowledge that exists in a system or organization, usually based on the experience and learning of individuals, in order to enhance system’s implication in organization's mission achievement. The eventual goals are: Extract, represent and keep the knowledge capital. Share knowledge about the organization and the system among the different actors of the organization, its partners and customers.

How to represent the knowledge
Links and structures Notation Ontology.

What is an Ontology? An ontology is a specification of a conceptualization that is designed for reuse across multiple applications and implementations. …a specification of a conceptualization is a written, formal description of a set of concepts and relationships in a domain of interest. (Peter Karp (2000) Bioinformatics). It is a formal explicit description of concepts in a domain, properties of each concept describing various features and attributes of the concept (slots (sometimes called roles or properties)), and restrictions on slots (facets (sometimes called role restrictions)). An ontology together with a set of individual instances of classes constitutes a knowledge base. In reality, there is a fine line where the ontology ends and the knowledge base begins.

Ontology as a system of concepts
Used as conceptual building blocks of knowledge-intensive systems Something deeper than metadata It provides foundation on which a KB or an application system is built Ontology Knowledge Base (Model) An explicit specification of a hidden conceptualization of the target domain

Why? To share common understanding of the structure of information among people or software. Enabling reuse of domain knowledge. For example, models for many different domains need to represent the notion of time including notions of time intervals, points in time, and so on. If one develops such an ontology in detail, others can simply reuse it for their domains. Making explicit domain assumptions underlying an implementation makes it possible to change these assumptions easily if our knowledge about the domain changes. Hard-coding assumptions about the world in programming- language code makes these assumptions hard to change. Separating the domain knowledge from the operational knowledge is another common use of ontologies. We can describe a task of configuring a product from its components according to a required specification and implement a program that does this configuration independent of the products and components themselves. Analyzing domain knowledge is possible once a declarative specification of the terms is available.

From Knowledge Eng. To Ontological Eng.
KE is the research on: Domain-specific heuristics for a stand-alone problem solver OE is the research on: General/reusable/sharable/long-lasting concepts for building a KB/model for helping people solve problems.

Dichotomy of ontology Light-weight Ontology Heavy-weight Ontology
One like Yahoo ontology Vocabulary rather than concepts Annotation-oriented ontology Used for Information representation and search Heavy-weight Ontology Concepts rather than vocabulary for unified understanding the target system for building ontology-aware system Keep knowledge separated from system changes.

The fundamental role of an ontology
An ontology is not directly used for problem solving It gives a specification of knowledge and information models in a system The role of an ontology to a knowledge base is to give definitions of concepts used in the knowledge representation and constraints among concepts to make the knowledge base consistent and transparent which are the necessary properties of sharable and reusable knowledge Knowledge Amplifier systems.

Know that Ontologies’ Design principles

Why Ontologies? (review)
To share common understanding of the structure of information among people or software agents To enable reuse of domain knowledge To make domain assumptions explicit To separate domain knowledge from the operational knowledge To analyze domain knowledge

Building Ontologies(NN & DLM)
In practical terms, developing an ontology includes: defining classes in the ontology, arranging the classes in a taxonomic (subclass–superclass) hierarchy, defining slots and describing allowed values for these slots, filling in the values for slots for instances.

Fundamental thumb rules
There is no one correct way to model a domain— there are always viable alternatives. The best solution almost always depends on the application that you have in mind and the extensions that you anticipate.

Fundamental thumb rules
Ontology development is necessarily an iterative process. Concepts in the ontology should be close to objects (physical or logical) and relationships in your domain of interest. These are most likely to be nouns (objects) or verbs (relationships) in sentences that describe your domain.

Step 1. Determine the domain and scope of the ontology
What is the domain that the ontology will cover? For what we are going to use the ontology? For what types of questions the information in the ontology should provide answers? Who will use and maintain the ontology?

Example! Consider an ontology which helps representing the best combination (wine/ food). Representation of food and wines is the domain of the ontology. We plan to use this ontology for the applications that suggest good combinations of wines and food. Naturally, the concepts describing different types of wines, main food types, the notion of a good combination of wine and food and a bad combination will figure into our ontology. It is unlikely that the ontology will include concepts for managing inventory in a winery or employees in a restaurant. If it will be used to help restaurant customers decide which wine to order, we need to include retail-pricing information.

Step 1 Example Competency question Which wine characteristics should I consider when choosing a wine? Is Bordeaux a red or white wine? Does Cabernet Sauvignon go well with seafood? What is the best choice of wine for grilled meat? Which characteristics of a wine affect its appropriateness for a dish? Does a bouquet or body of a specific wine change with vintage year?

Step 2. Consider reusing existing ontologies
Sure, if they exist!!!

Step 3. Enumerate important terms in the ontology
What are the terms we would like to talk about? What properties do those terms have? What would we like to say about those terms? Example - wine, grape, winery, location, a wine’s color, body, flavor and sugar content; different types of food, such as fish and red meat; subtypes of wine such as white wine, and so. It is important to get a comprehensive list of terms without worrying about overlap between concepts they represent, relations among the terms, or any properties that the concepts may have, or whether the concepts are classes or slots.

Step 4. Define the classes and the class hierarchy
Methods Top-down: development process starts with the definition of the most general concepts in the domain and subsequent specialization of the concepts. For example, we can start with creating classes for the general concepts of Wine and Food. Then we specialize the Wine class by creating some of its subclasses: White wine, Red wine, Rosé wine. We can further categorize the Red wine class and so on.

Methods Bottom-up: starts with the definition of the most specific classes, the leaves of the hierarchy, with subsequent grouping of these classes into more general concepts. For example, we start by defining classes for Pauillac and Margaux wines. We then create a common superclass for these two classes—Medoc—which in turn is a subclass of Bordeaux.

Methods -Combination: it is a combination of the top-down and bottom-up approaches: We define the more salient concepts first and then generalize and specialize them appropriately. We might start with a few top-level concepts such as Wine, and a few specific concepts, such as Margaux . We can then relate them to a middle-level concept, such as Medoc.

Whichever approach we choose, we usually start by defining classes. From the list created in step3, we select the terms that describe objects having independent existence rather than terms that describe these objects. These terms will be classes in the ontology. We organize the classes into a hierarchical taxonomy by asking if by being an instance of one class, the object will necessarily (i.e., by definition) be an instance of some other class. hierarchical arrangements of concepts: If a class A is a superclass of class B, then every instance of B is also an instance of A. This implies “In other words, the class B represents a concept that is a “kind of” A.” For example, every Pinot Noir wine is necessarily a red wine. Therefore the Pinot Noir class is a subclass of the Red Wine class.

Top-down Food and Wine -- followed by White, Blush and Red Bottom-up define specific wine class first and the work your way up Combination

Step 5. Define the properties of classes—slots
Types of properties “intrinsic” properties such as the flavor of a wine; “extrinsic” properties such as a wine’s name, and area it comes from; parts, if the object is structured; these can be both physical and abstract “parts” (e.g., the courses of a meal) relationships to other individuals; these are the relationships between individual members of the class and other items (e.g., the maker of a wine, representing a relationship between a wine and a winery, and the grape the wine is made from.)

Step 5. Define the properties of classes—slots
We have already selected classes from the list of terms we created in step3. Most of the remaining terms are likely to be properties of these classes. For each property in the list, we must determine which class it describes. Describe the internal structure of concepts. Examples a wine’s color, body, flavor sugar content location of a winery.

Completing slots In addition to the properties we have identified earlier, we need to add the following slots to the Wine class: name, area, maker, grape.

Inheritance All subclasses of a class inherit the slot of that class. For example, all the slots of the class Wine will be inherited to all subclasses of Wine, including Red Wine and White Wine. We will add an additional slot, tannin level (low, moderate, or high), to the Red Wine class. The tannin level slot will be inherited by all the classes representing red wines (such as Bordeaux and Beaujolais). Example: Red wine inherits name, area, maker, grape slots from wine. add an additional slot, tannin level (low, moderate, or high), to the Red Wine class.

Step 6. Define the facets of the slots
Slot cardinality defines how many values a slot can have. Sometimes it may be useful to set the maximum cardinality to 0. Slot-value type what types of values can fill in the slot. allowed values other features of the values the slot can take.

Step 6. Define the facets of the slots
common value types: String Number Boolean Enumerated Instance-type slots allow definition of relationships between individuals. Slots with value type Instance must also define a list of allowed classes from which the instances can come. For example, a slot produces for the class Winery may have instances of the class Wine as its values.

Step 6 - rules slot Domain and Ranges
When defining a domain or a range for a slot, find the most general classes or class that can be respectively the domain or the range for the slots . On the other hand, do not define a domain and range that is overly general: all the classes in the domain of a slot should be described by the slot and instances of all the classes in the range of a slot should be potential fillers for the slot. Do not choose an overly general class for range (i.e., one would not want to make the range THING) but one would want to choose a class that will cover all fillers. We can attach the tannin level slot to each of the classes representing red wines (e.g., Bordeaux, Merlot, Beaujolais, etc.). However, since all red wines have the tannin-level property, we should instead attach the slot to this more general class of Red Wines. Generalizing the domain of the tannin level slot further (by attaching it to the Wine class instead) would not be correct since we do not use tannin level to describe white wines for example.

Step 6 - rules slot Domain and Ranges
If a list of classes defining a range or a domain of a slot includes a class and its subclass, remove the subclass. If a list of classes defining a range or a domain of a slot contains all subclasses of a class A, but not the class A itself, the range should contain only the class A and not the subclasses. If a list of classes defining a range or a domain of a slot contains all but a few subclasses of a class A, consider if the class A would make a more appropriate range definition.

Step 7 - Creating Instances
Body: Light Color: Red Flavor: Delicate Tannin level: Low Grape: Gamay (instance of the Wine grape class) Maker: Chateau-Morgon (instance of the Winery class) Region: Beaujolais (instance of the Wine-Region class) Sugar: Dry

Consistency/validity/sanity checks???
DONE?? Consistency/validity/sanity checks???

Step 8 - Defining classes and a class hierarchy
Ensuring that the class hierarchy is correct An “is-a” relation A subclass of a class represents a concept that is a “kind of” the concept that the superclass represents. A single wine is not a subclass of all wines Transitivity of the hierarchical relations

Evolution of a class hierarchy distinction between classes and their names hence synonyms of concept name do not represent different classes Avoid class hierarchy cycles All the siblings in the hierarchy (except for the ones at the root) must be at the same level of generality.

How many is too many and how few are too few? If a class has only one direct subclass there may be a modeling problem or the ontology is not complete. If there are more than a dozen subclasses for a given class then additional intermediate categories may be necessary. (may not always be possible)

Multiple Inheritance When do you introduce a new class Subclasses of a class usually (1) have additional properties that the superclass does not have, or (2) restrictions different from those of the superclass, or (3) participate in different relationships than the superclasses

Counter example to thumb rule in previous slide Classes in terminological hierarchies do not have to introduce new properties MeSH at NLM National Institute of Health purpose is just to organize for ease of searching/indexing

A new class or a property value? Class White Wine or simply property of class Wine that takes value White Depends on how important a concept White Wine is in the domain An instance or a class? starts with deciding what is the lowest level of granularity in the representation. Individual instances are the most specific concepts represented in a knowledge base.

Step 8 - Limiting the scope
The ontology should not contain all the possible information about the domain: you do not need to specialize (or generalize) more than you need for your application (at most one extra level each way). The ontology should not contain all the possible properties of and distinctions among classes in the hierarchy.

Details Inverse slots Naming conventions Synonyms Defaults
Disjoint subclasses

Next Choose domain IN WHICH YOU ARE EXPERT. Requirements
Identify intended use Show all steps mentioned so far…

References The elements of this presentatiion are obtained from:
Cartic Ramakrishnan, LSDIS Lab, University of Georgia. ASIS KM Website Brint.com Knowledge Portal Knowledge Management Research Center Karl-Erik Sveiby and Knowledge Associates University of Arizona Riichiro MizoguchiSIR, Osaka University Canadian Institutional Research and Planning Association Cartic Ramakrishnan, LSDIS Lab, University of Georgia Ontology Working Group

Pattern oriented software architecture

Definitions Is an original object used to make copies, or a set of repeating objects in a decorative design and in other disciplines. A pattern is a general reusable solution to a commonly occurring problem. A design pattern is a formal way of documenting a solution to a design problem in a particular field of expertise. An organized collection of design patterns that relate to a particular field is called a pattern language.

Definitions The elements of this language are entities called patterns. Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. A design pattern for must be broad enough to be applied to differnet situations, but not so vague that it doesn't help the designer make decisions. The documentation for a design pattern describes the context in which the pattern is used, the forces within the context that the pattern seeks to resolve, and the suggested solution.

Pattern documentation
It contains the following sections: Pattern Name and Classification: A descriptive and unique name that helps in identifying and referring to the pattern. Also Known As: Other names for the pattern (including aliases). Abstract: a short description. Intent: A description of the goal behind the pattern and the reason for using it. Solution: description of the solution. Motivation (Forces): A scenario consisting of a problem and a context in which this pattern can be used. Applicability: Situations in which this pattern is usable; the context for the pattern. Structure: A graphical representation of the pattern. Issues: points to be considered during the implimentation. Trade-Offs: positive and negative side effects on the other aspects.

Pattern documentation
Participants: A listing of the classes and objects used in the pattern and their roles in the design. Collaboration: A description of how classes and objects used in the pattern interact with each other. Consequences: A description of the results, side effects, and trade offs caused by using the pattern. Implementation: A description of an implementation of the pattern; the solution part of the pattern. Sample Code: An illustration of how the pattern can be used in a programming language. Known Uses: Examples of real usages of the pattern. Related Patterns: Other patterns that have some relationship with the pattern; discussion of the differences between the pattern and similar patterns.

Account Lockout

Software design patterns
Design Patterns - Elements of Reusable Object- Oriented Software was written by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides. Design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Grouped into three categories: creational patterns, structural patterns, and behavioral patterns.

Patterns categories In software engineering, creational design patterns are design patterns that deal with object creation mechanisms, trying to create objects in a manner suitable to the situation. structural design patterns are design patterns that ease the design by identifying a simple way to realize relationships between entities. behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns.

Abstract factory Provides a way to encapsulate a group of individual factories that have a common theme. In normal usage, the client software creates a concrete implementation of the abstract factory and then uses the generic interfaces to create the concrete objects that are part of the theme.

Abstract factory Sheet metal stamping equipment is an example of an Abstract Factory for creating auto body parts. Using rollers to change the dies, the concrete class can be changed. The possible concrete classes are hoods, trunks, roofs, left and right front fenders,etc. The master parts list ensures that classes will be compatible. Note that an Abstract Factory is a collection of Factory Methods.

Factory Methods The factory method design pattern centralize creation of an object of a specific type choosing one of several implementations .

Builder pattern The intention is to abstract steps of construction of objects so that different implementations of these steps can construct different representations of objects.

Prototype pattern The Prototype pattern specifies the kind of objects to instantiate using a prototypical instance.

Singleton pattern The Singleton pattern ensures that a class has only one instance, and provides a global point of reference to that instance (At any time, at most one unique instance of the class exists).

Structural patterns Structural patterns ease the design by identifying a simple way to realize relationships between entities. The Bridge pattern decouples an abstraction from its implementation, so that the two can vary independently (Switch). The Adapter pattern allows otherwise incompatible classes to work together by converting the interface of one class to an interface expected by the clients.

Composite pattern The Composite composes objects into tree structures, and lets clients treat individual objects and compositions uniformly.

Composite pattern The composite pattern defines class hierarchies consisting of leaf objects and composite objects. Composite objects are treated the same way as leaf objects (their value is added, subtracted, etc. from another value). With composites, it is easy to add new kinds of components. Composite objects are treated the same way as leaf objects (their value is added, subtracted, etc. from another value).

Decorator pattern The Decorator attaches additional responsibilities to an object dynamically. Adding or removing frames and mattes provide more flexibility than requiring all paintings to have the same frame. Paintings can be customized with the addition of mattes and frames. The cost of customization is determined by the framing and matting options chosen. The decorator and component remain separate.

Facade pattern The Facade defines a unified, higher level interface to a subsystem, that makes it easier to use. When ordering from a catalog, consumers do not have direct contact with the Order Fulfillment, Billing, and Shipping departments. The Customer Service Representative acts as a Facade, or unified interface, to each of the departments involved in the transaction.

Flyweight pattern and proxy pattern
The Flyweight uses sharing to support large numbers of objects efficiently. The proxy introduces a level of indirection when accessing an object. The indirection can be used for security, or disguising the fact that an object is located in a different address space.

Behavioral design patterns
Behavioral design patterns are design patterns that identify common communication patterns between objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this communication. This type of design pattern includes:

The Chain of Responsibility pattern
The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver. A mechanical sorting bank uses a single slot:for all coins. As each coin is dropped, a Chain of Responsibility determines which tube accommodates each coin. If a tube cannot accommodate the coin, the coin is passed on until a tube can accept the coin.

Command pattern The Command pattern allows requests to be encapsulated as objects, thereby allowing clients to be parameterized with different requests. The “check” at a restaurant is used to encapsulate the customer’s order. The written order corresponds to the command. It creates a binding between the cook and the action. The object that invokes the command and the one that performs it are decoupled. Commands can be assembled into composite commands. When several people at a table order on the same check, the command is a composite.

Interpreter and Iterator patterns
The Interpreter pattern defines a grammatical representation for a language, and an interpreter to interpret the grammar. The Iterator provides ways to access elements of an aggregate object sequentially without exposing the underlying structure of the object.

Iterator patterns The channel selector on modern day television sets is an example of an Iterator. Rather than a dial containing all possible channels, or one button per tuned channel, today’s television sets have a Next and Previous button for tuning channels. The “Channel Surfer” doesn’t need to know if Channel 3 or Channel 4 comes after Channel 2.

Mediator pattern The Mediator defines an object that controls how a set of objects interact. Loose coupling between colleague objects is achieved by having colleagues communicate with the Mediator, rather than one another. Constraints are localized within the Mediator. Changes to constraints need only be dealt with in the tower. Interactions are decoupled. The many to many interactions are replaced with a one to many interaction.. Control is centralized. Complexity of interaction is traded for complexity in the mediator.

Memento pattern The Memento captures and externalizes an object’s internal state, so the object can be restored to that state later. It eliminates the need for everyone needs to know an object state ettings to store them inside. Stores the managed information outside of the manging object (i.e. not in his memory).

Observer pattern The Observer defines a one to many relationship, so that when one object changes state, the others are notified and updated automatically. When a bidder at an auction accepts a bid, he or she raises a numbered paddle which identifies the bidder. The bid price then changes and all Observers must be notified of the change. The auctioneer then broadcasts the new bid to the bidders.

State pattern The State pattern allows an object to change its behavior when its internal state changes. Coffee machine!

Strategy A Strategy defines a set of algorithms that can be used interchangeably. Strategies combine families of related algorithms and allow the algorithm to vary independently of the context; The context alone does not dictate which method of willl be used. Strategies offer a choice of implementations.

Template Method The Template Method defines a skeleton of an algorithm in an operation, and defers some steps to subclasses. Templates factor out what is common, so that it can be reused. Multiple elevations can be built from a basic floor plan. The specific elevation does not need to be chosen until later in the process.

Visitor pattern The Visitor pattern represents an operation to be performed on the elements of an object structure, without changing the classes on which is operates. An outside consultant coming into a department, to meet with everyone in the department on a one-onone basis is an example of Visitor. While the visitor is escorted to each room, she does nothing. Once she arrives at an office, she springs into action interviewing the employee (sending messages and obtaining results).

References The elements of this presentation are obtained from:
AG Communication Systems – 1999 Examples to Accompany:Design Patterns Elements of Reusable Object-Oriented Software. Wikipedia.

Information System Architecture

Similar presentations

Presentation on theme: "Information System Architecture"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Information System Architecture

Similar presentations

Presentation on theme: "Information System Architecture"— Presentation transcript:

Similar presentations

About project

Feedback