architecture in it outlinearchitecture in it architecture conceptually as opposed to the description...

Architecture in IT

Outline

Challenges of Electronic Business

Specification Approaches

Commitments

Architecture in IT

Contracts and Governance

XML Concepts and Techniques

XML Modeling and Storage

Summary and DirectionsMunindar P. Singh (NCSU) Electronic Commerce Technologies Spring 2012 82 / 345

http://courses.ncsu.edu/csc513/lec/001/

Architecture in IT

Architecture in ITIn the sense of information systems

I Important themesI Conceptualizing architectureI Enterprise architecturesI Tiered architecturesI Architecture as a basis for governance (next section)

I Not quite the same as conventional software architecture, though thetopics are converging

Munindar P. Singh (NCSU) Electronic Commerce Technologies Spring 2012 83 / 345


Architecture in IT

Architecture ConceptuallyAs opposed to the description of a system via a blueprint

I How a system is organizedI An over-used, vaguely defined term

I Software architectureI Standards, e.g., Berners-Lee’s “layer cake” and the networking

standardsI May include processes

I That exercise the systemI By which the system is built and maintainedI By which the system is administered

I May include human organizations



Architecture in IT

Understanding Architecture: 1Conception and description of a system

I Two main ingredients of a systemI What: ComponentsI How put together: Interconnections

I Openness entails specifying the interconnections cleanlyI Physical components disappearI Their logical traces remain

I Information environments mean that the interconnections areprotocols



Architecture in IT

Exercise: Examples of ArchitectureIdentify the main components and interconnections

I Buildings

I Plumbing

I Power systems



Architecture in IT

Understanding Architecture: 2

I Components and interconnections are not sufficient to characterize anarchitecture

I Two additional ingredients go into an architectural styleI Constraints (hard requirements) on the components and

interconnnectionsI Patterns involving the components and interconnnections

I Openness entails the constraintsI Do not apply on the physical components directly



Architecture in IT

Exercise: Examples of ArchitectureIdentify the main constraints and key patterns

I Buildings

I Plumbing

I Power systems



Architecture in IT

Understanding ProtocolsProtocols encapsulate IT interactions

I Interconnections over which information is the main thing that flowsI Connect: conceptual interfacesI Separate: provide clean partitions among logical components

I Wherever we can identify protocols, we canI Make interactions explicitI Enhance reuseI Improve productivityI Identify new markets and technologies

I Protocols yield standards; their implementations yield products



Architecture in IT

Examples of Logical Architectural ComponentsEach logical component class serves some important purpose

I Power: UPS

I Network connectivity

I Storage: integrity, persistence, recovery

I Policy management

I Decision making

I Knowledge and its management

What are some products in the above component classes?



Architecture in IT Enterprise Architecture

OutlineChallenges of Electronic Business


Commitments

Architecture in ITEnterprise ArchitectureTiered ArchitectureWeb ArchitectureMiddlewareDeployment Architecture




Summary and Directions




IT Architectures

The term architecture is used more broadly in IT settingsI The organization of an IT system

I Bad usage: the implementation of a system

I The extensibility and modifiability of a systemI Versus the system having no discernible structure

I Even the governance of a system, which inevitably accommodates thehuman organization where the system is deployed




IT and SOA GovernanceThe human administration of an IT system

I IT Governance: How IT resources are administered

I SOA Governance: How services are created, deployed, removed, . . .I Goes hand-in-hand with architecture

I IncorporatesI The stakeholders (human organization) of a systemI The processes through which a system is updated or upgradedI Nontechnical aspects, such as flows of responsibility

I Sometimes confused with architecture, but distinct




Governance in the Resource Life CycleKey determinations

I Identifying a need is inherently creative

I Developing might involve merely configuring a COTS toolsuite




Exercise: Consider Kleenex Tissue Boxes in the GraduateProgram Area




Enterprise Models: Information ResourcesCapture static and dynamic aspects

