Title: Collaborative Network Applications
1Collaborative Network Applications
- Stephen T. Mohr
- smohr_at_answerthink.com
2The Challenge of Distributed Web Applications
- Loosely coupled networks (connectivity and
technology) - Loosely managed - no central control, little
common agreement - Desire for reuse
- Need to cope with rapid change
- Need to deal with noise in data
3Five Principles of Distributed Development
- Applications will be built from coarse-grained
services that implement a unit of processing
larger than components - Services will be discovered by querying
directories - Services will be provided as self-describing data
4Five Principles (continued)
- Services will be enlisted on a transient basis
- Services must support extension and degrade
gracefully
5Services
- Why not components?
- Convenient granularity for Web applications
- ASP, CGI, etc. for implementation
- Small enough to promote reuse, large enough to be
broadly useful
6Finding Services through Directories
- Directories are a central repository describing
the resources and organization of the enterprise - Describe services in terms of the vocabularies
they speak and their URL - Choose scope wisely
7Communicating through Self-Describing Data
- Cant count on distributed object technology in a
loosely coupled network - Write out the state of an object on the server
and reconstitute it on the client - XML is a (nearly) universally accepted tagged
language - Tagging clearly delimits and describes data -
less confusion in processing!
8Use Services and Release Them
- Service providers may not always be available
- Each HTTP round-trip should work like a
transaction - Works well with HTTPs stateless nature
- Service consumers maintain the state of the
computation
9Promote Extension, Tolerate Degraded Data
- People can find common ground Web apps should
too - Views of objects evolve and diverge over time
- Backward and forward compatibility
- Small bugs can put noise in data - cope with it!
10Building Business Services in ASP
- ASPs that return XML documents
- Each service has one or more pairs of request and
response vocabularies - Encapsulate the data and processing of a service
- Use components to implement services
11Typical ASP Structure
- lt_at_ Language"Javascript" gt
- ltHTMLgt
- ltHEADgt
- lt/HEADgt
- ltBODYgt
- lt
- // Some code here
- Response.Write(xxx)
- gt
- lt/BODYgt
- lt/HTMLgt
12XML only ASP Structure
- lt_at_ LanguageJavascript gt
- lt
- Response.ContentType"text/xml"
- var parser Server.CreateObject("microsoft.xmldom
") - / Add code to parse a request document, perform
processing, and create a reply document. / -
- Response.Write(parser.xml)
- parser null
- gt
13Architecture of a Service
14Directory Services
- Hierarchical store describing network objects
- An API to the data
- Optimized for read access
- Microsoft Active Directory, Netscape Directory
Server - Schemas - permissible classes and their properties
15What is LDAP?
- Lightweight Directory Access Protocol
- Open standard for directory access
- Distinguished names for objects, e.g.,
CNPrintSrv, OUSales, DCWidgets - Query syntax
- Language bindings for protocol
16LDAP Queries
- Syntax
- ltbase DNgt(filter)attributeListscopepref
erences - Example
- ltLDAP//sales/DCwidgetsgt((objectClassUser)(mai
ls))cn, mailSubTree
17COM Components
- Active Directory Services Interface
- Providers for each directory service, including
LDAP - Bind to a known object and query its properties
- ADO Data Source Object for ADS
- ad hoc queries using SQL or LDAP syntax
- read-only in ADSI 2.5 beta
18Some Conventions
- Use a well known class to represent services
- Have a naming convention to identify service
objects - List all the vocabularies the service can
understand - List the URL of the service
- Find a service by querying by vocabulary
19ActiveDirectory Implementation
- serviceConnectionPoint class
- serviceClassName xml
- serviceBindingInformation holds a list of
vocabulary names - url property locates an ASP implementing the
service - ltLDAP//Salesgt((objectClassserviceConnectionPoi
nt) - (serviceClassNamexml))url,serviceBindingInforma
tionSubTree
20Collaborating on Data
- Collections - Where do the objects begin and how
are they ordered? - Specialization - General properties and multiple
specialized views of an object - Versions - Vocabularies change, so provide a
means of reconciling data in both directions
21Collections
- An XML convention for collecting object
representations within an XML document - Indicates object boundaries
- Attributes
- ObjectType - top level tag names for contained
objects - Order - objects sorted by tag name
- Name - collection name
22Sample Collection
- ltCollection ObjectType"Person" Order"LName,
FName ascending" Name"Customers"gt - ltPersongt
- ltNamegt
- ltLNamegtAmanlt/LNamegt
- ltFNamegtAlbertlt/FNamegt
- ltMIgtAlt/MIgt
- lt/Namegt
- . . .
- lt/Persongt
- ltPersongtlt/Persongt
- ltPersongtlt/Persongt
- lt/Collectiongt
23Specialization
- Different users have different views of an object
- Reuse a general representation by adding
specialized properties - Our XML convention models this by making the root
of the general representation a peer property of
the specialized representation
24Specialization in Theory
General
Specialized
25Specialization in Practice
- ltOrderCustomergt
- ltCustomergt
- ltCustomerIDgt13lt/CustomerIDgt
- ltFirstNamegtBucklt/FirstNamegt
- ltMIgtQlt/MIgt
- ltLastNamegtRogerslt/LastNamegt
- ltStreet1gt10E3 Galactic Lanelt/Street1gt
- . . .
- ltTelephonegt999-999-9999lt/Telephonegt
- lt/Customergt
- ltPaymentOptionsgt
- ltCreditCardgt
- ltTypegtMasterCardlt/Typegt
- ltNumbergt4444444444444444lt/Numbergt
- ltExpirationDategt12/1/2000lt/ExpirationDate
gt - lt/CreditCardgt
- lt/PaymentOptionsgt
- lt/OrderCustomergt
26Versions
- Data schemas evolve
- Loosely coupled apps may use different versions
of the schema - Objective communicate several versions of an
objects representation in one document - Document recipient can faithfully recreate the
object in a version it understands
27Versioning Conventions
- Version, EarliestVersion attributes
- Each root child is a version
- List properties by exception
- Receiving software reconciliation rules
- Add new properties
- Replace changed properties
- Ignore dropped properties
28Sample Version-Controlled Representation
- ltPerson Version"v19981019
- EarliestVersion"v19980418"gt
- ltv19980418gt
- ltNamegtJohn Doelt/Namegt
- ltAddressgt1234 Nowhere Lane, Philadelphia,
PA - 19102lt/Addressgt
- lt/v19980418gt
- ltv19980521gt
- ltNamegt
- ltFirstgtJohnlt/FirstgtltLastgtDoelt/Lastgt
- lt/Namegt
- lt/v19980521gt
- ltv19981019gt
- ltEmployeeTypegtFull-timelt/EmployeeTypegt
- lt/v19981019gt
- lt/Persongt
29Sample After Reconciliation
- ltPersongt
- ltNamegt
- ltFirstgtJohnlt/Firstgt
- ltLastgtDoelt/Lastgt
- lt/Namegt
- ltAddressgt1234 Nowhere Lane, Philadelphia, PA
- 19102lt/Addressgt
- ltEmployeeTypegtFull-timelt/EmployeeTypegt
- lt/Persongt
30Avoiding Shared State
- State consumes resources
- Shared state makes scaling hard
- Extra complexity to keep data consistent
- Resources come and go - might not be able to
process some portion of the data later - Let the client worry about state, if necessary
31Handling Change
- Use directory scope wisely to promote good
implementations - Circulate data schemas
- Write XML code to be tag driven
- Use versioning as needed
- Write services to do as much as possible with the
data at hand
32Issues of Scale
- ASP-based services reduce the problem to that of
scaling a Web site - Server farms
- Scalable application tier
- Data scaling
- Asynchronous messaging
33A Scalable Architecture
34Summary
- Future belongs to loose, dynamic networks
- Adopt the Five Principles throughout the
enterprise - Use best tools for the job within service
boundaries - Use open standards between services
35Further Resources
- Designing Distributed Applications (Wrox)
- Understanding and Deploying LDAP Directory
Services (MacMillan) - Microsoft XML MSXML reference-
http//msdn.microsoft.com/xml - Microsoft Millennium - http//www.research.microso
ft.com/sn/Millennium - Java Jini - http//www.sun.com/jini/