slide1 n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Working Notes on Protocol Centric Compositional Architecture: Section 2 - Protocol Translating User Agents and Models by PowerPoint Presentation
Download Presentation
Working Notes on Protocol Centric Compositional Architecture: Section 2 - Protocol Translating User Agents and Models by

Loading in 2 Seconds...

play fullscreen
1 / 30

Working Notes on Protocol Centric Compositional Architecture: Section 2 - Protocol Translating User Agents and Models by - PowerPoint PPT Presentation


  • 152 Views
  • Uploaded on

Working Notes on Protocol Centric Compositional Architecture: Section 2 - Protocol Translating User Agents and Models by Robert J. DuW o rs with consideration of AJAX designs produced by PTC Corporation as works for hire for the Boeing Corporation. 04 / 26 / 2005.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Working Notes on Protocol Centric Compositional Architecture: Section 2 - Protocol Translating User Agents and Models by' - wayland


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Working Notes on

Protocol Centric Compositional Architecture:

Section 2 - Protocol Translating User Agents and Models

by Robert J. DuWors

with consideration of AJAX designs produced by PTC Corporation as works for hire for the Boeing Corporation.

04 / 26 / 2005

slide2

Innovating the next Dominant Design for Large Scale Distributed Systems

Section 1: Compositional Architecture

Need: Architectural understanding of what we really do in practice everyday on

the Web and to jump start better architectures for more effective solutions.

Solution: Compositional Architecture is the first architectural framework as

flexible as the Web itself and offers a powerful framework going forward.

Section 2: Protocol Translating User Agents and Models

Need: Provision of well structured customized functionality and unique User

Experience for specialized User Community markets at competitive cost.

Solution: Application Level Protocols (ASLP) link Service Oriented Models (SO-M)

that extend core product functionality flexibly and inexpensively, to

Protocol Translating User Agents (PTUA) that tailor User Experience on

the fly.

Section 3: Distributed Capability Architecture

Need: Trustworthy security from top to bottom of all architectural levels without too

much or too little securing of highly scalable, dynamic, distributed systems.

Solution: Permission Rule Based Capability model for coarse through fine

grained control, and for scalable, adaptable “just right” security

controls from top-to-bottom and end-to-end: a big step beyond the

currently dominant but troubled Access Control List (ACL) model.

slide3

Application Protocol Centric Models and Protocol Translating User Agents:

Well Structured Extension of Product Functionality and Adaptation of User Experience

  • Opportunity:
  • Gain far reaching competitive advantage in product line architecture by providing dedicated application
  • components connecting on-demand to modularized User Interfaces that can be created quickly using
  • standardized technologies at low cost by in-field solution architects, VARs, and developerson behalf of
  • multiple user communities. Build better, cheaper, faster, and with much more flexibility!
  • Challenges:
      • The technology pendulum swings as pendulums do:
        • glass Teletypes and 3270s to UNIX Workstation and PC Windowing System, back to X-Windows,
        • forward to Web Browsers, back to Server Pages, forward to AJAX architecture
      • But there has never been clear and concise guidelines as to what belongs in User Interface, what belongs
      • in the application, where and when it should all happen:
        • the technology progresses but architecture seems to bounce randomly: where are the architectural
        • guidelines to determine division of responsibility and placement of functionality which are the heart
        • of distributed system architecture? Is there a natural architectural equilibrium?
      • The current industry domination design, (Java and ASP) Server pages undesirably mix together design
      • issues of display and information content in troublesome and ultimately inefficient ways that:
        • require multiple skill sets that do not belong together, i.e. client side, server side, application specific
        • results in severe impact on business models: high cost, late delivery, reliance on rare skill sets,
        • missed marketing windows, competitive disadvantage of being priced out of markets, and
        • unnecessarily inflexible products incapable of serving the needs of specific user communities
    • Needed: A new dominant design in distributed architecture to greatly advance Application and UI creation
  • Solution: Protocol Translating User Agents (PTUA) and Models (SO-M) Architecture
slide4