I Static: snapshot of the enterprise’s resourcesI Databases and knowledge basesI Applications, business processes, and the information they create,

maintain, and use

which through explicit representations enableI Dynamic: ways to add or modify enterprise resources

I Integrity validationI ReusabilityI Change impact analysisI Software engineering: Automatic database and application generation

via CASE tools




Enterprise Models: Rationales

I Capture (human) organizational structureI Document business functions

I Rationales behind designs of databases and knowledge basesI Justifications for applications and business processes




Enterprise Architecture ObjectivesEnable governance to support the business objectives of the enterprise

I Accommodating change by introducing new instances and types ofI UsersI Ways of interaction (e.g., ongoing push toward mobility)I Applications

I Administering information resourcesI Preserving prior investments by interoperating with legacy systemsI Upgrading resources

I Developing blueprints to guide resource and application installationand decommissioning




Exercise: Creating a Web Interface for the State HealthCare System for the Public




Enterprise Architecture Observations

I IT is usually not a profit centerI Continual squeeze on IT resources

I Demand for rapid development and deployment of applicationsI Demand for greater return on investment (ROI)

I Essential tension, involving stakeholders (users and suborganizations)I Empowerment ensures satisfaction of their needsI Ad hoc approaches complicate interoperability and governance




Enterprise Architecture PrinciplesBusiness processes should drive the technical architecture

I Define dependencies and other relationships among stakeholders(including users) and suborganizations of an organization

I Message-driven approaches are desirable because they decouplesystem components

I Event-driven approaches are desirable because they help make asystem responsive to events that are potentially visible and significantto users




Architecture Modules: ApplicationsTypically, frontends of business processes

I Often directly visible to usersI Application deploymentI Data modeling and integrityI Business intelligence: decision support and analytics

I More technical but indirectly visible to users

I Interoperation and cooperationI Ontologies: representations of domain knowledge

I Component and model repositoriesI Business process management




Architecture Modules: Systems

Functionality used by multiple applications

I Middleware: enabling interoperation, e.g., via messaging

I Identity management, e.g., ID across a system to support Single SignOn

I Security and audit

I Accessibility

I Policy repositories and engines




Architecture Modules: Infrastructure

I Connectivity

I Platform: hardware and operating systems

I Storage

I System management




Functionalities in a Working Enterprise SystemCompare with three-tier architectures

I Presentation: user interactionI A large variety of concerns about device constraints and usage scenarios

I Business logicI Application-specific reasoningI General rules

I Data managementI Ensuring integrity, e.g., entity and referential integrity (richer than

storage-level integrity)I Enabling access under various kinds of problems, e.g., network

partitionsI Supporting recovery, e.g., application, operating system, or hardware

failures




Enterprise FunctionalitiesBases for choosing among architectures

For three-tier architectures

I Size of implementations

I Organizational structure: who owns what and who needs whatI Staff skill sets

I User Interface: usability and designI ProgrammingI DatabaseI Policy tools

I Products available in the marketplace



Architecture in IT Tiered Architecture



Commitments









One-Tier and Two-Tier Architectures

I One tier: monolithic systems; intertwined in the code baseI Historically the first (usually early approaches are monolithic)I Common in legacy systemsI Difficult to staff, maintain, and scale up

I Two-tier: separate data from presentation and business logicI Classical client-server (or fat client) approachesI Mix presentation with application business rulesI Change management




Three-Tier Architecture

I Presentation tier or frontendI Provides a view to user and takes inputsI Invokes the same business logic regardless of interface modalities:

voice, Web, small screen, . . .

I Business logic tier or middle tierI Specifies application logicI Specifies business rules

I Application-level policiesI InspectableI Modifiable

I Data tier or backendI Stores and provides access to dataI Protects integrity of data via concurrency control and recovery




Multitier ArchitectureAlso known as n-tier

I Best understood as a componentized version of three-tier architecturewhere

I Functionality is assembled from parts, which may themselves beassembled

