WebSphere AS Architecture

Three-tier architecture

- Presentation Layer (Client)

- Application Logic Layer

- Network Resources

Packages

WAS-XD improves system availability, maintaining multiple instances of key components so that services can be switched from one server to another.

WAS-EE improve many different aspects of the network's operation. For example, the APIs included in Extended Messaging Support make it easier to deal with incoming asynchronous messages. Other extensions allow you to process query statements at runtime, support interruptible and compensated workflows, and manage transactions better.

WebSphere components

- EJB Container

- Web Container

- Application Client Container

- Applet Container

- Embedded HTTP Server

- Virtual Host (Fence off data, only makeing it accessible to resources installed on the same virtual host)

Support for EJB

- Local, remote, and message-driven beans

- Container-managed relationships and association relationships

- Portable finder query language

- Programming model

- Abstract and Concrete entity beans

- Local Home and Local Entity Interfaces

- EJB query language

Enhancement Features

- Changing semantic behavior

- Entity bean inheritance

- Optimistic concurrency control

- Read-ahead (minimize the number of database roundtrips by retrieving a working set of container-managed persistence (CMP) beans for the transaction within one query)

- Intent mechanism support

- Backend access support

- SQLJ

- Data caching

Enhance CMP performance

- bean data caching

- long lifetime caching

- optimistic currency control

- read-ahead

Activity Session (enables the user to group transactions into work units. You can associate various properties and configurations with an activity session)

Web Services Functionality

- Application lifecycle events

- autoRequestEncoding and autoResponseEncoding

- Classes and servlets

- Filters

- HTTP session support (in-memory, persistent-to-database, memory-to-memory)

Common Object Request Broker Architecture (CORBA) clients can access WebSphere Application Server CORBA C++ servers and WebSphere Application Server EJB servers. WebSphere also provides a basic CORBA environment that can bootstrap into the J2EE name space and invoke J2EE transactions. New support features include SSL security for CORBA C++ clients.

Web Service Support

- XML

- UDDI

- SOAP

- WSDL

Naming Support

- Instead of binding an object, it is bound to the server root context, or a context specific to the server associated with the object.

-Name Server runs in its own process instead of the administrative server's process

Changes to dynamic caching

- caching support (servlet and JSP results caching, command caching, pattern caching, and web services caching)

- dynamic caching engine (disk overflow, Least Recently Used (LRU), mgmt, XML cache policy mgmt, invalidation mgmt, and external cache support for IBM WebSphere Edge and IBM HTP Server Fast Response Cashe Accelerator)

- dynamic network caching (caching is performed within the context of J2EE and caching behavior is described in XML cache policy files)

- dynamic servlet caching (by configuring caching through the cachespec.xml file format)

I18N

- Change Currency

- Change character sets

Application and Service choreography

WebSphere Platform Infrastructure

- node

- configuration repository

- virtual hosts (is not linked to a specific node, it can be created, but cannot be started or stopped)

- admin service

- session database (for multiserver environment)

- scripting client

Network Deployment platform components

- Support multiple nodes. Each node has a node agent component and a number of application servers. These are all run within an administrative unit called a cell, which resides within the Deployment Manager. You can use a Network Deployment cell to configure clusters of load-balanced application servers.

- The Deployment Manager administers the configuration and application binaries of the components in a cell. They are divided out to local copies on each node.

Edge Components offer an efficient and economic means of hosting web-accessible content and providing Internet access. The software typically runs on machines that are in proximity to the boundary between an enterprise intranet and the Internet.

Edge Components include the caching proxy and load balancer, which help administrators to provide improved levels of service to internal and external users with access to documents on enterprise server machines.

A cluster is a logical arrangement of application server processes designed for workload balancing. Application servers that are part of a cluster are "members" of that cluster and must have identical application components deployed on them. Cluster members are not required to share any configuration data.

Cluster members can be situated on a single node (vertical cluster), over a number of nodes (horizontal cluster), or a mixture of the two.

Managed Servers or Processes

- Deployment Manager (Network Deployment Only)

- Node Agent (Network Deployment Only)

- Application Server (Base and Network Deployment)

- JMS Server (Network Deployment Only)

Network Deplyment

- Multiple WAS instances

1. Application Servers (multiple instances from a single installation of WAS)

2. Deployment Manager (multiple instances from a single installation of Network Deployment)

- Multiple server instances using a single installation (It is possible to configure multiple Deployment Managers for a single Network Deployment installation but these Deployment Managers are incapable of providing mutual failover or clustering support)

