Translate

Pages

Friday, 30 March 2012

Web Services architectures from Borland


Borland offers cross-platform development by, for example, using Delphi 6 to create Web Services running on IIS for Windows and then take that same code to Linux, recompile using Kylix 2, and deploy on Apache Web servers. The Internet protocols they use to expose internal Web Services and access external Web Services include: SOAP, WSDL, UDDI, BTP, and ebXML.

Web Services architectures from Halwet-packed


In May 1999, HP was the first to develop a Web Services platform under the name E-speak. Hewlett-Packard kept quiet as Microsoft, Oracle, and IBM responded, until March 2001 when it put a large number of software products together in two groups. 

Web Services architectures from Oracle


The core of the Oracle9iWeb Services framework is the Web Service Broker, a J2EE execution engine deployed in Oracle9i Application Server. 
Application developers can access the engine using the Oracle Web Services Java client APIs that provide
a level of abstraction over the communication protocol to connect to the execution engine (direct Java method calls,
PL/SQL calls, HTTP, HTTPS, or JMS (Java Message Service) messages).

Web Services architectures from Sun


Sun Open Net Environment (Sun ONE) is an open framework to support "smart" Web Services, and in which the Java 2 Platform Enterprise Edition (J2EE) platform plays a fundamental role. 
The Sun ONE Web Services developer model shows how developers can build Web Services, using XML, servlets, JavaServer Pages, EJB architecture, and Java technologies, as shown below. Note that EJB wrappers allow existing applications to become Web Services.

Web Services architectures from Microsoft


Microsoft
On May 24, 2000, Microsoft announced it had posted three additional specifications on its XML Web Service Web site:
XLANG, SOAP-Routing, and Direct Internet Message Encapsulation (DIME) protocol, a method of packaging up attachments
in SOAP messages. SOAP-Routing along with DIME, however, were not included in .NET My Services (formerly
codenamed "HailStorm"). This was because the Global XML Web Services Architecture (GXA) replaced SOAP-Routing
with WS-Routing which supports one- and two-way messaging, including peer-to-peer conversation and long-running dialogues.
The global architecture builds upon the foundation of baseline specifications - SOAP, UDDI, and WSDL among others. In
April 2001, Microsoft and IBM co-presented their vision of this architecture to the W3C Workshop on Web Services. Both
vendors contributed to the development and implementation of the W3C Web Services Architecture Stack - more complex
than their own versions.

Layer
Type
WS-Inspection, WS-License,
WS-Referral, WS-Routing,
WS-Security

Global Architecture
UDDI, WSDL, XML, SOAP

Baseline Architecture




The GXA is modular, meaning that you can use one specification with another to address a set of specific requirements.

