Translate

Pages

Wednesday, 11 July 2012

Introduction to html


Welcome to HTML...
This is Primer #1 in a series of seven that will calmly introduce you to the very basics of HyperText Mark-up Language. I suggest you take the Primers one at a time over seven days. By the end of the week, you'll easily know enough to create your own HTML home page. No really. You will.
I say that because many people scoff at the notion that they can actually learn this new Internet format. I'm still amazed that the best-selling line of computer books calls its readers "Dummies." And people seem to revel in that title. Some of the smartest people I know love to proclaim themselves "Dummies" regarding every aspect of computers. Strange. I think you'll do a whole lot better at your next cocktail party by handing out your home page address rather than laughing about how dumb you are about the Internet.
You Can Do This!

Let's Get Started
I am assuming at the beginning of this tutorial that you know nothing about HTML. I am assuming, however, some computer knowledge. You wouldn't be looking at this page without having some knowledge. To continue with these Primers, you will need...
1. A computer (obviously)
2. A browser like Mozilla FirefoxNetscape NavigatorMicrosoft Internet Explorer, or Opera. If you're looking at this page, you already have one. If you look up at the title bar at the very top of your screen it will probably say the page title ("Basic HTML: Introduction") and then your browser's name.
3. A word processor. If you have access to Windows "Notepad" or "WordPad" programs or the MAC "Simple Text" program, use that to get started.
If you have those three things, you can write HTML with the best of them. Now here are a few questions you probably have:
Q. I have a MAC (or PC) -- will this work on my computer?
A. Yes. HTML does not use any specific platform. It works with simple text. More on that in a moment...
Q. Must I be logged onto the Internet to do this? More specifically, will learning this throw my cost for on-line way up?
A. Neither. You will write off-line.
Q. Do I need some sort of expensive program to help me write this?
A. No. You will write using just what I outlined above. You can buy those programs if you'd like, but they're not needed. I've never used one.
Q. Is this going to require I learn a whole new computer language like Basic or Fortran or some other cryptic, God-awful, silly-lookin', gothic extreme gobbledygook?
A. Touchy-touchy, aren't we? "No" is the answer. HTML is not a computer language. Allow me to repeat that in bold... HTML is not a computer language!

