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

Read More

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)

Read More

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

Read More

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.

WebServices. Org

The Stencil Group

IBM

W3C

 Web Services architectures from Microsoft

Web Services architectures from Sun

Web Services architectures from Oracle

Web Services architectures from Hewlett-Packard

Web Services architectures from Borland.

Read More

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

Read More