Just now i completed reading Building Web Applications with UML Second Edition By Jim Conallen
Nice book but to be frank i donot think in many web projects people finish sequence,collaboration etc diagrams before writing code.
I want to know from reader's comments about their experiences about web projects development.
Here in our project we do reverse engineering and yes produce diagrams from code. :-)
Below are the points i wanted to share with readers from this book.
1) Web applications evolved from Web sites or Web systems. The first Web sites, created by Tim Berners-Lee while at CERN (the European Laboratory for Particle Physics), formed a distributed hypermedia system that enabled researchers to have access to documents and information published by fellow researchers, directly from their computers.
2) The full identifier for referencing and obtaining the document is called a uniform resource locator (URL).When a client requests a URL, the request must be made directly to the host computer. This means that the host name identified in the URL must be resolved into a numeric IP address. This process is done with a domain name server (DNS). A DNS is a network computer that the client has access to and that has a known IP address.Network infrastructure software on the client knows how to request the IP address from a DNS for a given domain name.
3) "URI stands for Universal Resource Identifier and URL stands for Universal Resource Locator. Often times people use the terms interchangably, which is not entirely correct. A URL is a subset of the URI popular protocols. These are protocols (http://, ftp://, mailto:). Therefore all URLs are URIs. The term URL is deprecated and the more correct term URI is used in technical documentation. All URIs are means to access a resource on the Internet and are a a technical short hand used to link to the resource. URIs always designate a method to access the resource and designate the specific resource to be accessed."
Wikipedia says
A URI may be classified as a locator (URL) or a name (URN) or both.
A Uniform Resource Name (URN) is like a person's name, while a Uniform Resource Locator (URL) is like their street address. The URN defines something's identity, while the URL provides a method for finding something. Essentially, "what" vs. "where".
A typical URN is the ISBN system for uniquely identifying books. ISBN 0486275574 (urn:isbn:0-486-27557-4) cites unambiguously a specific edition of Shakespeare's book "Romeo and Juliet". In order to gain access to this object and read the book, one would need its location: a URL address. A typical URL for this book is a file path, like file:///C:/MyDocuments/RomeoAndJuliet.pdf, identifying the electronic book saved in a local PC hard disk. So the purposes of URNs and URLs are complementary
4) HTTP runs over TCP (Transmission Control Protocol), but could run over any connection-oriented service. TCP, a lower-level network protocol used by the Internet and many company networks, enables computers to make
connections and to exchange information with one another. TCP, usually combined with IP, is an implementation of layers in the OSI (Open Systems Interconnection) model for network communications.
HTTPS—HTTP with Secure Sockets Layer (SSL)—is related to HTTP but uses encryption to help "secure" the communication. HTTPS is used on the Internet for handling sensitive data such as personal and financial information.
5) Browsers, in addition to establishing the network connections and protocols for document interchanges, need to render the document on a display. TCP/IP and HTTP don't address this at all. The rendering of content is managed by the browser. This is where the Hypertext Markup Language (HTML) fits in.
6) A cookie is a piece of data that a Web server can ask a Web browser to hold on to, and to return every time the browser makes a subsequent request for an HTTP resource to that server. Typically, the size of the data is small, between 100 and 1K bytes;however, the official limit is around 4K. Initially, a cookie is sent from a server to a browser by adding a line to the HTTP headers
7) JavaScript is object based, not objected oriented, meaning that it uses built-in extensible objects but does not support user-defined classes or inheritance.Because JavaScript is not compiled, it uses dynamic binding, and all object references are checked at runtime.
8) Initial release of the RMI API used Java serialization and the Java Remote Method Protocol (JRMP) to make method invocations across a network look like local invocations.Today, the use of Internet Inter-Orb Protocol (IIOP), a product of the CORBA initiatives, as the transport protocol is preferred, making it easier
to integrate with non-Java objects.Operations that accept Java object references as parameters might not be usable in IIOP-based systems
9) A Web service is a collection of functions packaged and published on a network for use by other client programs.From the highest levels of abstraction, a Web service is simply another type of remote procedure call (RPC). The difference,however, is what Web services bring to the concept of RPC. Much as component models—COM and JavaBeans—have made component reuse practical, Web services make RPC practical by providing a set of standards for discovering and invoking the services
10) A certificate authority (CA) is a third-party organization that can be trusted by both the server organization and the individual client.
11) The class loader is responsible for locating and fetching the class file, consulting the security policy,
and defining the class object with the appropriate permissions.
12) One option to limit access to intranet-based Web applications is to establish a firewall between the intranet and the Internet.Most companies maintain a firewall to insulate their internal systems from the external world; they are relatively easy to install and maintain. Firewalls, however, are no guarantee that an intruder or a disgruntled employee won't gain access.
13) A workflow is set of activities—requirements, analysis, design, implementation, testing, and deployment—that ultimately produce a tangible and observable result.
14) In many of these organizations, unfortunately, testing is usually done in an unorganized way. In fact, in one project Author had the privilege of working on, the testing team, consisting of three full-time specialists, never even wrote a test plan! They simply got a release and started hacking.
15) The three most common patterns for the presentation tier are thin Web client, thick Web client, and Web delivery.
a) The thin Web client is used mostly for Internet-based applications, in which there is little control of the client's configuration. The client requires only a standard forms-capable Web browser. All the business logic is executed on the server.
b) The thick Web client pattern is used when an architecturally significant amount of business logic is executed on the client machine. Typically, the client uses dynamic HTML, Java applets, or ActiveX controls to execute business logic.Communication with the server is still done via HTTP.
c) The Web delivery pattern is used when the Web browser acts principally as a delivery and container device for a distributed object system. In addition to HTTP for client and server communication, other protocols, such as IIOP and DCOM, may be used to support a distributed object system.
16) Dynamic content in a screen is a complex subject. In the last few years, the distinction between Web applications and Web sites has continued to blur. As a result, an entire new branch of software/information technology has emerged—content management—as well as a new class of off-the-shelf software systems: content management systems (CMSs). These systems have evolved to meet a primary business need: how to manage the change of the information presented to the users of Web sites and applications.
17) When defining packages, you should strive to ensure that
they are
a) Comprehensible: An individual is expected to comprehend the package's semantics, reason for existence, major elements, and responsibilities.
b) Cohesive: Logically speaking, the classes belong together. At some abstraction, all the classes in the package form a natural group.
c) Loosely coupled: Generally, each class has more relations with classes in the same package than with classes outside the package.
d) Shallow hierarchy: Deep hierarchies tend to be difficult to understand because each level carries its own meanings. It is best to limit the number of levels to two or three.
About the Author
Jim Conallen
Jim Conallen is the Web Modeling Evangelist at Rational Software Corporation, where he has continued his work on the development of the Web Application Extension for the Unified Modeling Language. Prior to joining Rational, he was a consultant specializing in full life cycle object-oriented development. He has built client/server and web-based systems in the transportation, telecommunications, and health care domains; has architected large, high-volume transaction processing systems; and has designed and developed applications in C++, Smalltalk, Java, Delphi and Visual Basic. Jim is a frequent speaker on topics ranging from web application modeling to software best practices. He has written for many industry publications, including ASPToday.com, Rose Architect, and Communications of the ACM
Hope you enjoy reading this book
Wednesday, 18 June 2008
Subscribe to:
Post Comments (Atom)
1 comment:
Nicely done Prashant.
Post a Comment