|

 


 


Source:
Building Web Applications with UML Second Edition By Jim Conallen
Conallen,, 2002
Modeling Web Application Architecture with UML By:: Jim Conallen, 1999

IF3037
STEI ITB - 2008
 

ΠWeb App
ΠClient site management
ΠCookies, sessions
ΠEnabling technology
ΠCGI, compiled modules, interpreted scripts
ΠDynamic clients
ΠScript, java applet, activeX/COM
ΠDistributed object
ΠJava RMI, Microsoft DCOM
ΠXML
ΠWeb services

@
  
 

 

ΠWeb applications evolved from Web sites or
Web systems
ΠWeb application is a Web system that allows its
users to execute business logic with a Web
browser
ΠWeb applications use enabling technologies to
make their content dynamic and to allow users
of the system to affect business logic on the
server.

@
  
 
 R




@
  
 

 
 




ΠIt contains the same principal components of a
Web site:
Πa Web server,
Πa network connection, and
Πclient browsers.
ΠWeb applications also include an application
server..
server
ΠThe addition of the application server enables the
system to manage business logic and state.

@
  
 
 =




 



ΠOne common challenge of Web applications is
managing client state on the server.
ΠOwing to the connectionless nature of client and server
communications, a server doesn't have an easy way to keep
track of each client request and to associate it with the
previous request, since each and every Web page request
establishes and breaks a completely new set of connections.
ΠManaging state is important for many applications; a
single use case scenario often involves navigating
through a number of Web pages.
ΠThe W3C has proposed an HTTP state management
mechanism, more commonly known as "cookies
"cookies""

@
  
 
 =

Π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.

@
  

 
 
ΠA session represents a single cohesive use of the system.
ΠA session usually involves many executable Web pages and a lot
of interaction with the business logic on the application server.
ΠThe most common example of keeping client state on the server
can be found on the Internet at any e-
e-commerce site.
ΠThe use of virtual shopping carts is a nice feature of an online store.
ΠA shopping cart contains all the items an online customer has selected
from the store's catalog.
ΠThe shopper can check the contents of the cart at any time during the
session.
ΠThis feature requires that the server be capable of maintaining some state
about the client across a series of Web page requests.

@
  

 ë  
 

ΠEnabling technologies are the mechanism by which
Web pages become dynamic and respond to user input.
ΠThe earliest involved the execution of a separate
module by a Web server.
ΠInstead of requesting an HTML-
HTML-formatted page from the file
system, the browsers would request the module, which the
Web server interpreted as a request to load and to run the
module.
ΠThe module's output is usually a properly formatted HTML
page but could be image, audio, video, or other data.

@
  
 
 ë  
 

ΠThe original mechanism for processing user input in a Web system is the
Common Gateway Interface (CGI),
Πa standard way to allow Web users to execute applications on the server.
Πcan be written in any language and can even be scripted.
Πthe most common language for small-
small-scale CGI modules is Perl (practical
extraction and reporting language), which is interpreted each time it is executed.
ΠThe two biggest problems with CGI:
Πit doesn't automatically provide session management services
Πevery execution of the CGI module requires a new and separate process on the
application/Web server
ΠThe available solutions:
Πby adding plug-
plug-ins to the Web server.
Πthe plug-
plug-ins allow the Web server to concentrate on servicing standard HTTP
requests and deferring executable pages to another running process

@
  
 
 ë  
 

Œ Two major approaches to Web application²
application²enabling
technologies are used today:
Πcompiled modules
Πinterpreted scripts
Π= 


  are CGI-
= 
 CGI-like modules that are
compiled loadable binaries executed by the Web server.
ΠThese modules have access to APIs that provide the information
submitted by the request, including the values and names of all the fields
in the form and the parameters on the URL.
ΠThese modules produce HTML output that is sent to the requesting
browser.
ΠSome popular implementations of this approach are Microsoft's Internet
Server API (ISAPI), Netscape Server API (NSAPI), and Java servlets.

@
  
 
 ë  
 

Π


 

 looks like an




HTML page that happens to process business
logic (whereas the compiled-
compiled-module solution looks like a
business logic program that output HTML)
Πa file in the Web server's file system, contains scripts
to be interpreted by the server;
Πthe scripts interact with objects on the server and
ultimately produce HTML output.
Πsome popular vendor are Java Server Pages,
Microsoft's Active Server Pages, and PHP.

@
  
 



ë  
 

@
  
 
 Ñ =


ΠClient computers that sharing in the execution of the
business logic
ΠThe simplest examples: field and form validations
ΠA number of technologies and mechanisms share some
features:
Πassociated with the Web page and can access and modify its
content.
Πautomatically deployed, or downloaded, to the client
computer as needed.
Πaddress specific security concerns.