I Supports greater reuse and enables greater dynamismI But only if the semantics is characterized properly

I Famous subclass: service-oriented architectureI Enterprise version: when the services are internalI General: some services are external




Architectural Tiers EvaluatedThe tiers reflect logical, not physical partitioning

I The more open the architecture the greater the decoupling amongcomponents

I Improves development through reuseI Enables composition of componentsI Facilitates governance, including scaling up of resourcesI Sets boundaries for organizational control

I In a narrow sense, having more moving parts can complicateadministration

I But improved architecture facilitates administration through divideand conquer




XML-Based Information System

Let’s place XML in a multitier architecture




How About Database Triggers?

I Pros: essential for achieving high efficiencyI Reduce network load and materializing and serializing costsI Leave the heavy logic in the database, under the care of the DBA

I Cons: rarely port well across vendorsI Difficult to introduce and manage because of DBA controlI Business rules are context-sensitive and cannot always be applied

regardless of how the data is modified



Architecture in IT Web Architecture



Commitments









Web ArchitecturePrinciples and constraints that characterize Web-based information systems

I URI: Uniform Resource Identifier

I HTTP: HyperText Transfer ProtocolI Metadata must be recognized and respected

I Enables making resources comprehensible across administrativedomains

I Difficult to enforce unless the metadata is itself suitably formalized




Uniform Resource Identifier: 1

I URIs are abstract

I What matters is their (purported) uniqueness

I URIs have no proper syntax per seI Kinds of URIs include

I URLs, as in browsing: not used in standards any moreI URNs, which leave the mapping of names to locations up in the air




Uniform Resource Identifier: 2

Good design requirements

I Ensure that the identified resource can be located

I Ensure uniqueness: eliminate the possibility of conflicts throughappropriate organizational and technical means

I Prevent ambiguity

I Use an established URI scheme where possible




HTTP: HyperText Transfer Protocol

Intended meanings are quite strict, though not constrained byimplementations

I Text-based, statelessI Key verbs (and some others)

I GetI PostI Put

I Error messages for specific situations, such as resources not available,redirected, permanently moved, and so on

ReST: Representational State Transfer




Representational State Transfer

ReST is an architectural style for networked systems that constrains theconnectors

I Models the Web as a network of hyperlinked resources, each identifiedby a URI

I Models a Web application as a (virtual) state machine

I A client selecting a link effects a state transition, resulting in receivingthe next page (next state) of the application




Characteristics of ReST

I Client-ServerI Statelessness: in terms of sessions

I What is an advantage of statelessness?I Where is the session state kept then?

I Focus on resources being manipulated and their representations beingtransferred

I Uniform Interface: URIs, hypermedia

I Caching: responses can be labeled as cacheable



Architecture in IT Middleware



Commitments









Middleware PracticallyComponents with routine, reusable functionality

I Abstracted from the application logic or the backend systems

I Any functionality that is being repeated is a candidate for beingfactored out into middleware

I Enables plugging in endpoints (e.g., clients and servers) according tothe stated protocols

I Often preloaded on an application server

I Simplify programmer’s task and enable refinements and optimizations




Middleware ConceptuallyComponents that implement important architectural interfaces

Key examples: transaction and persistenceI Explicit:

I Invoke specialized APIs explicitlyI Ties application to middleware API: Difficult to create, maintain, port

I Implicit:I Container invokes the appropriate APIsI Based on declarative specificationsI Relies on request interceptions or reflection




ContainersDistributed object management

I Architectural abstraction geared for hosting business components(objects)

I Remote method invocationI ThreadingI MessagingI TransactionsI Connection pooling

I Implementations for JEE and .NET




JEE TechnologyVernadat

EJB Server

Entity Bean

Session

Bean

J2EE

Connector

Relational

DBMS

Legacy

System

CORBA Client

Java Applet in

Browser

Java

Applications

(Swing, AWT)

Web Browser

Servlet JSP

RMI, IIOP

XML, HTML, HTTP (SSL)

RMI