For example, WS-Referral does not explicitly specify security, but rather relies on other specifications in the architecture
to enable the routing strategies used by the SOAP nodes in a message path.
Other specifications for the global architecture are:
WS-Inspection assisting in the inspection of a site for available services. Due to the decentralized nature of Web
Services, this specification doesn't work well if the communication partner is unknown. In such cases, you would be
better off with UDDI. This specification (also known as WSIL) was announced by both IBM and Microsoft to the W3C
in November 2001. It is another service discovery mechanism
(http://www-106.ibm.com/developerworks/library/ws-wsilover/index.html) and is complementary to UDDI
(http://www.webservicesarchitect.com/content/articles/modi01.asp).
WS-License describing a set of commonly used-license types and how they can be placed within the WS-Security
"credential" tags, such as X.509 certificates and Kerberos tickets.
WS-Routing referring to a simple, stateless, SOAP-based protocol for controlling the route of SOAP messages in an
asynchronous manner over a variety of transports such as TCP, UDP, and HTTP.
WS-Security describing enhancements to SOAP-messaging to provide three capabilities: credential exchange, message
integrity, and message confidentiality, each of which you could use by itself or in combination with another as a way of
contributing to a security model.
Additional specifications will become available as Microsoft releases them for public review.
To accommodate the architecture, Microsoft offers the .NET Framework as a platform for building, deploying, and running
XML Web Services and applications. It allows a Web Service consumer send and receive information in a loosely coupled
manner, including a description of the Web Services that it and other consumers offer. SOAP is supported by XML Schema
Datatypes (XSD), WSDL, XML, and HTTP.
As part of the Microsoft .NET initiative, Microsoft provides a user-centric architecture and a set of XML Web Services, collectively
called Microsoft .NET My Services. Using .NET Passport as the basic user credential, the .NET My Services architecture
defines identity, security, and data models that are common to all services and can help orchestrate a wide variety
of applications, devices, and services - all in one basket.
The initial set of .NET My Services includes:
.NET Profile. Name, nickname, special dates, picture, address.
.NET Contacts. Electronic relationships/address book.
.NET Locations. Electronic and geographical location and rendezvous.
.NET Alerts. Alert subscription, management, and routing.
.NET Presence. Online, offline, busy, free, which device(s) to send alerts to.
.NET Inbox. Inbox for items like e-mail and voice mail, including existing mail systems.
.NET Calendar. Time and task management.
.NET Documents. Raw document storage.
.NET ApplicationSettings. Application settings.
.NET FavoriteWebSites. Favorite URLs and other Web identifiers.
.NET Wallet. Receipts, payment instruments, coupons, and other transaction records.
.NET Devices. Device settings, capabilities.
.NET Services. Services provided for an identity.
.NET Lists. General purpose lists.
.NET Categories. A way to group lists.

W3C



The W3C Web Services Workshop, led by IBM and Microsoft, has agreed that the architecture stack consists of three components:
Wire, Description, and Discovery.
Wire Stack
The following table shows what layers constitute the Wire Stack.





As you will notice, this Wire Stack has extensions to two layers: SOAP and XML. This means whenever the SOAP is used
as the envelope for the XML messages, they must be attached, secure, reliable, and routed to the intended service requester
or provider. In the stacks of other organizations, SOAP and XML are not treated as "extensions." IBM, for instance, refers
to SOAP as a tool for its stack layer, "XML-Based Messaging."
Description Stack
The Description Stack, the most important component, consists of five layers:




This stack starts with orchestration of business processes from which the messages are sequenced, depending on how service
capabilities are configured. Whatever comes out of the proposal on combining WSFL and MS XLANG that IBM and
Microsoft submitted to the W3C last year will be the tool for the Business Process Orchestration Layer. What needs to be
resolved is to consider what parts of WSFL and MS XLANG are more open than the other: transition-based versus blockstructured
based control flow, and extending versus complementing WSDL among others.
The Service Capabilities Layer is similar to IBM's WSEL as mentioned in IBM WSCA 1.0 and WSFL 1.0 (http://www-
4.ibm.com/software/solutions/Webservices/pdf/WSFL.pdf). Like IBM, the W3C uses WSDL to describe service interface
and service implementation, neither of which is explicitly highlighted in other stacks. WSDL may use a hefty chuck of XML
Schema and takes advantage of SOAP/HTTP bindings to WSDL. SMTP, Reliable HTTP (HTTPR), and HTTP Get are
other possible bindings that could be used.
Discovery Stack
As the name implies, the Discovery Stack involves the use of UDDI, allowing businesses and trading partners to find, discover,
and inspect one another in a directory over the Internet, as follows:







The Inspection Layer refers to WSIL (Web Services Inspection Language) and WS-Inspection specifications. Please refer
to the Microsoft section below for more information on WSIL.
Putting all three stack-components together, we have the Architecture Stack.


















IBM


The IBM Conceptual Web Services stack is part of their Web Services Conceptual Architecture (WSCA) 1.0 (http://www-
4.ibm.com/software/solutions/Webservices/pdf/WSCA.pdf). It is presented in a slightly different way than that of the first
two stacks, by starting with Web Services tools and then showing what each layer is used for.


The IBM Web Services stack does not show WSCL and ebXML, included in the WebServices.Org stack. It associates the
Network layer with IBM MQSeries (now called WebSphere MQ) messaging systems and the Internet Inter-ORB Protocol
(IIOP) - a protocol CORBA uses to transmit data, information, and messages between applications. They do not appear in
either that of WebServices.Org or The Stencil Group. IBM considers WSDL as a description of the service endpoints where
individual business operations can be accessed. WSFL uses WSDL for the description of service interfaces and their protocol
bindings. WSFL also relies on WSEL (Web Services Endpoint Language), an endpoint description language to
describe non-operational characteristics of service endpoints, such as quality-of-service properties.
Together, WSDL, WSEL, and WSFL provide the core of the Web Services computing stack. IBM perceives UDDI in two
categories: static and direct. Static UDDI refers to the Service Directory established after applying WSFL to Service Flow,
while direct UDDI pertains to the Service Publication of directory items. Similar to the WebServices.Org stack, the IBM
stack applies QoS, management, and security to all layers.
As of May 2001, IBM announced software and tools that enable businesses to create, publish, securely deploy, host, and
manage Web Services applications, using the IBM Web Services stack as the framework. They include WebSphere
Application Server Version 4.0, WebSphere Studio Technology Preview for Web Services, WebSphere Business Integrator,
DB2 Version 7.2, Tivoli Web Services Manager (to monitor performance of all aspects of the Web Services environment),
and Lotus software suite (to enable Web collaboration, knowledge management, and distance learning). WebSphere was
originally the collective name of IBM's J2EE application server family. It has since been stretched to include most of their
middleware and application development offerings, such as MQSeries Workflow (now known as WebSphere Process
Manager). IBM currently offers a Web Services ToolKit (WSTK) to help in designing and executing Web Service applications,
and enabling them to find one another and collaborate in business transactions without programming requirements
or human intervention.


Tools
layers
TPA (Trading Partner Agreement)
Service Negotiation
WSFL
Service Flow
UDDI+WSEL
Service Description
Service Publication (Direct UDDI)
Service Directory
(Static UDDI)
Endpoint Description

WSDL
Service Interface
Service Implementation
SOAP
XML-Based Messaging
HTTP, FTP, email, MQ, IIOP
Network
Quality of ServiceManagement, Security
, Business Issues



The Stencil Group



Now, let's take a look at the Stencil Group's Web Services technology stack. It is similar to that of WebServices.Org with
three exceptions:
1. The WebServices.Org stack does not divide the layers into emerging and core components. Not doing so could confuse
the reader as to which standards are emerging. What is now an emerging standard would become a core standard at a
future date.
2. The Stencil Group does not apply Management, Quality of Service, Open Standards, and Security to any layer. The
reader could get the wrong impression that they are proprietary and treated as not important. When this happens, the
reader will opt for another architecture stack that has these features.
3. The Stencil Group starts the stack with undefined business rules while WebServices.Org begins with a clearly defined
business process such as service agreement. The reader could get confused on what undefined business rules are, and
how many would eventually be defined.


Layer
Type
Other Business Rules (undefined)




Emerging Layers
Web Services Flow Language (WSFL)

Universal Description, Discovery and Integration (UDDI)                     
Web Services Description Language (WSDL)

Simple Object Access Protocol (SOAP)





Core Layers


Extensible Markup Language (XML)                                                     
Common Internet Protocols (TCP/IP, HTTP)


WebServices.Org

The following is the Web Services stack from WebServices.Org.

Service Negotiation
The business logic process starts at the Services Negotiation layer (the top) with, say, two trading partners negotiating and
agreeing on the protocols used to aggregate Web Services. This layer is also referred to as the Process Definition layer, covering
document, workflow, transactions, and process flow.
Workflow, Discovery, Registries
The stack then moves to the next layer to establish workflow processes using Web Services Flow Language (WSFL) and
MS XLANG, which is an XML language to describe workflow processes and spawn them. Microsoft previously achieved
recognition for WSDL by working with IBM. History may repeat itself since IBM now has a similar technology to XLANG.
In April 2001, IBM published WSFL. Gartner expected IBM and Microsoft to jointly agree to submit a proposal to W3C
to combine XLANG and WSFL by the end of 2001. Yet, the W3C Web site has not indicated whether it has received the
proposal for consideration. If it did, the proposal has not yet been posted on the Web site (February 2002).
WSFL specifies how a Web Service is interfaced with another. With it, you can determine whether the Web Services should
be treated as an activity in one workflow or as a series of activities. While WSFL complements WSDL (Web Services
Definition Language) and is transition-based, XLANG is an extension of WSDL and block-structured based. WSFL supports
two model types: flow and global models. The flow model describes business processes that a collection of Web
Services needs to achieve. The global model describes how Web Services interact with one another. XLANG, on the other
hand, allows orchestration of Web Services into business processes and composite Web Services. WSFL is strong on model
presentation while XLANG does well with the long-running interaction of Web Services.
You may declare a Web Service as private, meaning that it cannot expose details of what it does to public applications. You
can create Web Services with the WebMethod Attribute in Visual Basic.NET, or with EJB wrappers for existing J2EE applications
in either the Internet (public) or intranet (private) environment. You may declare them as public or private methods
when you code.
Among the software supporting WSFL is IBM MQ Series Workflow (now known as WebSphere Process Manager) that
automates business process flows, optimizes Enterprise Application Integration (EAI) with people workflow, provides scalability,
and complies with the Workflow Coalition and multi-platform capabilities. MS XLANG is the language implemented
in BizTalk.
Web Services that can be exposed may, for example, get information on credit validation activities from a public directory
or registry, such as Universal Description, Discovery and Integration (UDDI). The ebXML, E-Services Village, BizTalk.org,
and xml.org registries and Bowstreet's (a stock service brokerage) Java-based UDDI (jUDDI) are other directories that
could be used with UDDI in conjunction with Web Services for business-to-business (B2B) transactions in a complex EAI
infrastructure under certain conditions. Web Services is still primarily an interfacing architecture, and needs an integration
platform to which it is connected. Such an integration platform would cover the issue of integrating an installed base of
applications that cannot work as Web Services yet.
The first release of UDDI's Business Registry became fully operational in May 2001, enabling businesses to register and discover
Web Services via the Internet. Its original intent was to enable electronic catalogues in which businesses and services
could be listed. The UDDI specification defines a way to publish and discover information about services. In November
2001, the UDDI Business Registry v2 beta became publicly available.
Hewlett Packard Company, IBM, Microsoft, and SAP launched beta implementation of their UDDI sites that have conformed
to the latest specification, including enhanced support for deploying public and private Web Service registries, and
the interface (SOAP/HTTP API) that the client could use to interact with the registry server. In addition to the public UDDI
Business Registry sites, enterprises can also deploy private registries on their intranet to manage internal Web Services using
the UDDI specification. Access to internal Web Service information may also be extended to a private network of business
partners.
Service Description Language
As you move further down the stack, you need WSDL to connect to a Web Service. This language is an XML format for
describing network services. With it, service requesters can search for and find the information on services via UDDI,
which, in turn, returns the WSDL reference that can be used to bind to the service.
Web Service Conversational Language (WSCL) helps developers use the XML Schema to better describe the structure of
data in a common format (say, with new data types) the customers, Web browsers, or indeed any XML enabled software



programs can recognize. This protocol can be used to specify a Web Service interface and to describe service interactions.
Messaging


Now, we get to the Messaging layer in the stack where SOAP acts as the envelope for XML-based messages, covering message
Web Services as the work progresses (say, from customer order to shipping product out of the warehouse).
packaging, routing, guaranteed delivery and security. Messages are sent back and forth regarding the status of variousTransport Protocols
When a series of messages completes its rounds, the stack goes to its last layer: the transport layer using Hypertext Transfer
Protocol (HTTP), Secure HTTP (HTTPS), Reliable HTTP (HTTPR) File Transfer Protocol (FTP) or Standard Mail Transfer
Protocol (SMTP). Then, each Web Service takes a ride over the Internet to provide a service requester with services or give
a status report to a service provider or broker.
Business Issues
Finally, the Business Issues row in the table lists other key areas of importance to the use and growth of Web Services.
Without consideration to these points, Web Services could quickly become objects of ridicule.
Layer
Example
Service Negotiation
Trading Partner Agreement

Workflow, Discovery, Registries
UDDI, ebXML registries, IBM WSFL, MS XLANG

Service Description Language
WSDL/WSCL

Messaging
SOAP/XML Protocol

Transport Protocols
HTTP, HTTPS, FTP, SMTP

Business Issues
Management, Quality of Service, Security, Open Standards

Web Service Architecture


Web Service Architectures


With Web Services, information sources become components that you can use, re-use, mix, and match to enhance Internet
and intranet applications ranging from a simple currency converter, stock quotes, or dictionary to an integrated, portalbased
travel planner, procurement workflow system, or consolidated purchase processes across multiple sites. Each is built
upon an architecture that is presented in this paper as an illustrated stack of layers, or a narrative format.
Each vendor, standards organization, or marketing research firm defines Web Services in a slightly different way. Gartner,
for instance, defines Web Services as "loosely coupled software components that interact with one another dynamically via
standard Internet technologies." Forrester Research takes a more open approach to Web Services as "automated connections
between people, systems and applications that expose elements of business functionality as a software service and create
new business value."
For these reasons, the architecture of a Web Services stack varies from one organization to another. The number and complexity
of layers for the stack depend on the organization. Each stack requires Web Services interfaces to get a Web Services
client to speak to an Application Server, or Middleware component, such as Common Object Request Broker Architecture
(CORBA), Java 2 Enterprise Edition (J2EE), or .NET. To enable the interface, you need Simple Object Access Protocol
(SOAP), SOAP with Attachments (SwA), and Java Remote Method Invocation (RMI) among other Internet protocols.
Although we have a variety of Web Services architectures, Web Services, at a basic level, can be considered a universal
client/server architecture that allows disparate systems to communicate with each other without using proprietary client
libraries, according to the WebMethods whitepaper, Implementing Enterprise WebServices with the WebMethods
Integration Platform (December 2001). The whitepaper points out that "this [architecture] simplifies the development
process typically associated with client/server applications by effectively eliminating code dependencies between client and
server" and "the server interface information is disclosed to the client via a configuration file encoded in a standard format
(e.g.WSDL)." Doing so allows the server to publish a single file for all target client platforms.
For the purposes of this paper, we present the architecture stacks starting with the most simple, proceed to the more complex
ones, and then compare them. After this, we will cover other architecture types from Microsoft, Sun ONE, Oracle,
Hewlett-Packard, BEA Systems, and Borland.




Based on initial findings or the current state of implementations, IBM's architecture is most acceptable. All architectures
will eventually come into one umbrella, as there is a risk that if companies go away and keep on building their own extensions
to the basic architecture stack, the promise of Web Services could be lost. The IBM versions, current and future, could
serve as an industry-wide Standard Stack model, after W3C accepts new standards resulting from, for example, the convergence
of IBM WSFL and Microsoft XLANG on workflow processes.





Tuesday, 27 March 2012

SPECIAL HTML CHARACTERS


SPECIAL HTML CHARACTERS
In order to include a copyright symbol, certain math equations, and other non-standard characters on your
Web page, you will need to include special characters in your HTML coding. To do this, you will use a table of
characters called the ISO-8859-1 Latin-1 Table (http://www.htmlhelp.com/reference/charset/). You can
include the Latin-1 characters in your coding by either typing in a numeric character reference (") or an
entity reference (") when you write your HTML code.
For instance, a standard double quotation mark ( “ ) is defined as either " using numeric characters or
" using an entity reference. Either way, your visitors see a plain quotation mark.
Other handy special characters include:
•  Registered trademark: ® or ®
Introduction to HTML – UM University Libraries 18
•  Copyright symbol: © or ©
• & Ampersand: & or &
• ° Degree sign: ° or °
• Non-breaking space:   or  
From: http://www.netmechanic.com/news/vol5/html_no11.htm - HTML Tip: Learn To Speak Latin

HTML VALIDATION



HTML VALIDATION
Once you have finished a page, make sure your coding is valid by checking your documents against the
W3C’s HTML validator at:
http://validator.w3.org/
This program will pick out all HTML errors, and it is a good idea to perform this step even if your document is
displaying perfectly.
NOTE: All pages using the Libraries’ templates have coding included within them that facilitate the use of the
HTML validator. If you want to use the HTML validator on your own page (or you are editing an older page on
the Library server), type this at the very beginning of your document, before the <HTML> tag:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
Then use the HTML validator to check your coding.

Troubleshooting and Helpful Hints


Troubleshooting and Helpful Hints
If your code doesn't display as you think it should, there are several things you can do:
1. Press the “Reload” button. The browser you are using to preview your web page may be displaying the
previous version of your document.
2. Ask someone who is more experienced to look over your document, and be sure to preview your document
in Netscape, Firefox, and Internet Explorer as you are developing it. Page elements may appear differently in
each of these browsers, and you need to be aware of this as you are creating your page.
3. Be sure you have used an ending tag wherever required. Omitting the ending tag (or forgetting the slash
within it) is a common error.
4. If a link is not working, make sure you typed quotation marks before and after the URL. Make sure you
have the entire URL, including http://. Check to see whether you've made any capitalization or spelling errors
within the URL.
Introduction to HTML – UM University Libraries 17
5. With your page displayed in Netscape or Firefox, click on “View”, then “Page Source”. This will show your
HTML document with tags and attributes in a different color from the text. This format makes it easier to see
your tags and figure out what is wrong.
6. Break up the information you have on your site into coherent "chunks" rather than placing unrelated
information all together on one long page. These smaller chunks make it easier for people to link to the specific
information that interests them at your site.
7. Visit the Information Technology Division’s “Web Author Resources” page for more suggestions, tips, and
hints: http://www.lib.umd.edu/itd/web/resources.html/.
8. Use the World Wide Web Consortium’s (W3C) HTML validator service (described below).

Using WebSpinner


Using WebSpinner
WebSpinner is the way in which files are loaded onto the Library server. To use WebSpinner, log in at:
http://www.lib.umd.edu/cgi-bin/WebSpinner and choose the appropriate directory from the welcome screen.
To Create A New File:
􀂾 Select the appropriate directory where you want to load your file.
􀂾 Select New File , and enter the File Name (which must end in one of the following: .pdf if a PDF,
.html if an HTML file, .jpg if a JPEG, .gif if a GIF).
􀂾 Click on Browse to upload the local file to the server.
􀂾 Click on Create File . Your file should appear in the file list box. You may then launch a
second browser and type in the URL of your file to view it. Make changes as needed.
NOTE: You would follow this process to upload any type of file to the server (.pdf, .jpg, .gif, .html). To upload
multiple files – contact Web Services at webservices@itd.umd.edu, for instructions on how to FTP files and
use the “Upload” feature in WebSpinner.
To Update An Existing File:
􀂾 Select the appropriate directory where you want to edit the file.
􀂾 Highlight the file name, and press .
􀂾 Either edit the file as needed and press Update File when you are finished, or copy and
paste the entire text to notepad, edit the file as needed, and then use the Browse and Update File
buttons to upload your local copy.
Introduction to HTML – UM University Libraries 15
NOTE: Do NOT save a file from the website through your browser and then upload it to the site. This will
“break” several features of our web pages, such as included files (the header image, etc.).
If you need to change directories when working on pages, choose the button.
To delete a file from the server, select the file name from the list, and choose the button. At the
“Delete Confirmation” screen, select . (If you change your mind, use your browser's "Back" button to
cancel the deletion.)
NOTE: If you rename, move, or delete a file – first check to see who is linking to it at Link Checking
(http://www.lib.umd.edu/itd/web/link/all/ALL.html), and notify the information providers.
When you have finished editing your pages in WebSpinner, select the button.
REMINDER: If you have questions or problems with WebSpinner, contact Web Services at
webservices@itd.umd.edu.
Let’s use WebSpinner to load our file into the “Junk” directory. Go to WebSpinner (using the URL above, or by
going to the Library Home Page – http://www.lib.umd.edu, and choosing Web Credits and Maintenance 􀃆
Web Author Resources 􀃆 WebSpinner). Follow the steps below to preview your page on the web server.
􀂾 At the WebSpinner welcome screen, choose the /JUNK directory,
and click “Go to directory”.
􀂾 When you are in the /JUNK directory, scroll down until you see the
html101/ subdirectory, and select Open
􀂾 Select New File , and enter the File Name of the file you had saved on your A: drive (remembering
it must end in .html).
􀂾 Click on Browse to upload the local file to the server.
Introduction to HTML – UM University Libraries 16
􀂾 As the “Create File” screen indicates, any file uploads will override existing document text
􀂾 Click on Create File . Your file will be added to the /JUNK/html101 directory.
􀂾 To view your file, open a new browser window, and type in the URL (for example:
http://www.lib.umd.edu/JUNK/html101/myinitialspage.html).
􀂾 After viewing, delete your file from the /JUNK/html101 directory by locating the file name in WebSpinner,
highlighting the name, and choosing Delete . At the “Delete Confirmation” screen, select
.
􀂾 Once you are finished in WebSpinner, log off by choosing the button.
UMD WebSpinner Tutorial – available online at: http://www.webhosting.umd.edu/howto/wsthost/
NOTE: This tutorial was created by OIT, when WebSpinner was “launched” in 2000. The Libraries revised
WebSpinner for internal use, so some items covered in the tutorial (such as the TEXT->HTML, Security, Style
Template, Showpics and Prefs buttons) are not applicable to us.

UM Library Templates


UM Library Templates
All Web pages on the UM Libraries' site should follow the consistent look and feel designed for the site. To
facilitate this, there are several different templates available for you to use. The templates are found at:
http://www.lib.umd.edu/itd/web/templates/
Generic Templates
o Basic template -- May be used for pages that are best suited for using paragraph tags as the major
text divisions. (For example: http://www.lib.umd.edu/ASD/LPO/AdminMemos/memo5.html -
“Administrative Memo #5: Issuing of Keys.”)
o Left column template – Used for pages that have menu items or quick links in the left column. (For
example: http://www.lib.umd.edu/PUB/staffhome.html- The “Staff and Organization” page.)
Specialized Templates
o Professional profile (no image) -- may be used for your "Professional" page.
o Professional profile (w/image) -- may be used for your "Professional" page with an image.
o Minutes template
o Guides to Information Resources template -- for use by subject specialists.
o Course Related Web Pages -- for pages created to support a specific class at UM.
There are also templates for usability testing and forms.
In order to use the templates, do the following:
􀂾 Open a template. Based on the examples provided, choose the layout which best suits your needs.
􀂾 Copy the template code. Click on the link that takes you to the source code for the template you
want to use. With the template mark-up visible in your browser, go to Edit 􀃆 Select All. Copy the
highlighted selection by choosing Edit 􀃆 Copy. NOTE: Be sure to use Select All so that the entire
template is copied.
􀂾 Open a new document in Notepad.
􀂾 Paste the template code into the Notepad document. In the Notepad document, choose Edit 􀃆 Paste.
The complete code you copied from the template will appear.
Introduction to HTML – UM University Libraries 14
􀂾 Name your document and save it as a web page. Use lowercase letters, with no spaces. Make sure
that you include the file extension .html at the end.
􀂾 Edit the code and add the content. Follow the editing instructions embedded within the template
carefully. Replace all bracketed text with your own information, deleting the brackets. Pay attention to
comment tags (e.g. <! - - Stock Meta Tags DO NOT EDIT - ->) for instructions.
NOTE: Refer to the “Using the Libraries Templates” page
(http://www.lib.umd.edu/itd/web/bestpractices/using_templates.html) for additional information regarding
the use of the templates.
To publish your page to the server, use WebSpinner (instructions follow).

The UM Libraries’ Best Practices and Web Author’s Checklist


The UM Libraries’ Best Practices and Web Author’s Checklist
The Web Administration Committee (WAC) developed a series of “Web Best Practices” to guide development
of pages placed on the Library server. These guidelines are available at:
http://www.lib.umd.edu/itd/web/bestpractices/
The Best Practices cover topics such as:
o Using the Libraries Templates o Know Your User o Writing for the Web
o Writing HTML o Page Design o Accessibility
o Linking and Navigation o Graphics o Ongoing Maintenance
o Naming Directories, Files and Links o Validating Your HTML
Although you will want to become familiar with all of the “Best Practices”, of particular note are the following:
From “Naming Directories, Files and Links” – (http://www.lib.umd.edu/itd/web/bestpractices/naming.html) --
􀂾 Use lowercase for directory names.
􀂾 Use brief, logical and meaningful file names.
􀂾 Give meaningful names to links (avoid "click here"). Remember that some people scan pages for links;
make the content of your links jump out at those people.
􀂾 When linking off the UM web site, be sure to let users know.
From “Page Design” – (http://www.lib.umd.edu/itd/web/bestpractices/page_design.html) --
􀂾 Left-justify your headings and text to compliment the design of the templates. (See page 13 for a
discussion of the templates.)
􀂾 Consider content “above the fold” – keep highest priority information at the top of the page so users do
not have to scroll down to find it.
􀂾 Maintain a professional appearance – avoid blinking text and animation.
Introduction to HTML – UM University Libraries 13
􀂾 The shade of gold used in the template footer and header should not be used elsewhere in your page
(except if you use gold arrows).
The Web Administration Committee has created a brief, easy-to-read reminder of the elements that make a
Web site usable and accessible to a large, diverse audience. Called the "Web Author's Checklist", this guide
simply references the existing “Best Practices” in writing. The complete Checklist is available online at
http://www.lib.umd.edu/itd/web/checklist.html or in a more concise, printable form, at
http://www.lib.umd.edu/itd/web/checklist.pdf.

Adding A Simple Table


Creating a Web Page: Part 3 – Adding A Simple Table
Tables may look complicated at first, but they will be easier to understand if you remember that a table in
HTML is created row by row. Type the tags as shown, and follow the directions in italic type. Use any spacing
or indentation that makes sense to you, but do not change the order of any of the tags. Be sure to insert this
table before the closing body and html tags on your page.
<table>
<tr>
<th> Heading for 1st column . For example: Name</th> <th> Heading for 2nd column. For example: Phone
Number</th></tr>
<tr>
<td> Words in the first row, first column. For example: Coach Ralph Friedgen</td><td> Words in the first row,
second column. For example: X4-7096 </td></tr>
<tr>
<td> Words in the second row, first column. For example: Coach Gary Williams</td> <td> Words in the
second row, second column. For example: X4-7029</td>
</tr>
</table>
Save your document, and preview it in Firefox.


Next, we'll spread out the table by adding space in the cells. This is done by specifying a number, which the
browser interprets as a number of pixels between the text and the cell border. The HTML command for this is
cellpadding. Edit your table to read:
<table cellpadding="5">
You can also change the amount of space between table cells – which is called cellspacing in HTML. Both
cellpadding and cellspacing commands can be used at the same time.
<table cellspacing="5" cellpadding="5">
Once you have made this change, save your file and preview it in Firefox.
Congratulations! You have now created a simple web page with graphics, links, and a table!!!

 
Twitter Bird Gadget