Beyond Marketing Buzzwords and Hype:

Thin/Virtual Terminal

Clients

Rich/Smart/Fat

Clients

Protocol Translating User Agents

(PTUAs)

Protocol Translating User Agents (PTUAs) come at the mid-point of the fuzzy continuum between

“Thin” Clients and “Rich” Clients but only PTUAs are well defined regarding precisely what they do and don’t do!

slide5

Separation of presentation from application logic

“One of the major downfalls of most web applications is the tight coupling of user interface elements with … application logic. This poses a significant problem in team environments because the skills required to develop these two parts are often satisfied by different people.

… The layout and appearance of … applications can be altered independently of the application definition and logic…

This degree of separation results in applications that are easier to maintain by programmers and readily customized by designers and language translators.”

Easy

customization,

localization,

or branding

Another highly practical benefit of the separation … among application logic, presentation, and language text is the ease of customizing for different customers or groups of users.

From: http://www.mozilla.org/projects/xul/joy-of-xul.html

slide6

“Model View Controller” Pattern

Controller

user interaction

UserActions

Set

State

ChangeView

Update

Event

View

model representation

Model

Domain Semantics

GetState

slide7

“Model-View-Controller”

as Adapted from OOP

to Web Environments by

The Currently Dominate

Application Server Pages (ASP) and

Java Server Pages (JSP)

Architectures

Display

Browser “Page” Rendering & User

Interaction

User Input

HTTP Get/Post of HTML etc.

Server Side View and Information Content Binding 1

Specialized Framework

Protocols 3

Controller 4

“View” 2

1 ASP or JSP

2 Not really the View, but rather a description of the

view (consider HTML and its ilk as meta-views)

3 Typically script or DLL/JVM method calls

4 Script/ “Code Behind” or “JSP tag libraries”: typically

includes the Controller’s own notion of “intra-page

control” and “inter-page flow” (often application

process/transaction oriented)

5 COM++/IIOP/RMI/ODBC/JDBC etc.

6 Often “Business Rules” plus DBMS

Assorted Specialized Protocols 5

Model including Application Persistence 6

slide8

What’s Wrong With This?

  • MVC is an Object Oriented Programming Pattern useful for very tightly
  • coupled code (inter-related classes) with lots of low overhead interactions
  • (method calls) using small amounts of information (parametric values)
  • exchanged frequently in the same (high speed) memory space
  • Distributed System Architecture favors decoupled logic where invocations
  • tend to be relatively expensive (lots of protocol overhead and delays)
  • favoring fewer interactions (protocol operations) that use large amounts of
  • data (often documents or pages) exchanged relatively infrequently over the
  • network
  • Real MVC fails in a highly distributed environment (full MVC over CORBA or
  • COM+? shudder), so the ASP/JSP architecture is really an adaptation to a
  • radically different environment (web server)
  • Unfortunately, a poor one – Resulting from a bad separation of concerns
  • due to poorly drawn boundaries and division of responsibility in the basic
  • ASP/JSP architecture
slide9

Beyond Model View Controller*

[AJ]SP

* Actually we want to change HOW we use these technologies

slide10

What’s Wrong With This – cont’d

  • Fundamentally, the application model and user presentation concerns are being smeared
  • together by the middle man (the ASP/JSP pages) through mixing in:
      • Model + ASP/JSP Page + Browser Page Instance =
        • (Application Model Logic Semantics)
        • + (Application Model Control X
        • Binding of Instance Content X
        • Generation of User Display Description X
        • Generation of User Interaction Description X
        • View Control Logic X
        • Interpretation of Returned User Interaction Descriptions)
        • + (actual User Display X
        • actual User Interaction in the browser)
  • The above creates “entropic synergy” i.e. joining items together creates much worse
  • results than when they were on their own!
  • Solution: Refractor!
      • Model X Generic User Agent X Model Data Instance =
        • (Application Model Logic Semantics X Application Model Control)
        • + (Generic User Display Description X
        • Generic View Control Logic X
        • Generic User Interaction Description)
        • + (Binding of Instance Content X
        • actual User Display X
        • actual User Interaction X
        • Interpretation of User Interactions)