- Coexistence of WAS and ND

- Disadvantage: if something happens to either the WebSphere Application Server or Deployment Manager that results in the reconstruction of the node, the other component needs to be relocated

- A Single web server for coexisting, multiversion application servers on one machine

- A Single web server for multiple instances of WAS

- Standalone web servers for each application server instance when running multiple instances of WAS

Topology Considerations

- Availability (Horizontal scaling, Vertical Scaling, IP sprayer)

1. Hardware and process redundancy

2. Process Isolation

3. Load balancing

4. Failover support

5. Hardware-based high availability

- Maintainability (Inherent considerations for updating system hardware and software. Maintainability can clash with other topology considerations and can lead to shortcomings in throughput, performance, and availability)

- Performance

1. Vertical scaling: provision of software/application server failover as well as load balancing over a number of JVM application server processes. It enables an administrator to examine an existing application server for performance holdups.

2. Horizontal scaling: Creation of extra application server processes on multiple physical machines, harnesses additional processing power from each machine. This provides hardware failover support, and an administrator can apportion implementation costs among multiple physical machines.

- Security (A recommended security configuration is to use two firewalls to create a demilitarized zone (DMZ). Information in the DMZ is somewhat protected due to protocol filtering between the Internet and the DMZ. A web server can intercept requests and direct them through the next firewall. The vulnerable application and business data elements exist intthe space behind the second firewall, which filters by IP address or domain)

- Session Management

1. Database persistance