@
  
 
 Ñ =


  
 
ΠJavaScript is the most common scripting technology in browsers
today
Πone part of the Java technology revolution; an implementation of a
scripting language that has its roots in the Java programming language
Πeasier to learn and to use than Java
ΠJavaScript comes embedded in HTML pages, so it needs to
coexist in the document
ΠThe <script> and </script> tags, used to define regions of JavaScript.
ΠExamples:
<SCRIPT LANGUAGE="JavaScript"> alert('Hello World.') </SCRIPT>
ΠNot all browsers are JavaScript capable
Πeven though a browser is built to be robust and fault tolerant, the earliest
browsers do not gracefully handle JavaScript

@
  
 
Ñ =


  ! 


ΠThe use of Java on the client is usually in the form of an applet
ΠAn applet are:
Πmore or less a user interface control that is placed in a Web page
Πmade up of both system and custom classes
ΠA custom applet extends, or inherits, from the Java applet class.
ΠApplets are referenced by a Web page
Πneed to be identified by a tag: <object> to identify:
Πthe type of object (Java),
Πthe name of the class file to load and run, and,
Πoptionally, the location, or URL, where the file or files can be found on the network.
ΠExamples:
<OBJECT codetype="application/java" classid="java:Bubbles.class"
codebase="http://www.wae--uml.org/javaclasses/"> Java applet that draws
codebase="http://www.wae
animated bubbles. </OBJECT>

@
  
 
 Ñ =


  

"#= 
ΠActiveX is used to extend client-
client-side functionality in much the same way as
Java applets do
ΠActiveX is built on Microsoft's Component Object Model (COM)
ΠCOM is an infrastructure in which developers can build components, each in the
language of its choice, and share these objects to build bigger, more complex
systems
ΠActiveX is simply the brand name associated with a subset of COM technologies
ΠActiveX and COM can be used interchangeably
ΠActiveX object must be installed on the computer that it is to run on
ΠInstalling an ActiveX object typically means copying the DLL (dynamic link
library), EXE, or OCX file to the local hard drive and adding a few entries to the
registry
ΠBecause ActiveX objects often have dependencies on other ActiveX objects or
DLLs, these too need to be installed on the computer
ΠActiveX controls are placed in an HTML page with the <object> tag.

@
  
 
 Ñ


 $


ΠUsing distributed objects in a Web application can solve a lot of functionality
and performance issues in Web application development
ΠThe key is to incorporate the distributed object system without losing the
main benefits of a Web architecture
ΠThe most notable benefit of the Web is its ease of deployment.
ΠTo make effective use of distributed objects, there must be a way to
automatically send to the client the objects and interfaces necessary for it to
participate in the system without having the user stop the application and
install special software.
ΠTwo principal distributed object infrastructures: Java's RMI and Microsoft's
DCOM.
ΠThe goal of both is to hide the details of distributed communications and make
them the responsibility of the infrastructure, not of the class designer or the
implementer
ΠThey work on the principle of location transparency,
transparency, which states that the object
designer/implementer should never need to know the location of a given object
instance