slide11

What is the Glue that Holds The Refactored Solution Together?

In a Word: Application Service Level Protocols (ASLP)

  • Model Centric Architectural Principles are at the core of the strategy:
    • Models are primary, User Agents are secondary side effects
    • Models provide content, User Agents make content accessible to
    • humans
    • Models and User Agents interact exclusively by means of Application
    • Level Protocols (ASLP)
    • The interior of the network (i.e. “models” and “services”) has no
    • business concerning itself with user presentation – that should happen
    • only in edge nodes, i.e. only in User Agents
    • This approach could be considered “Web Services Lite”, but it’s also
    • compatible with “Web Services Heavy”, for those who want all that stuff
  • Application Model Controls and Interpretation of User Interaction are the architecture hooks
    • Application Model Controls depend upon Application Model Logic Semantics and are
    • independent of actual User Display
    • Interpretation of User Interaction involves translating them into the actions of
    • Application Model Controls
    • Presentation of actual User Display involves translating the Application Model
    • Semantics, including Application Model Controls, into forms intelligible to humans
slide12

Anatomy of a Generic Protocol

Local Application Program Interface (API)

Local Application Program Interface (API)

Network Link

Network

Node B

Network

Node A

AtoB Message 1

AtoB Message 2

AtoB Msg 3

BtoA Message 1

BtoA Message 2

Service Access Point (SAP)

a.k.a. Network Address or Network Port

  • Definition: The protocol is the rules for valid types of messages “on the wire” and the legal sequence of messages (i.e. the “behavior” of each end).
  • The Application Programming Interface (API) provides the mean by which developers gain access to each Protocol.
  • APIs relate to Protocol in N:M ways.
  • In general, a specific Protocol is vastly more important than a specific API in Network Computing Architecture. Traditional software engineering mentality not withstanding!
slide13

What is the Glue that Holds This Together?

First, The Application Service Level Protocol

Application Service Level

Protocol

Application Protocol Model Content

Protocol Translating User Agent

(PTUA)

Model Logic & Persistence

(SO-M)

Application Protocol

Model Controls

Physical

User

Presentation

Physical User Interaction

Persistence Engine

Legend;

Service Access Points (SAP)

a.k.a. Network Addresses

slide14

Model Logic & Persistence2

(SO-M)

Application Service Level Protocol Structures

(Assuming Mainly HTTP Transport)

XML

Content

XML

Content

XML

Content

Presentation

e.g.. HTML, Javascript (once)

Client

Web Browse

(PTUA)

Portal Server1

Request

XML Data

e.g.. Post data

Request

XML Data

e.g.. Post data

Request

XML Data

e.g.. Post data

Request UA e.g.

URL + parms

(once)

User Agent

Source Server2

1 Portal Server is Optional if direct connect used

2 Model and UA Source Servers may be directly

connected to client

slide15

The First Five Design Rules For Protocol Translating User Agents and Models

  • 1. The Model, or more generally the interior network services, contain all of the application semantics:
    • “Everything that can be known about the application is known to the Model.”
    • or
    • “The Model is the source of all of the possible application content.”
  • The Application Service Level Protocol (ASLP) is the only method by which the model exposes application semantics:
    • “The Application Level Protocol is the voice of the application.”
  • The ASLP communicates but does not add to application semantics revealed to it by the Model:
    • “The Application Level Protocol carries application content but does not embellish it.”
  • All application semantics expressible by the User Agent comes exclusively from the ASLP:
    • “The ASLP is the application content, the whole content, and nothing but the content to the User Agent”
  • The User Agents understands only enough application semantics to give expression to the ASLP by means of user presentations and interactions that in themselves can not insert any additional application semantics.
    • “The User Agents expresses application content but does not add to it.”
      • or
    • “The User Agent is a gloried style sheet for the applications content carried by the ASLP.”
        • or
      • “The User Agent only knows about the application only through what the ASLP tells it.”
slide16