2. Memory-to-Memory Replication (replication of session data between the memories of individual application server JVMs. WebSphere internal Messaging is a JMS publish/subscribe mechanism that provides assured session replication between the JVM processes. It does this by leveraging the internal JMS provider provided with WebSphere Application Server and so a database product is not essential for persistence.

- Scalability (Configure multiple machines to boost processing power, enhance security, maximize availability, and balance workloads)

1. WebSphere Application Server cluster support

2. WebSphere workload management (WLM) (in front of clustering)

3. IP sprayer (Redirects incoming HTTP requests transparently from web clients to a group of web servers. Intercepts all requests and disseminates them to the full range of web servers in the group. IP sprayers such as Cisco Local Director provide scalability, load balancing, and failover for web servers)

Topology Terminology

1. Web Presentation Server Node

2. Database Server Node

3. Domain and Protocol Firewall Nodes

4. Directory and Security Services Node

5. Web Application Server Node

6. Web Server Redirector node and application server Node

7. Load Balancer Node

8. Deployment Manager

Supported Network Topologies

1. Vertical Scaling (multiple app server instances on a single machine)

2. HTTP server separation

2.1 Supporting Network Address Translation (NAT) firewalls

2.2 Preventing data access from DMZ

2.3 Underpinning load balancing and failover

2.4 Simplifying administration

2.5 Alleviating congestion

2.6 Supporting Secure Sockets Layer (SSL) encryption

3. Reverse Proxy (resides in DMZ and forwards traffic to and from a web server, which now resides on the same machine as the application server)

4. Multi-Tiered (Divides the application server processes into servlet application servers (close to HTTP server) and EJB application servers (close to application data). This is beneficial from security and performance perspectives)

5. Horizontal Scaling with Clusters

6. Horizontal Scaling with IP Sprayer

Simple IP Sprayer

Complex IP Sprayer

7. Multiple WebSphere cells

Advantages

1. Isolates hardware and software failure

2. Prevents outages

3. Improves Performance

8. Multiple Clusters on a node

Advantages

1. Enhanced throughput

2. Improved performance

3. Hardware failover

4. Application software failover

5. Process isolation

9. Combined

- Two WebSphere cells

- Two load balancer nodes

- Two HTTP servers for each cell with the web server plug-in

- Four application server machines for each cell

- The use of application server clusters for both vertical and horizontal scaling

- Two database servers for each cell, which host mirrored copies of the application database

Web Service Architecture and Models

Web Services Entities
- Provider Agent
- Requester Agent
- Discovery Service

Web Service Architecture Stack


Web Service Models



Service Oriented Model


- Is Concerned with the service provided and the actions necessary to provide it. A service is realized by an agent and used by another agent. Services are mediated by means of the messages exchanged between requester agents and provider agents. A service offers real-world functionality and is owned by a person or organization


Resource Oriented Model


- Is concerned with resources that are available over the Internet. The owners of a resource are responsible for ti. The resource-oriented model specifies the relationship between owners and resources


Policy Oriented Model

- Is concerned with constraining how agents and services behave. Policies are implemented to address concerns about quality of service, security, application, and management.


Message-Oriented Model


- Is concerned with the messages that are exchanged by web service agents. It focuses on their structure and how they are transported. It is not concerned with their significance.


Message Exchange Patterns
- request-response
- one-way request (from requester)
- notification (from provider)
- solicit-response (provider to requester and back)


SOA Roles
- Service Requester
- Service Provider
- Service Register


SOA Operations
- Publish
- Find
- Bind


Web Service Design Stages
- Vision document
- Conceptual Design
- Logical Design
- Physical Design
- Architecture (how to connect and installed)
- Security Design (Authentication, Privacy, Authorization)


Web Service Design Options
- Synchronous or asynchronous Communication
- Session State
- Transactions (actions in a group. Time-stamped data to enable rollback across independent web services)
- Caching (expiration time must be set)

Federal Enterprise Architecture Framework V1.1

National Institute of Standards and Technology (NIST) model
The NIST model has been promoted within the Federal Government as a management tool that illustrates the interrelationship of enterprise business, information, and technology environments. The five-layered model allows for organizing, planning, and building an integrated set of information and information technology architectures.

Purpose
. Organize Federal information on a Federalwide scale
. Promote information sharing among Federal organizations
. Help Federal organizations develop their architectures
. Help Federal organizations quickly develop their IT investment processes
. Serve customer needs better, faster, and cost effectively

Value
. Promote Federal interoperability
. Promote Agency resource sharing
. Provide potential for Federal and Agency reduced costs
. Improve ability to share information
. Support Federal and Agency

Framework Components

1. Architecture Drivers

2. Strategic Driection

3. Current Architecture

4. Target Architecture

5. Transitional Processes

6. Architectural Segments

7. Architectural Models

8. Standards

Pinnciples
1. Standards: Establish Federal interoperability standards.

2. Investments: Coordinate technology investments with the Federal business and architecture.

3. Data Collection: Minimize the data collection burden.

4. Security: Secure Federal information against unauthorized access.

5. Functionality: Take advantage of standardization based on common functions and customers.

6. Information Access: Provide access to information.

7. Proven Technologies: Select and implement proven market technologies.

8. Privacy: Comply with the Privacy Act of 1974.

Federal Enterprise Architecture Framework, Level I

(the view from 20,000 feet)

Federal Enterprise Architecture Framework, Level II

(the view from 10,000 feet)

Federal Enterprise Architecture Framework, Level III
(the view from 5,000 feet)

Federal Enterprise Architecture Framework, Level IV

(the view from 1,000 to 500 feet)

The Zachman Framework

Enterprise Architecture Planning (EAP)

is a "how to" approach for creating the top two rows of the Zachman Framework, Planner and Owner

Design Architectures

TOGAF

TOGAF = The Open Group Architecture Framework

What kind of architecture does TOGAF deal with?
– Business Architecture - this defines the business strategy, governance, organization, and key business processes
– Data Architecture - this describes the structure of an organization's logical and physical data assets and data management resources
– Applications Architecture - this provides a blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization
– Technology Architecture - this describes the logical software and hardware capabilities that are required to support the deployment of business, data, and application services

What it is

(TOGAF)
• Generic
• Process Driven
• “One size fits all organizations”
• Flexible
• Set of Conceptual Tools
• Providing generic deliverables

(ADM)
• A step-by-step approach to developing an enterprise architecture
• Method - a way, technique, or process of or for doing something
• Process - a series of actions or operations towards an “end”

What it is Not

(TOGAF)
• Prescriptive and HOW to Customize the Framework
• Prescriptive and Artifact driven
• Specific to company size or to an industry
• Ontology Driven
• Tool
• Prescribing a specific set of deliverables
(ADM)

• The whole TOGAF
• Framework
• Chair in an ivory tower
• Quick & easy

TOGAF

Architecture Development Method

Enterprise Continuum
A virtual repository of all architecture assets
– Models, patterns, architecture descriptions
– Deliverables produced in this iteration of the ADM
– Deliverables produced in other iterations of the ADM
– Assets from the industry at large

• TOGAF provides two reference models for possible inclusion in an organization’s Enterprise Continuum
– The TOGAF Foundation Architecture
– The Integrated Information Infrastructure Reference Model

Resource Base

A set of resources, guidelines, templates, background information etc..
• For reference during application of the ADM
• Covers a broad range of topics used to develop an architectur

Enterprise Architecture Life Cycle (EALC)

The Strategic Alignment Model (Enterprise Value)

Preliminary Phase: Framework & Principles

Phase A: Architecture Vision

Phase B: Business Architecture

Phase C: Information Systems Architectures

Phase D: Technology Architecture

Phase E: Opportunities & Solutions

Phase F: Migration Planning

Phase G: Implementation Governance

Phase H: Architecture hange Management

Requirements Mnagement

Data Model Analysis Styles

Data Models
- Conceptual: The highest-level beginning place
- Logical: The most important model for developing a good physical design
- Physical: The most detailed model that’s the source of the DDL to generate database objects
- Reverse engineered: A Physical model that shows the As-Is of a deployed database

Top-Down Modeling
A top-down approach to the modeling of a system will begin with a Conceptual model and work down through a Logical model to a Physical model for implementation. This process documents details regarding the conceptual entities that you begin with, breaking out attributes and relationships as you progress toward a Physical model.

Bottom-up Modeling
Sometimes you have to work with a bottom-up approach, working backward from an existing system, in order to develop a Logical model (and sometimes further back to a Conceptual model). This type of approach is reverse-engineering analysis.

Levels of detail
At each of these stages of analysis, you can choose the level of detail you display in the model you develop.

- Entity level: This is a high level of detail used for scope and planning or a simplified review at the beginning of a project. It shows only entities and attributes.
- Key-based: This is an intermediate level of detail, which includes entities and primary key attributes (usually natural keys if possible).
- Fully attributed: This is the most detailed level of analysis. All attributes are listed, including all foreign keys migrating from the parent table.

It’s important to use the appropriate type of model and level of detail and to tailor the model to the needs of your particular situation. You’ll consider the scope of projects in the next chapter.

The Right Model
Data models go through similar maturing and iteration processes as a full project. At the height of a project you’ll be moving rapidly between different models, from Conceptual to Logical to Physical and back to Logical, as you find out that there are exceptions to the business rules that the clients didn’t mention earlier.

Project Type
The type of project will help you narrow down the analysis level of the models. Enterprise-level projects, for instance, almost never need Physical models, but transactional OLTP projects could use all three analysis levels.

Model Deliverables for Different Project Types
Enterprise
Conceptual

Transactional
Conceptual, Logical, Physical

Dimensional or data warehouse
Conceptual, Physical

Model Goal
Your task helps you decide analysis level as well. If you want a high-level overview of the data system, or to play with new ideas or ways of organizing things, then you’ll need to build a Conceptual model. On the other hand, if you want to analyze business rules and analyze data elements, then you’ll need to build a Logical model. If you already know everything there is to know about the rules of the data elements and need to design tables, then you’ll want to build a Physical model.

Model Deliverables Expected by Model Goal
Abstract
Conceptual

Analysis
Conceptual, Logical

Physical design
Physical

Customer Need
Now you need to determine who will be your customer in order to decide what level of definition you need. If your customer is someone who wants a general rundown of the data involved in the project, then you want an entity-level model. If you’re working with someone who is concentrating on integration opportunities or key design choices, then you need a key-based view of the model. If the customer is someone who needs to see all the gory details, then you want a fully attributed model.

Model Level of Detail Deliverable Expectation by Customer Need
Overview
Entity

Focused identifier/uniqueness
Key based

All the details
Fully attributed

Choose one option from these three ways to narrow the definition of your product, and you’ll see what model you need to build. The following maps the combinations of ideas that focus the product definition of a model.

Deliverable Needs Combined to Focus on What Model Should Be Built
(Project Type, Model Goal, Customer View Need, Analysis Level, Level of Definition)
Enterprise
Abstract
Overview
Conceptual
Entity level

Transactional
Abstract
Overview
Conceptual
Entity level

Transactional
Abstract
Overview
Conceptual
Fully attributed

Transactional
Analysis
Overview
Logical
Entity level

Transactional
Data element analysis
Focused identifier/uniqueness
Logical
Key based

Transactional
Data element analysis
All the details
Logical
Fully attributed

Transactional
Physical design
Focused identifier/uniqueness
Physical
Key based

Transactional
Physical design
All the details
Physical
Fully attributed

Data warehouse/enterprise reporting
Abstract
Overview
Conceptual
Entity level

Data warehouse/enterprise reporting
Data element analysis
All the details
Logical
Fully attributed

Data warehouse/enterprise reporting
Physical design: normalized or dimensional
Focused identifier/uniqueness
Physical
Key based

Data warehouse/enterprise reporting
Physical design: normalized or dimensional
All the details
Physical
Fully attributed

Note: Remember that if the model doesn’t communicate what you’re trying to get across to your audience, then it’s useless.
These are still just high-level definitions of what’s on a model and the details that show up. You have an almost unlimited set of choices, especially if you’re using one of the modeling software packages. Making these choices just helps you narrow down what kind of model you’re building and therefore what your checklist of information is. You still need to be aware of the level of understanding (rather than what they want to know) of your model customer, the needs of the project, and any methodology or external standard.

Model Tips
The following is a list of things you should keep in mind when modeling:
- Picking the level of analysis and detail of a model depends on many factors.
- Staying within scope is a challenge.
- Being wrong on a model can be a good thing. It stimulates discussion.
- There is no “one right” model. The models serve different purposes. Not all of them are schematics for databases.
- Sometimes the “correct” solution isn’t the best solution for the enterprise.
- Models are products and have customers. Be customer oriented.
- Stay objective. Feedback for designs or analysis is meant to enhance, not criticize.
- Finding a way to keep the team in sync with each other at every model iteration requires a creative publish and deploy mechanism.
- Every model you build helps you build the next one.
- You’ll need a second pair of eyes to look for your mistakes. You can be too close to see them.
The primary goal of your work is to create a model that your audience can understand. The “perfectly designed” model may not be consumable by your customers. Also, work with your audience to encourage them to think of better ways of doing things; sometimes resistance isn’t because of a failure of design but because of the comfort level of your customers.

Building a Conceptual Model
Defining the Objectives – 20 – 80 rule
What are you trying to accomplish in building a Conceptual model? In this example, you’re going to draw a picture that portrays the data scope of a business process. You’re also going to refine and clarify all the individual descriptions of a process until it’s distilled into a single truth (or as close as you can get to it). To do that, you need to do the following:
- You should become informed enough to explain and defend the discoveries you make.
- You should learn the vocabulary of the process and its surroundings as the business sees it.
- You should identify the concepts or data elements, and determine the rules that govern them.
- You should validate the scope.
- You should build a Conceptual ER model.

Defining the Scope
Defining the Approach
- Top-Down Approach
- Bottom-Up Approach

Documenting the Process

Building the Conceptual Model

Building a Logical Model

Understanding OLAP Database Basics
The main difference between a data mart and a data warehouse is this: a data mart is intended to store a single snapshot of the business data, and the data warehouse will contain more than just a single point-in-time snapshot. A data mart is usually intended to be exposed to query tools or decision support applications and therefore usually follows a Dimensional model design. A data warehouse may have a Third Normal Form (3NF) design or a Dimensional model design, depending on its purpose within the enterprise. If a data warehouse has a 3NF design, it’s likely to feed dependent data marts and therefore is infrequently accessed. If the data warehouse has a Dimensional model design, it may be supporting an OLAP query tool or application directly. It’s important to note that the terms data mart and data warehouse generally describe a database’s use rather than imply a Physical model design.

Data marts generally have the following characteristics:
- They have a Dimensional model design.
- They’re accessed by OLAP (business intelligence) tools or an OLAP application.
- They contain a single point-in-time snapshot of data.
- They’re periodically refreshed from a source system (usually a data warehouse).
- They don’t have other dependent OLAP databases.

Data warehouses generally have the following characteristics:
- They have either a Dimensional model design or a normalized design.
They’re infrequently accessed by any process that isn’t an extraction, transformation, and loading (ETL) process, unless they have a Dimensional model design.
- They contain a time variant and historical view of the data.
- They’re periodically refreshed from a source system (usually source OLTP systems).
- They have dependent data marts.

Dimensional Modeling
It’s a methodology for modeling data that starts from a set of base measurement events and constructs a table called the fact table, generally with one record for each discrete measurement. This fact table is then surrounded by a set of dimension tables, describing precisely what’s known in the context of each measurement record. Because of the characteristic structure of a Dimensional model, it’s often called a star schema. Dimensional models are the logical foundation of all OLAP systems.
The key to a Dimensional model is in determining the relevant context (or face). A Dimensional model that’s designed to find trends in sales information will likely treat each sale as a fact. Any supporting information important to that analysis, such as the country of sale or the month of the year, will be a dimension.

Enterprise Master Data Management (MDM)

Introduction
•Goal: Single place where all common master data in an organization is stored and managed. The data would be accurate, consistent, and maintained in a coherent and secure manner.
•Provides a consistent understanding and trust of master data entities
•Provides mechanisms for consistent use of master data across the organization
•Is designed to accommodate and manage change

Why MDM
•Cross-LOB Perspective (Investments, Loans, Deposits; sees data as critical to operations, not see value in sharing)
•Cross-Channel Perspective (dist. Channel- Partner, Internet, Branch; different solutions->account-centric->customer centric))
•Cross-Business Subdomain Perspective (Case history, Contact preference, Party; different scope)
•Cross-Application/Technology Perspective (packaged apps; variance in technoical platform
•Mergers and Acquisitions

MDM System
•Master Data Domains – Recognition of CDI and PIM. Three primary domains: party, product and account
•Methods of Use – Collaborative Authoring (users & systems to reach agreement), Operational (providing stateless services), Analytical (trusted data source, key function or analytics)
•System of Record (read-only) vs. System of Reference
•Consistency of Data – Absolute Consistency (consistent all the time), Convergent Consistency
•Implementation Styles – Consolidation Implementation (gold source); Registry Implementation (for read-only); Coexistence Implementation (master in many locations); Transactional Hub Implementation.
•Categorizing Data – Metadata, Reference Data, Master Data, Transaction Data, Historical Data

Collaborative MDM (New Product Introduction example)
•1. Receive Notification of New Item
•2. Create Draft Item
•3. Classify Item and Assign SKU
•4. Define Item Properties
•5. Define Marketing Properties
•6. Assign Item to Locations
•7. Define Finance Properties
•8. Approve Product Definition

Operational MDM (OLTP)- New Account Opening
•1. RECORD Arrangement Request
•2. ANALYZE Customer RElationship
•3. ANALYZE Arrangement Request
- APPLY Product Policy
- APPLY Credit Rating Scale
- FORECAST Arrangement Risk
- OFFER Arrangement

Implementation Style
•Consolidation
•Registry
•Coexistence
•Transactional Hub

Data Category
•Metadata
•Reference data
•Master Data
•Transactional Data
•Historical Data

Business Benefits of MDM
•Consistent Understanding and Trust of Master Data Entities – Accuracy, Completeness, Consistency, Timeliness, Relevance, Trust
•Consistent Use of Master Data Across the Organization – Cost Savings and Efficiencies, Regulatory Compliance
•Accommodate and Manage Change – Reducing Time to Market, Revenue Enhancement and Other New Opportunities, Ability to Rapidly Innovate, Product or Service Innovation, Process Innovation, Market Innovation, Supply Chain Innovation, Accommodating Mergers and Acquisitions, Introduction of New Requirements

An SOA Enabler (SOA Architecture)
•Layer 1 – Consumers
•Layer 2 - Business Process (Composition, Choreography, Business State Machine, Orchestration)
•Layer 3 – Services (atomic and composite)
•Layer 4 – Service Components
•Layer 5 – Application Services
•Layer 6 – Data Repositories & Information Services
•Layer 7 – Integration (Enterprise Service Bus)
•Layer 8 – Quality of Service (Security, Management, Monitoring)
•Layer 9 - Governance

Characteristics of SOA services (also for MDM)
•Service reuse
•Service granularity
•Service modularity and loose coupling
•Service composability
•Service componentization and encapsulation
•Compliance with standards (both common and industry-specific)
•Services identification and categorization
•Provisioning and delivery
•Monitoring and tracking

Information as a Service: Characteristics
•Definition – The structure and the semantics of the information needs to be well defined and commonly available
•Quality – integrity of the data needs to be ensured for retrieval and update
•Governance – Changes to the service and the underlying information need to be governed in a uniform and consistent manner

MDM Reference Architecture
•Conceptual Level
•Logical Level
•Physical Level

Architecture Pattern
•Process-Focused Application Integration (integration of applications)
•Information-Focused Application Integration (synchronize master data among MDM hub and underlying legacy systems)
•MDM Hub Patterns (style of MDM deployment)

MDM Ref – Key Functional and Technical Capabilities
•Master Data Lifecycle Mgmt Capability – from created to no longer required; group and define hierarchies; flexible mapping; define master data hierarchies, relationships, groupings; versioning; model multiple taxonomies; authoring; security; audit;
•Data Quality Mgmt Capability – analysis & profiling; standardization, data validation, data cleansing logic; Data reconciliation; data governance; measure the staleness of data
•Master Data Harmonization Capabilities – Integration (messaging, service invocation, batch, ETL, FTP); error-handling; support high-volume transaction
•Analysis and Insight Capabilities – discover insightful relationships; improve business decision; access structured and unstructured information; manage the state of a process; configure event management services

Conceptual Architecture
•Framework to manage and maintain master data
•Scalable, highly available, adaptive architecture
•Coordinate, manage the lifecycle of master data across the enterprise
•Accurate critical business information available as a service
•Cleanse data, improve the quality and consistency of master data
•Make master data active by detecting events and generating operations to manage master data
•enable the ability to implement solutions

MDM Solution – Key architecture building blocks
•Third-Party Data Service Provider
•Process Manager to choreograph
•Connectivity and Interoperability Layer
•MDM Services and Master Data Repository
•Information Integration Services
•Identity Analytics

MDM Solution – Architecture Principles
•Provide ability to decouple information from app & process
•Available as a strategic asset for enterprise
•Authoritative source for master data (manage integrity, control distribution in a standardized way)
•On an architectural framework and reusable services
•Based on industry-accepted open computing standards
•Provide flexibility to accommodate changes
•Highest regard for preserving the ownership of data, integrity and security of data
•Ability to incrementally implement a MDM Solution

MDM – Logical Architecture Components
•Interface Services
•Lifecycle Management Services
•Hierarchy and Relationship Mgmt Services
•Master Data Mgmt Event Mgmt Services
•Authoring Services
•Data Quality Mgmt Services
•Base Services
•Master Data Repository

MDM – Information Risk Analysis
•Identifying the information assets
•Assigning value to each asset
•Identifying each asset’s vulnerabilities and associated threats
•Calculating the risk for the identified assets
•Evaluating different countermeasures in terms of costs and reduction of risk they provide
•Recommending the appropriate countermeasures

MDM – Security and Privacy: Types of IT Risks
•Operational risks – failures in business process; denial of service attack;
•Regulatory and Compliance risks – meet business processes; adequately protecting sensitive data
•Reputational Risks -

MDM – Information Risk Management
•Risk Analysis for MDM
•Security Control Selection and Implementation

MDM – Identifying MDM Assets
•Sources of master data
•Master data itself
•Consumers of master data
•Other related assets

MDM – Security Consideration
•Policy
•Confidentiality
•Integrity
•Identity
•Authentication
•Authorization
•Audit
•User Registry
•Identity provisioning
•Identity token
•Identity mapping
•Identity Propagation
•Reverse Proxy

MDM – Security Considerations
•Identity Propagation, Mapping & Provisioning – Business (Trust Mgmt, Identity and Access (Authorization) Mgmt); Technical (Identity & Authentication Service, Policy Mgmt)
•Authorization – Business (manage identities, roles and groups); Technical (standards-based to handle specifying, distributing & enforcing authorization policies.
•Audit – Business (comply with policies & reports illustrating how well relative to policies; Technical (audit events, real-time and post-processing events reporting
•Data Protection – Business (describe business object level how master data should be protected); Technical (encryption, SSL, WS-Security)

Logical SOA Security Architecture
•Business Security Services tier
•Security Policy Mgmt tier
•IT Security Service tier

Security Enablers
•Cryptography
•Key Management
•Hardware key Storage
•Cryptographic Hardware
•Malware Protection
•Isolation
•Firewalls
•Intrusion Detection
•Intrusion Prevention
•Time
•Security Event and Incident Mgmt (SEIM)

Policy Management
•Policy abstraction level
•Policy management lifecycle
•Policy Domains

Identity propagation
•Security Token Service (STS)
•SAML token for security token format

Authentication Services
•WS-Trust Security Token Service (STS)

Authorization Services
•Service Consumer
•MDM SOA Services Layer
•MDM Services Implementation
•Master Data Repositories

Oracle Application Server 10g Corporate Portal

Overview
•Browser-based environment for building, deploying, and maintaining enterprise portals
•Secure and manageable framework
•Organized and personalized views
•Self-service Web publishing
•Manageable deployment architecture

Oracle Application Server Components
•Oracle Internet Directory (OID)
•OracleAS Portal (OC4J)
•OracleAS Wireless
•OracleAS Web Cache
•OracleAS Personalization
•OracleAS Integration

Grid Computing

Architecture that pools large numbers of servers and storage into a less expensive, flexible, on-demand computing resource for all enterprise needs

- Standardize low cost components

- Consolidate shared resources

- Automate management operations

OracleAS 10g portal Solution
•Content management (Classify content, Navigate and access content; Route content for review and approval)
•Content display (Create, organize, and manage pages; Build and customize dynamic portlets
•Content integration (integrate applications and disparate data by using built-in functionality, including Web Clipplig, OmmiPortlet, and Portlet Builder

Major User Roles in OracleAS Portal

- Page designers

- Content contributors and content managers
- Portlet developers

- Portal administrator

Portal Page Modes

•Page group – Root page; Subpages
•View mode; Graphical mode; Layout mode; List mode

Adding Content to Portal
Item
•An item is a basic unit of content on a portal page.
•Two kinds –
•Content item type
•Navigation item type

Content item types
•File and Simple File
•Simple Image
•Image and Simple Image Map
•PL/SQL and Simple PL/SQL
•Prge Link and Simple Page Link
•Text and Simple Text
•URL and Simple URL
•Zip File

Item-Related Features
•Versioning
•Item-level security
•Document control
•Publishing dates
•Expiry dates
•Approvals

Adding Items

Accessing the Document Library by Using a WebDAV Client

With a WebDAV client, you can:

- Move content, files, and folders between your desktop and the document library

- Open, edit, and save file type items "in place" by using desktop application

Content Metadata
•Data about the content in the document library
•Set explicitly or implicitly
•Made up of three main components (Attributes; Categories; Perspectives)

Classifying Content in OracleAS Portal
•Category – A predefined attribute that is used to group or classify pages, items, and portlets

Creating Category

•Perspective – A cross-category grouping of items and pages (attributes)

- Further classify content across categories

- Enable users to view related content classified in different categories

Creating Perspectives

Implementing Custom Types

Custom Types
•Custom types are unique types you create to extende the standard type definitions provided by OracleAS Protal.
•Custom attributes – User-defined attributes based on predefined data types created to store additional info about an item. (used in definition of custom item types and page types)
•Custom item types
•Custom page types
•[Item Type]n-n[Attribute]n-n[page type]

Creating Custom Item Types

Approval Process

A Series of one or more approval routing steps

- Each step must have one or more approvers

- Routing to approvers can be in serial or in parallel

Portal Page

•OracleAS Protal object that contains portlets and items.
•A portal page is the face of the portal – that which the user interacts with to access informatipn and applications. The layout of a portal page is defined through regions
•A portal page combines the features of a directory folder and a browser page.Like a folder, a page can exist within a hierarchy of pages and can contain content.

Page Group

•A page group is a hierarchical collection of pages for which common attributes and mechanisms can be established to govern the behavior of the pages it contains.
•Consider – (Administering page groups; Managing content metadata; managing content presentation; Copying and moving content)
•Region – rectanglar area on a page used to define the page layout (Types: Item; Portlet; Sub-Page Links; Undefined)

Shared Objects

•Layout and appearance (Styles; Templates; Navigation pages)
•Content attribution (Custom page types; Custom item types; Custom attributes; Perspectives; Categories

Style

•Set of values and parameters that controls the colors and fonts that are used by pages and regions within a page

Page template
•An object that enforces an standard layout and appearance for multiple pages

Navigation Items

•Portal Smart Link

•Login/Logout Link

•Basic Search Box

•List of Objects

•Portal Smart Text

•Object Map Link

•Page Path

•Page Function

Page parameters

•Synchronize portlets residing on a page

•Enable the reuse of portlets on multiple pages with no additional coding

•Provide users the means to customize pages based on their input values

Portlet parameters

•Enable the portlet developer to declare a public data input interface for the page designer to use

•Give the page designer control over the input data to the portlet

Integrating Page and Portlet Parameters

Controlling Access to Page Groups

Controlling Access to Pages

Item-Level Privileges

•Manage

•Edit

•View

Accessing Portal Objects by Using Direct Access URLs

Web Clippling

A piece of existing Web content that can be repurposed in other Web pages, particularly portals.

OmniPortlet

A feature of Oracle AS Portal that enables you to quickly and easily publish data from various data sources and render the result in a variety of formats.

Supported data sources

•Spreadsheet

•SQL

•XML

•Web Service

•Web Page

Supported Data formates

•Tabular

•Chart

•News layout

•Bulleted list

•Form

Data-Driven Portlets (DB, SQL etc)

OracleAS Portal Forms

•Forms based on tables and views

•Master-detail forms based on two tables or views

•Forms based on stored procedures

OracleAS Poprtal Reports

Publishing Business Intelligence on a Portal Page

OrcleAS Discoverer provides two types of portlets

•List of Database Workbooks portlet: Contains the names and links to Discoverer workbooks

•Worksheets portlet: Enables you to place actual worksheetcontent on the portal page

Privileges

- Global privileges

- Objectr-level Privileges

- The corresponding global privilege overrides an object-level privilege