@
  
 
 [|#||

ΠThe Java standard for distributed objects
ΠAllows Java classes to communicate with other Java classes,
which might be located on different machines
ΠJava RMI is a set of APIs and a model for distributed objects
that allows developers to build distributed systems easily
ΠThe 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-
Inter-Orb Protocol (IIOP) as the
transport protocol is preferred, making it easier to integrate with
non--Java objects
non
Πa product of the CORBA initiatives
Πbuilt--in support for this protocol is included in the latest releases of the
built
Java Development Kit (JDK)

@
  
 
 [|%





@
  
 
 [|%





ΠIntroduces two new types of object: stub and skeleton.
ΠThe stub is a client-
client-side object that represents the remote object
and executes on the client machine
ΠThe skeleton is responsible for managing all the details of being
remote³
remote ³responding to communications from objects on
another machine³
machine³and exists on the server machine
ΠYou don't have to write the code for them yourself
ΠAutomatically generated from a special compiler: rmic
ΠThis compiler creates the stub and skeleton classes from business objects
that implement certain interfaces
ΠFor example, the rmic command would take the Java class MyObject as
an argument and produce class files of the form MyObject_Skel.class and
MyObject_Stub.class

@
  
 
 [| 

ΠRMI is typically used as a communication mechanism
between an applet and an application server
ΠThe applet is part of a Web page
Πrequire a Java-
Java-enabled Web browser
Πall the classes necessary to invoke and to use remote objects
will be downloaded to the client as necessary
ΠOnce the client applet is run, it can contact the remote
server, request a remote object instance reference, and
begin to invoke methods on it as if it were a local object
instance.
ΠAll marshalling of protocols is handled by the stub and
skeleton classes and the RMI infrastructure

@
  
 
  

 [|

@
  
 
 Ñ= Ñ


= 
ΠMicrosoft's solution to the distributed-
distributed-object problem
Πan extension to the popular Component Object Model (COM)
ΠIsolates the object developer from the details of distributing an object
ΠGives the object developer independence from the distributed-
distributed-object
infrastructure
ΠCOM object implementations are assigned special class identifiers (CLSID)
ΠClients who want instances of a particular COM object, request them with the
CLSID from the operating system
ΠWhen the client machine has the DCOM-
DCOM-supporting facilities installed, it is
possible for these objects to be located on a remote server
ΠWhen a client creates an object instance, the following happens:
ΠThe client calls CoCreateInstance() on a CLSID supported by a local server
ΠThe DCOM runtime, working with the SCM (service control manager), determines
whether the requested local server is running and can be connected to
ΠThe client is provided with a reference to an interface proxy to the object.
ΠIf an existing instance of the object is available, it will be used; otherwise, a new
instance is created

@
  
 
 

&'Ñ= 




@
  
 
 Ñ= 




ΠUses a scheme similar to RMI and CORBA
Πcreating proxy and stub objects to act as interfaces
between the client program, or server object
implementation, and the COM infrastructure
ΠThe existence of these objects, invisible to the
implementer, is provided by DCOM

@
  
 
 Ñ=  

ΠWeb pages contain ActiveX controls
downloaded to the client and executed
ΠAlong with these controls, proxy objects can be
downloaded and registered to point to
implementation objects on the appropriate
application server

@
  
 
 O
'


$

 


@
  
 
 "%
ΠAn XML-
XML-formatted document is a text document that defines a hierarchical
collection of elements.
ΠAn element is one part of a document and usually contains a textual value
ΠAn element can have child elements and thus form a hierarchy
ΠEvery XML document begins with one root element
ΠElements can be enhanced with attributes, which are just key/value pairs
ΠElements have bodies that can contain free-
free-form text, with some restrictions
ΠXML offers the basic rules for formatting generic documents
Πsimple parsers can read and validate their contents
Πwith the availability of free parsers, development teams are more likely to adopt
XML document structures as a standard
ΠMost content of an XML document is textual
Πelements of the document can point to, but not directly contain, nontextual
resources, such as images or applications
ΠBy describing documents with XML, generic XML parsers can be used to
extract the document's structure

@
  
 
 "%
( 

"%
<address>
<street>123 Pine Rd.</street>
<city>Lexington</city>
<state>SC</state>
<zip>19072</zip>
</address>

@
  
 




Π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 is Web services make RPC practical by
providing a set of standards for discovering and invoking the
services
ΠThe standards:
ΠSOAP
ΠUDDI
ΠWSDL

@
  
 
  

ΠSimple Object Access Protocol
ΠBuilt on top of XML
Πa SOAP message is simply an XML-
XML-formatted document that validates
against a certain DTD or schema.
Œ When used with HTTP, SOAP messages³
messages³documents
documents³ ³can be
sent to Web servers, which invoke the specified function defined
by the Web service.
ΠThe full specification for SOAP 1.1 can be found at
http://www.w3.org/TR/SOAP..
http://www.w3.org/TR/SOAP
ΠA SOAP message consists of:
Πa mandatory SOAP envelope; is the top element of the XML document
Πan optional SOAP header; is a way messages can be extended in the
future with prior knowledge
Πa mandatory SOAP body

@
  
 
 OÑÑ|
ΠUniversal Description, Discovery, and Integration
ΠA mechanism for publishing and describing Web
services to potential clients
ΠIs a set of replicated registries of information about
Web services on the network.
ΠRegistration of a service involves four core data structure
types: business information, service information, binding
information, and specification information

@
  
 
 Ñ%
ΠWeb Services Description Language
ΠA more detailed specification of the SOAP interface
ΠA WSDL specification describes in detail how to invoke a Web
service and what to expect when it responds
ΠA WSDL description defines a Web service as a collection of
network end points, or ports
ΠEach port defines a collection of operations that can be invoked.
ΠEach operation includes a set of input and output messages: the
parameters.
ΠA binding maps a port type to a specific protocol, HTTP, and data
format, SOAP.
ΠA port instantiates a port type and binding at a specific network address.

@
  
 
  



 

  


 

@
  
 
 Ñ

 

'




@