RMI

RMI

Java Message

Service

Java Naming and

Directory

Interface

Operating System (Windows,

Linux, Mac, Solaris…)




.NET TechnologyVernadat

Microsoft Transaction Server

Shared Property

Manager

COM+

COMPONENT

Babylon Integration

Server

Relational

DBMS

Legacy

System

ADO,

OCEDB,

ODBC

CORBA Client

ActiveX Control

in Browser

Applications

Web Browser

IIS/ASP

XML, HTML, HTTP (SSL)

Microsoft

Message

Queue

Active Directory

Windows Operating System




Basic Interaction Models

Interactions among autonomous and heterogeneous partiesI Adapters: what are exposed by each party to enable interoperation

I Sensors ⇐ informationI Effectors ⇒ actions

I Invocation-based adapters

I Message-oriented middleware

I Peer-to-peer computing




Invocation-Based Adapters: TypesRealized in distributed objects, e.g., EJB, DCOM, CORBA

I Synchronous: blocking method invocation

I Asynchronous: nonblocking (one-way) method invocation withcallbacks

I Deferred synchronous: (in CORBA) sender proceeds independently ofthe receiver, but only up to a point




Invocation-Based Adapters: ExecutionExecution is best effort: application must detect any problems

I At most onceI More than once is

I OK for idempotent operationsI Not OK otherwise: application must check




Message-Oriented Middleware

I Main varietiesI Queues: point to point, support posting and reading messagesI Topics: logical multicasts, support publishing and subscribing to

application-specific topics; thus more flexible than queuesI Blackboards: Variant of topics wherein data items can be over-written

and consumed

I Can offer reliability guarantees of delivery or failure notification tosender

I Analogous to store and forward networksI Usually implemented over databases




A standardized callback for messages

I Accessed only via messages, not invoked

I No need for specialized interfaces, such as home, remote, . . .I Easy interface to implement: onMessage() as a callback

I Programmer defines what actions to take on receipt of a messageI Limited message typing

I Stateless: thus no conversations




Peer-to-Peer ComputingTraditionally, hard coded into specific applications, such as file sharing

I Symmetric client-server: (callbacks) each party can be the client ofthe other

I Asynchrony: while the request-response paradigm corresponds to pull,asynchronous communication corresponds to push

I Generally to place the entire intelligence on the server (pushing) side

I Federation of equals: (business partners) when the participants canenact the protocols they like

I Revisited from a cross-organizational perspectiveI Business protocols being defined in terms of business interactions, not

low-level messaging




Enterprise Best Practices

I Enterprise Service BusI Builds on top of messagingI Provide orchestration as a way to realize business processesI Shields programmer from transport and location considerations

I Asset repositoryI Building on directory services

I Data dictionaryI Evolving into one based on ontologies



Architecture in IT Deployment Architecture



Commitments









Deployment Architecture: Web Server

I Frontend

I Supports HTTP operations

I Usually multithreaded




Deployment Architecture: Application Server

I Mediates interactions between browsers and backend databases: runscomputations, invoking DB transactions as needed

I Provides a venue for the business logicI Different approaches (CGI, server scripts, servlets, Enterprise

JavaBeans) with tradeoffs inI Overhead: OS processes versus threadsI ScalabilityI Security




Application Server as an Architectural AbstractionSeparates business logic from infrastructure

I Load balancing

I Distribution and clustering

I Availability

I Logging and auditing

I Connection (and resource) pooling

I Security

Separate programming from administration roles




Deployment Architecture: Database Server

I Holds the data, ensuring its integrityI Manages transactions, providing

I Concurrency controlI Recovery

Transaction monitors can manage transactions across database systems,but within the same administrative domain




Data Center Architecture

I Demilitarized zone (DMZ)I External routerI Load balancer

I Firewall: only the router can contact the internal networkI Internal networkI Web serversI Application serversI Database servers



architecture in it outlinearchitecture in it architecture conceptually as opposed to the description...

Documents