Internet Architectural Principles for the eBusiness Era

1. Internet Architectural Principles for the eBusiness Era • Architectural Guidelines for going forward: • A-to-A • B-to-B • Enterprise Architecture • All of the above

2. Recommending a Strategy • Internet Architecture Principles Are Proven to Work... • Unprecedented interoperability, scalability, and functional extensibility • Unprecedented economic impact: the “business case” which changed the world • Unstoppable combination: Collaborative Computing is King! • So Let’s Apply them to throughout the Entire Architecture! • A2A, AI, B2B, B2C, EIA, etc.

3. 4 Basic Principles of Internet Architecture: #1) The Internet Architecture is defined by a collection of protocols which are the rules for things to talk to each other. #2) Everything can talk to everything else. #3) Intelligence lives at the edge of the network, not within it. #4) Internet Service Model: functionality is provided by the federated action (collaboration) of protocol specific services.

4. #1) The Internet Architecture is defined by a collection of protocols: • e.g. IP, DNS, HTTP, TCP, POP3, FTP, SNMP, Telnet, LDAP, RIP, BGP, ... • the protocol specifications are usually sanctioned by the Internet Engineering Task Force (IETF) • World Wide Web Consortium (W3C) also emerging as a companion source of standards

5. Software Service Interface (API) Software Service Interface (API) Local Network Stack Component Network Channel Local Network Stack Component AtoB Message 1 AtoB Message 2 AtoB Msg 3 BtoA Message 1 BtoA Message 2 Network Node A Network Node B • The protocol defines the rules for valid types of message “on the wire” and the legal sequence of messages. • The Software Service Interface (SSI) defines the Application Programming Interface (API) independently to each local network stack component. • SSI/API relates to Protocol in N:M ways. • In general, a specific Protocol is vastly more important than a specific SSI/API in Network Computing Architecture. Traditional software engineering mentality not withstanding!

6. #2) Everything can talk to everything else: • the basic Internet Protocol (IP) does not define a “cloud” but rather an image of total inter- connection • inherently Peer to Peer but not physically Point to Point • tech note: only datagram (packet) delivery known to the inside of the network

7. SMTP Server DNS Server eMail Client DNS Server #3) Intelligence live at the edges of the network, not within it: • No single point of control or failure • Decoupling of unrelated functionality • Simplified design of functionality, e.g. DNS, SMTP, LDAP, SNMP, etc. • Specific functionality controlled by self-organizing communities • Vast Synergy: nearly infinite number of ways recombine functionality at the end Points!

8. #4) Internet Service Model: functionality is provided by the federated action (collaboration) of protocol specific services: • Each protocol specification implies the existence of a distributed computing model (which may or may not be explicitly mentioned): • Distributed Communication Scheme: the service protocol itself consisting of protocol messages (logical data units) and sequence rules (“behavior”) • Distributed Processing/Algorithm Scheme, e.g. WWW: Navigating the “World Wide Web” as one huge hypertext document FTP: file access & transfer rules, DNS look up, SMTP: eMail delivery, … • Distributed Memory/Persistence Scheme, e.g. WWW: Web page contents stored in whatever form FTP: files, DNS:name records, SMTP: message stores, LDAP: X.500 trees, .... • Distributed Linkage Scheme to find/relate things of interest, e.g. WWW: the URL (an act of sheer genius!) SMTP eMail addresses, DNS names, LDAP distinguished names, …. • The operational result of the distributed computing model enabled by the particular protocol is a virtual service, namely the protocol’s “Internet Service”

9. An Internet Service • An Internet Service provides functionality which appears to be available throughout the net provide by and to communities of common interest. • An Internet Service is: • Virtual • Well Defined • Distributed • Federated (Collaborative) (Virtual) Internet Service

10. An Internet Service Is: • Virtual • An Internet Service is “virtual service” which looks like one complete thing but in reality has many far flung parts glued together • Well Defined • An Internet Service is defined by a common protocol specification (messages and rules about exchanging message) • Usually promulgated through the Internet Engineering Task Force (IETF), or more recently, the World Wide Web Consortium (W3C)

11. An Internet Service is: (cont’d) • Distributed • An Internet Service protocol specification implies (not necessarily overtly) an associated Distributed Computing Model: • Distributed Algorithm(s), • Distributed Data Store(s), • and Distributed Reference Mechanism(s) (URI, etc.) • An Internet Service may (C/S), or may not (P2P), divide its participants between client and server nodes