What is HTML?
H-T-M-L are initials that stand for HyperText Markup Language (computer people love initials and acronyms -- you'll be talking acronyms ASAP). Let me break it down for you:
  • Hyper is the opposite of linear. It used to be that computer programs had to move in a linear fashion. This before this, this before this, and so on. HTML does not hold to that pattern and allows the person viewing the World Wide Web page to go anywhere, any time they want.
  • Text is what you will use. Real, honest to goodness English letters.
  • Mark up is what you will do. You will write in plain English and then mark up what you wrote. More to come on that in the next Primer.
  • Language because they needed something that started with "L" to finish HTML and Hypertext Markup Louie didn't flow correctly. Because it's a language, really -- but the language is plain English.

    Beginning to Write
    You will actually begin to write HTML starting with Primer #2. That's tomorrow if you follow the seven-day plan this was written for. Here, I want to tell you how you will go about the process.
    You will write the HTML document on the word processor, or Notepad, WordPad, or Simple Text. When you are finished creating the HTML document, you'll then open the document in a browser, like Netscape Navigator. The browser will interpret the HTML commands for you and display the Web page.
    Now, some people who are already schooled in HTML are going to jump up and down and yell that you should be using an HTML assistant program because it makes it easier. That's true, but it also makes it harder to learn as the program does half the work for you. Take my word for it, use the word processor for a week, then go to the assistant if you still want to use one. You'll be far better off for the effort. I have been writing HTML for six years and I still use Notepad for the bulk of my writing.

    Let's get into the programs you will use to write your HTML document. Keep this in mind: HTML documents must be text only. When you save an HTML document, you must save only the text, nothing else.
    The reason I am pushing NotePad, WordPad, and Simple Text is that they save in text-only format without your doing any additional work. They just do it. But, if you're like me, then you will want to start writing on a word processor, like WORD, or WordPerfect. Maybe you're just more comfortable on it. If so, read this next part carefully.
    The Word Processor
    When you write to the word processor you will need to follow a few steps:
    1. Write the page as you would any other document.
    2. When you go to save the document (Here's the trick), ALWAYS chooseSAVE AS.
    3. When the SAVE AS box pops up, you will need to save the page in a specific format. Look at the SAVE AS dialogue box when it pops up: Usually at the bottom, you find where you will be able to change the file format.
    4. If you have a PC, save your document as ASCII TEXT DOS or just TEXT. Either one will work.
    5. If you have a MAC, save your document as TEXT.
    6. When I started writing HTML, I saved pages by assigning every Web page its own floppy disc. It just helped me keep it all straight, but if you want to save right to your hard drive, do it. I only offer the floppy disc premise as a suggestion.
    Please remember: It is very important to choose SAVE AS EVERY time you save your document. If you don't, the program won't save as TEXT, but rather in its default format. In layman's terms -- use SAVE AS or screw up your document.
    You see, when you save your document in WORD, or some other word processor format other than text, you are saving much more than just the letters on the page. You're saving the margin settings, the tab settings, specific fonts, and a whole lot of other settings the page needs to be displayed correctly. You don't want all of that. You just want the text.
    NotePad, WordPad, and SimpleText already save in text-only format so if you use one of them as your word processor, you'll get the correct format simply by saving your document.

    How To Name Your Document
    What you name your document is very important. You must first give your document a name and then add a suffix to it. That's the way everything works in HTML. You give a name and then a suffix.
    Follow this format to name your document:
    1. Choose a name. Anything. If you have a PC not running Windows 95, you are limited to eight letters, however.
    2. Add a suffix. For all HTML documents, you will add either ".htm" or ".html".
    (".htm" for PCs running Windows 3.x and ".html" for MAC and Windows 95/98 Machines)
    Example:
    I am looking to name a document I just wrote on a PC running Windows 3.11 for workgroups. I want to name the document "fred". Thus the document must be named "fred.htm". If it was MAC or Windows 95/98 I would name it "fred.html". Please notice the dot (period) before .htm and .html. And no quotation marks, I just put them in here to set the name apart.
    Uhhhhhh.... Why Do I Do That?
    Glad you asked. It's a thing called "association." It's how computers tell different file types apart. ".html" tells the computer that this file is an HTML document. When we get into graphics, you'll see a different suffix. All files used on the Web will follow the format of "name.suffix." Always.
    Okay, why .htm for PCs running Windows 3.x and .html for MAC and Windows 95/98?
    Because that's the way the operating systems are made (Windows 3.x, Windows 95/98, and MAC OS are all technically called operating systems). Windows 3.x only allows three letters after the dot. MAC OS and Windows 95/98 allow four, or more. Your browser allows for both suffixes. It acts upon .html and .htm in the same fashion.

    Why do you keep harping on the fact that I must save in TEXT only?
    You're just full of questions! You see, HTML browsers can only read text. Look at your keyboard. See the letters and numbers and little signs like % and @ and *? There are 128 in all (read upper- and lowercase letters as two). That's text. That's what the browser reads. It simply doesn't understand anything else.
    If you'd like to test this theory, then go ahead and create an HTML document and save it in WORD. Then try and open it in your browser. Nothing will happen. Go ahead and try it. You won't hurt anything.
    Remember that if you are using Notepad, Wordpad, or Simple Text, the document will be saved as text with no extra prompting. Just choose SAVE.

    Opening the Document in the Browser
    Once you have your HTML document on the floppy disc or your hard drive, you'll need to open it up in the browser. It's easy enough. Since you're using a browser to look at this Primer, follow along.
    1. Under the FILE menu at the very top left of this screen, you'll find OPEN, OPEN FILE, OPEN DOCUMENT, or words to that effect.
    2. Click on it. Some browsers give you the dialogue box that allows you to find your document right away. Internet Explorer, and later versions of Netscape Navigator, require you to click on a BROWSE button or OPEN FILE button to get the dialogue box. When the dialogue box opens up, switch to the A:\ drive (or the floppy disc for MAC users) and open your document. If you saved the file to your hard drive, get it from there.
    3. You might have to then click an OK button. The browser will do the rest.

    One More Thing
    You easily have enough to keep you occupied for the first day. Don't worry, the Primers get less wordy after this.
    If you are going to start writing HTML, I suggest you make a point of learning to look at other authors' HTML pages. You say you're already doing that, right? Maybe. What I mean is for you to look at the HTML document a person wrote to present the page you are looking at. Don't look at the pretty page, look behind it at the HTML document.
    Why Would I Do That?
    Because you can... but seriously, folks. Let's say you run into a page that has a really neat layout, or a fancy text pattern, or a strange grouping of pictures. You'd like to know how to do it.
    Well, look, I'm not telling you to steal anything, but let's be honest, if you see some landscaping you like, you're going to use the idea. If you see a room layout you like, you will use the idea to help yourself. That's the point of looking at another page's HTML document. I think it's also the best way to learn HTML. In fact, I am self-taught in HTML simply by looking at others' documents. It was the long way around, believe me. You're going to have a much easier time of it with these Primers.
    Here's how you look at an HTML document (known as the "source code"):
    1. When you find a page you like, click on VIEW at the top of the screen.
    2. Choose DOCUMENT SOURCE from the menu. Sometimes it only reads SOURCE.
    3. The HTML document will appear on the screen.
    4. Go ahead. Try it with this page. Click on VIEW and then choose the SOURCE.
    It's going to look like chicken-scratch right now, but by the end of the week, it'll be readable and you'll be able to find exactly how a certain HTML presentation was performed.
    It's A Little Different On AOL
    Those of you who use AOL can also see the source. You can do it by placing your pointer on the page, off of an image, and clicking the right mouse button. MAC users should click and hold. A small menu should pop up. One of the items will allow you the ability to view the source.
    That's the Primer for today. Print it out if you'd like and get ready to delve in and write your first HTML document. See you tomorrow.
  • 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

     
    Twitter Bird Gadget