What is all the Glue that Holds This Together?

The Application Service Level Protocol and User Agent Loading Protocol

User

Presentation

Application Service Level Protocol

User Interaction

Application Protocol Model Content

Model Logic & Persistence

( May be a Core Model or an Extension Model)

Protocol Translating User Agent

(PTUA)

Application Protocol

Model Controls

Persistence Engine

User Agent

Source Server

User Agent Needed

User Agent

Library/Templates

Generic User Agent Whole or Part

User Agent

Library/Templates

User Agent Loading Protocols

slide17

The Sixth and Seventh Design Rules For Protocol Translating User Agents and Models

  • The Compositional Architecture Rule for Protocol Translating User Agants (PTUA): User Agents are constructed in whole or part (transclusion) as needed from network resources.
    • “User Agents are created as needed from URIs.”
      • or
    • “The User Agent adapts to the ASLP as needed.”
        • or
      • “The User Agent gets its brains from the rest of the network.”
      • or
      • “The User Agent expresses distributed knowledge from throughout the network (subject only to security constraints).”
  • 7. The Compositional Architecture Rule for Models (SO-M): same as above for models as needed.
slide18

The Heritage of

Protocol Translating User Agents

And

Service Oriented Models

(UML Conventions)

Data Flow

Architecture

Hardware Data Flow

Architecture

Software Language

Data Flow

Architecture, etc.

Network

Agent and Service

Architecture

Search Engine Spider

Architecture

Web Services

Architecture

etc.

Service Oriented

Edge Node

Architecture

Embedded Controller

Architecture

Sensor System

Architectures

etc.

PTUA/SO-M

Architecture

slide19

AJAX Architecture: Some of the Most Effective Current Technologies for building Protocol Translating User Agents

Figure 1: The traditional model for web applications (left) compared to the Ajax model (right).

From: http://www.adaptivepath.com/publications/essays/archives/000385.php

slide20

Why The Extensive Use of XML for the Application Level Protocol?

“He gives an example of how XML makes it easy to swap out an application's current GUI -- presentation layer -- with another.

"Before XML, we'd been trying to factor out the presentation layer away from the underlying code using some pretty interesting techniques in a homebrew of Perl, ColdFusion and Java," Ostergaard said.

"But when XML and XSLT hit the stage, we were able to throw out our own home-grown code and use standards-based code to factor out the presentation layer and bind in a new front end.“

XML also made the binding of the presentation layer to the underlying code much cleaner, and improved performance. "We were able to remove tremendous amounts of old code," he added. “

From: http://idevnews.com/TipsTricks.asp?ID=139

slide21

Classic Web Protocol Structures

Presentation

e.g.. HTML, Javascript

Presentation

e.g.. HTML, Javascript

Content

Content

Client

Web Browser

Web Server

Request

Data

e.g.. Post data

Request

Action e.g.

URL + parms

Request

Action e.g.

URL + parms

PTUA/SO-SM Application Protocol Structures

(Assuming Mainly HTTP Transport)

XML

Content

XML

Content

XML

Content

Presentation

e.g.. HTML, Javascript (once)

Client

Web Browser

(PTUA)

Portal Server1

Request

XML Data

e.g.. Post data

Request

XML Data

e.g.. Post data

Request

XML Data

e.g.. Post data

Request UA e.g.

URL + parms

(once)

1 Portal Server is Optional if direct connect used

2 Model and UA Source Servers may be directly connected to Client

Comparison of Classic Web

and PTUA/SO-M

Protocol Structures

(Assuming mainly HTTP Transport)

Model Logic & Persistence2

(SO-M)

User Agent

Source Server2

slide22

Protocol Translating User Agents and Models:

Internal and Network Structures

Robert J. DuWors 04 / 26 / 2005

slide23

Anatomy of a Logical SO-UA

Mapping Adapter

Protocol to User Interface

Informational Transform

User Interface

View and Interaction Generator

Protocol Handler

User Inteface to Protocol Informational

Transform

Physical

Presentation

Application

Protocol