12. An Internet Service is: (cont’d) • Federated (Collaborative) • Technically • an Internet Service is composed of many participants • an Internet Services coexists, often beneficially, with other Internet Services (sometimes in a layered relationship) • Organizationally: Technical Structure follows Social Structure • There must be an active social/technical/business community(s) which come together around a common interest(s) in the Internet Service • Never, or at most rarely, is there a single enforcing point of control over the service (protocol) specification nor over the service operation (systems administration, etc.)

13. Internet Service Examples: IP Routing, Domain Name Service, eMail, and the World Wide Web

14. Note: even the fundamental IP connectivity of “everything to everything else” is really a virtual service internal to the Internet called IP Routing! IP Routing Service Physical Network Topology: Limited Direct Connectivity IP Conceptual Addressing: Everything connected to everything else

15. Further notes on the TCP as an Internet (virtual) Service: • While IP routing is provided by the internals of the network, Transmission Control Protocol (TCP) is the prime example of virtual service provide by “intelligence at edge of the Network” • IP allows packet by packet to go from anywhere to anywhere: “datagram/connectionless” transport • TCP provides an overlaid sequential message stream layered on top of IP: “virtual circuit/connection oriented” transport • By means of the TCP protocol each end node (TCP/IP procotocl stack) sorts out packets which may arrive in jumbled order in order to maintain the illusion of a continuous octet (byte) stream • In its day this was radical: most contemporary network architectures in the 1970s and 1980s were not datagram oriented, but rather virtual circuit oriented, e.g. SNA, DECNet, X.25, ISDN, etc.

16. Architectural Observations • Social/Business Context: most standard Internet Services provide core functionality of interest to a large percentage of Internet users (i.e have really large communities), e.g. DNS, HTTP, SMTP, etc. • Most of these core Internet Services are analogous to Single Instruction Multiple Data (SIMD) computer systems architecture • Each server independently follows the same algorithm (SI equivalent) with its own unique data store contents (MD equivalent) • The algorithms and virtual data stores tend to be fairly simple • Services may be implemented by “components” in any given node, often they are, but they don’t have to be • Much like “components” may be implemented by “objects”, often are, but don’t have to be • Services are NOT defined by APIs, programming languages, or distributed object models, rather they are defined by protocols

17. Architecture Observations - Future Directions • The notion of Internet “Service” is expanding from infrastructure functionality (IP, TCP, DNS, LDAP, etc) to included support of many application domains (B2C, B2B, engineering, finance, etc.) • Concomitantly, Internet Architecture is expanding from SIMD like simple protocols to more sophisticated MIMD like protocols • Communities of interest may be smaller and more specialized, e.g. subcultures of Boeing suppliers and customers • A big enabler of the expanded notion of application level protocols are new data types such as multi-media (MIME and streaming formats) and, especially, XML • Better ways to define and implement the behavioral aspects of a protocol has not yet achieved the relative success of XML for the data aspects.

18. An Example of Using Internet Services in a Future Data Query Architecture

19. Internal Schema Service Service Service Client Application/ Service (e.g EJB) Client User Agent (e.g. Web Servlet) GUI (e.g Browser) Service Directory (e.g. UDDI) Distributed Query Services Architecture Service (aka "Interface") Repository(s) OLTP / System of Record(s) Partner OLTP/SoR(s) & Repository(s) Service Implementation (via Business Object Schema*) Service Implementation * e.g XML DTD/Schema Service Implementation Service Implementation Data Service Response Extract (via Extract Schema*) Data Service Request Query (via Query Schema*) External Service Service Description Request Description Response (e.g. WSDL) Global & Service Level Security Models

20. Data Store Relational Table Schema Service Virtual BO Instances & Other Metadata Service Business Object Schema* Data Store Model Business Object Model Service Implementation: Apply Relevant and Permitted Business Rules to Map, Merge, and Transform Service Security Model: Credentials & Authorization Rules *e.g. All service schemas are XML DTD/Schemas ===> All service "object" instances are XML "document" instances. Service Response Service Request Request Object Response Object Service Response Object Schema* Service Request Object Schema* Anatomy of a Schema Oriented Service: Metadata Rules!