Browser Engine

Physical

User Action

slide24

Anatomy of an Example AJAX SO-UA (Karam Style*)

Protocol View Controllers typically including Presentations and basic Interactions

XML Based & Other Application Level

Protocol

Units

URI

Loads *

Protocol Major State and Action Handlers typically including Submenus

URI

Loads *

Basic User Agent Services including Screen Real Estate,

Utilities, and typically Top Level Menus

URI

Loads *

Browser Engine : I.E., F.F., etc.

HTML, XML, XLST, Javascript, CSS, Java and so on.

* Via URI

Application Protocols

HTTP XML, Streaming data, etc.

User Agent Loading Protocols

HTTP HTML, XLST, Javascript etc

* It all began by trying to make architectural sense out of this!

slide25

Service Orientd User Agent

(SO-UA)

Integration

Server

Mapping Adapter

Protocol to User Interface

Informational Transform

BizTalk

Server /

IBM WBI /

Windchill

etc.

User Interface

View and Interaction Generator

Protocol Handler

User Inteface to Protocol Informational

Transform

(the SO-M

never has

to talk to the

Web Server)

Physical

Presentation

Application

Protocol:

(HTTP[S], Pure XML)

Browser Engine

Physical

User Action

User Agent Loading Protocol:

(HTTP[S], HTML, Javascript, XLST,

CSS, XML configuration, etc.)

An Example Value Proposition:

The Protocol Translating User Agent (PTUA) in the Browser connects directly to the Integration Server as a cost effective no frills Data Translation, Business Process Orchestration, and Collaboration Engine (SO-M).

Web Sever

(Apache/IIS/Tomcat etc.)

(Only used to load appropriate User Agent as needed upon request)

slide26

An Extended Example of using Integrations Servers as an Direct Integration/Collaboration Models (SO-M) with Protocol Translating User Agents (PTUA) using “AJAX” technology

Pux – Protocol for PT User Agent, type X (XML) Pm1 – Protocol for Model server, type 1

Puy – Protocol for PT User Agent, type Y (XML) Pm2 – Protocol for Model server, type 2

PLx - Protocol for loading PT User Agent, type X Pss – Protocol for Security server

PLY – Protocol for loading PT User Agent, type Y

Data Translation & Collaboration Rules

Persistence Engine

e.g.

ODBC

Model Type 1 Servers & Persistence

:

PuX

(Pure XML)

Pm1

e.g. SOAP, UPnP, etc.

Pss

Integration

Servers:

Integration and Orchestration

SO User Agents Type X

Pm2

e.g. COM+, CORBA, EDI,

etc.

Puy

(Pure XML)

Model

Type 2

Servers

Pss e.g. LDAP, etc.

SO User Agents Type Y

PLy e.g.HTML, Javascript, XLST, etc.

Pss

Pss

UA Servers (e.g. Apache / IIS)

User Profile & Security Servers

PLx e.g.HTML, Javascript, XLST, etc.

Pss e.g. LDAP, etc.

slide27

Example of Core Architectural Protocols:

with Customization Extension Models and Portal Servers

Pm1 – Model protocol, type 1 Pux - PT UA loading protocol (HTTP+HTML+…), type X

Pm1A - Extension model protocol, type 1A PuY - PT UA loading protocol, type Y

Pss – Security server protocol, type S Pxn – eXternal server protocol (strictly optional), type n

Psu – UA server protocol, type u

PuX

PTUA Type X

Pxn

Pm1A

Model Type 1 Instance “A”

(Model

Based

Security)

Pm1

Pm1A

PTUA Type X

Portal

Server

PuX

Pm1A

(Note: All Application Logic resides only in Core Models and in Extension Models)

PTUA Type Y

Pm1

Extension

Model

Type 1A

PuY

Pm1

Psu

Pss

Pss

Model Type 1 Instance “B”

Pss

User Profile & Security Server

UA Server

UA Server

Pss

slide28

PTUA/SO-M Layered Architecture1

  • Core Models may connect to each other, to Extension Models, or to nothing.
  • Extension Models must connect to at least one Core Model or to another Extension Model, and may connect PTUAs.
  • PTUAs must connect to one and only one either Core Model or Extension Model, but never connect to each other! i.e. This Is NOT a P2P architecture.
  • User Profile and Security Policy Servers may be types of Core Models and may be types of Extension Models.
  • User Agent Servers live in their own space, but likely have extensive contact with the User Profile and Security Policy Servers, and of course load all PTUAs.
  • N.B. If needed, there may be a Portal Layer between the Extension Model Layer and the PTUA Layer
  • 1 Motivated by real world experience.

(Note: All Application Logic resides only in Core Models and in Extension Models)

User Agent Servers

PTUA

D

Loads all PTUAs

PTUA

A

Extension Model 1

PTUA

E

Extension Model 2

Core Model A

User Profile & Security Servers

Core Model B

User Profile & Security Servers

Core Model D

Extension Model 4

Core Model C

Core Model

Layer

Extension Model 3

PTUA

E

PTUA

Variant B1

Extension Model

Layer

PTUA

C

PTUA

Variant B2

Protocol Translating

User Agents

slide29

The Significance to Product Line Architecture

    • There are 7 significant degrees of freedom that are the architectural inflection points:
  • 1. Protocols that can be added, enhanced, or replaced relatively painlessly
    • Provide minimum coupling between servers and agents
    • Are the basis of plug and play for the rest of the architecture
  • 2. Core models that can be added, enhanced, or replaced relatively painlessly
    • Generally contain the “core product functionality”
  • 3. Extension models that can be added, enhanced, or replaced relatively painlessly
    • Further complete product functionality on the basis customized vertical market needs, user community needs,
    • or individual customer requirements without disturbing the core product
    • Useful product functionality can be added in the field without privileged knowledge of core product internals
    • Ensure that all application logic remains in the hands of the server side product architects and away
    • from the meddling of User Agent designers
  • 4. User Agents that can be added, enhanced or replaced relatively painlessly
    • Keep the product suite’s presentation to end users separate from design of the product’s functionality
    • Put all User Interface concerns solely into the User Agents and in the hands of the User Agent designers
    • Keeps server side architects from specifying really, really dumb and inflexible User Interfaces
    • Primary point of customization for the market place: “small changes can have big impact - the 20/80 rule:
    • 20% of the effort for 80% of the gain”, or somewhat more cynically, “sell the sizzle, not the steak”
  • 5. User Agent Servers that can be added, enhanced, or replaced relatively painlessly
    • User Agents may be statically or dynamically generated for application, security, or personalization needs
    • Might be the last refuge of JSP and/or PERL,  but XLST also likely to be a major tool
  • 6. User Profile &Security Servers that can be added, enhanced, or replaced relatively painlessly
    • As noted in the Distributed Capability Model, security severs can interact with both personalization and model
    • based security, as well as with filter based security
  • 7. Portal Servers that can be added, enhanced, or replaced relatively painlessly
    • Provides deployment architecture “glue” as needed, likely to get around “same source” security policies, and/or
    • differences in multiple realm administration
slide30

The Significance to Product Line Architecture – cont’d

    • Commonality/Variability Analysis (CVA)
  • The greatest Commonality and stability exists in the central Core Model layer, and decreases outward
  • The greatest Variability and instability exists in the edge User Agent layer, and decreases inward
  • Relationship to “Service Oriented Architecture”
  • Every node in PTUA/SO-M architecture is “service enabled” in that it speaks a defined machine-to-machine
  • protocol
    • this makes it relatively easy to “mix and match” at all stages from design time through run time
    • it might be call “Service Oriented Architecture Lite”
    • it is fully compatible with the goals and techniques of “Service Oriented Architecture Heavy”:
  • SOAP, WSDL, etc.
  • Only the User Agents are User Interface oriented as well
    • PTUAs are “service enabled” on their back end
    • PTUAs are also “user interface oriented” on their front ends, which are viewed as specialized forms of
    • human-to-computer protocols