Friday, December 2, 2011

Web Interface Definition Language [WIDL]


which collectively are referred to as "the submission". We request the submission be known as the "WIDL" submission.

Abstract

This document provides the specification for the Web Interface Definition Language (WIDL), a metalanguage that implements a service-based architecture over the document-based resources of the World Wide Web. WIDL is an application of the eXtensible Markup Language (XML); it allows interactions with Web servers to be defined as functional interfaces that can be accessed by remote systems over standard Web protocols, and provides the structure necessary for generating client code in languages such as Java, C/C++, COBOL, and Visual Basic. WIDL enables a practical and cost-effective means for diverse systems to be rapidly integrated across corporate intranets, extranets, and the Internet.

1. Introduction

The World Wide Web is providing millions of end-users access to ever-increasing volumes of information. While the Web initially served browsers static documents, the resources of legacy systems, relational databases and multi-tier applications have all been made available to the Web browser to provide corporate users with interactive information resources including financial services, inventory management, on-line purchasing and package tracking.
While the Web has achieved the extraordinary feat of providing ubiquitous accessibility to end-users, it has in many cases reinforced manual inefficiencies in business processes as repetitive tasks are required to transcribe or copy and paste data from browser windows into desktop and corporate applications. This is as true of Web data provided by remote business units and external (i.e. partner or supplier) organizations as it is of Web data accessible from both public and subscription based Web sites. The problem of direct access to Web data from within business applications has been largely ignored.
The purpose of the Web Interface Definition Language (WIDL) is to enable automation of all interactions with HTML/XML documents and forms, providing a general method of representing request/response interactions over standard Web protocols, and allowing the Web to be utilized as a universal integration platform.

A central feature of WIDL is that programmatic interfaces can be defined and managed for data (HTML, XML or text files) and services (CGI-bin, database, or other back end systems) that are not under the direct control of programs that require such access. WIDL definitions can be co-located with client programs, centrally managed in a client/server architecture, or referenced directly from HTML/XML documents.
WIDL defintions provide a mapping between Web resources and applications written in conventional programming languages such as C/C++, COBOL, Visual Basic, Java, JavaScript, etc., enabling automatic and structured Web access by compatible client programs, including mainstream business applications, desktop applications, applets, Web agents, and server-side Web programs (CGI, etc.).
Automatic means that complex interactions with Web servers do not require human intervention; programs can request Web data and services by making local calls to functions which encapsulate standard Web access protocols and utilize WIDL definitions to provide naming services, change management, error handling, condition processing and intelligent data binding.
Structured means that Web data and services are described as interfaces with well defined input and output variables.
Standard Web access protocols means HTTP and HTTPS.
Compatible means any program that both utilizes WIDL definitions to define the location of Web services and the structure of data that is returned by standard HTTP and HTTPS requests, and allows WIDL definitions to be managed locally, centrally, or by individual service providers.
WIDL describes business objects on the Web, providing the basis for a common API across Web servers, legacy systems, databases, and middleware infrastructures, and effectively transforming the Web from an access medium into an integration platform.
This document provides a complete description of the Web Interface Definition Language (WIDL).

2. Benefits of WIDL

A major part of the value of an Interface Defintion Language (IDL) is that it can define services offered by applications in an abstract but highly usable fashion. WIDL brings to the Web many of the features of IDL concepts that have been implemented in distributed computing and transaction processing platforms including DCE, and CORBA.

2.1 Business-to-Business Integration

WIDL makes it easy for organizations to automate business transactions with customers and suppliers. WIDL describes and automates interactions with services hosted by Web servers on intranets, extranets and the Internet; it transforms the Web into a standard integration platform and provides a universal API for all Web-enabled systems.
Using HTML, XML, HTTP and HTTPS as corporate standards glue, WIDL requires only that target systems be Web-enabled. There are hundreds of products in the market today which Web-enable existing systems, from mainframes to client/server applications. The use of standard Web technologies empowers various IT departments to make independent technology selections. This has the effect of lowering both the technical and 'political' barriers that have typically derailed cross-organizational integration projects.
A number of analysts have already warned that proprietary e-commerce platforms could lock suppliers into relationships by forcing them to integrate their systems with one infrastructure for business-to-business integration, making it costly for them to switch to or integrate with other partners who have selected alternate e-commerce platforms. Buyer-supplier integration issues involve many-to-many relationships, and demand a standard platform for functional integration and data exchange.
A service defined by WIDL is equivalent to a function call in standard programming languages. At the highest level, WIDL files describe the locations (URLs) of services, input parameters to be submitted (via Get or Post methods) to each service, conditions for successful processing, and output parameters to be returned by each service.
WIDL provides the following features:
A browser is not required to drive Web applications
WIDL definitions are dynamically interpreted and can be centrally managed
Client applications are insulated from changes in service locations and data extraction methods
Developers are insulated from network programming concerns
Application resources can be integrated through firewalls and proxies
WIDL can be used to describe interfaces and services for:
Static documents (HTML, XML, and plain text files)
Dynamically generated documents (HTML, XML, and plain text files)
HTML forms
URL directory structures
WIDL can be used:

to automate interactions with Web servers
for both on-demand and scheduled extraction of targeted Web data
to aggregate data from a number of Web sources
to chain services across multiple Web sites
to rapidly integrate Web resources with traditional application development languages and environments
WIDL has the ability to specify conditions for successful processing, and error messages to be returned to calling programs. Conditions further enable services to be defined that span multiple documents.

2.2 Change Management
One of WIDL's most significant benefits is its ability to insulate client programs from changes in the format and location of Web documents. Unlike the way CORBA and DCE IDL are normally used, WIDL is interpreted at runtime; as a result, service URLs, object references in variables, definitions of document regions, success/failure conditions, and directives for service chaining can all be administered without requiring modification of client code. This usage model supports application-to-application linkages that are far more robust and maintainable than if they were coded by hand.
There are three models for WIDL management:
client side - where WIDL files are co-located with a client program
naming service - where WIDL definitions are centrally managed and referenced via directory services, i.e. LDAP
server side - where WIDL files are referenced by, co-located with, or embedded within Web documents.
WIDL does not require that existing Web resources be modified in any way. Flexible management models allow organizations to describe and integrate Web sites that are uncontrolled, as well as to provide their business partners with interfaces to services that are controlled. The ability to seamlessly migrate from independent to shared management eases the transition from informal to formal business-to-business integration.

2.3 Language Bindings
The primary purpose of WIDL is integration of Web resources with corporate business applications. In much the same way that DCE or CORBA IDL is used to generate code fragments, or 'stubs', to be included in application development projects, WIDL provides the structure necessary for generating client code in languages such as C/C++, Java, COBOL, and Visual Basic. Developers can thus be insulated from the need to understand both HTML/XML parsing and Web protocols. This capability enables the existing skills of innumerable programmers to be rapidly leveraged in the utilization of Web based resources.

3. Object Model References

Many of the features of WIDL require a capability to reliably identify and extract specific data elements from Web documents. Various mechanisms for accessing elements of HTML and/or XML documents have been defined, such as the Javascript Page Object Model, the Document Object Model, and XLL XPointers. WIDL does not define or determine a mechanism for accessing document data, but rather allows an object model referencing mechanism to be specified on a per-interface basis.

The following capabilities are desirable for accessing elements of Web documents:

HTML Parsing
XML Parsing
Text Pattern Matching
Object referencing mechanisms would ideally support both parsing and pattern matching. Pattern matching extracts data based on regular expressions, and is well suited to raw text files and poorly constructed HTML documents. Parsing, on the other hand, recovers document structure and exposes relationships between document objects, enabling elements of a document to be accessed with an object model.

4. WIDL Reference

The Web Interface Definition Language (WIDL) is an application of the eXtensible Markup Language (XML); its definition consists of the various XML elements defined in this section.

Major Elements

WIDL - defines an interface
SERVICE - child of WIDL - defines a service
BINDING - child of WIDL - defines input and output parameters for services

Minor Elements

VARIABLE - child of BINDING - defines a variable within a binding
CONDITION - child of BINDING - defines a condition within a binding
REGION - child of BINDING - defines a area within a document

Monday, November 21, 2011

UI Web Developer - Interview Questions

Excellent Communication Skills:-
The candidate should be a good communicator as most of the cases he will be the liason between business stakeholders and project management team.
Technical Skills:-
Should be Strong with : HTML, CSS, Javascript/JQuery
UI Design/Javascript/CSS/JQuery:
How would you make sure that your CSS are cross browser compliant?
What testing tools you've used for cross browser testing?
Which javascript frameworks have you used?
How would you achieve a Corporate Heading on all pages?
What would be your approach to desing following elements:
Navigation Menu
3-Column Layout
A Grid with more than 2000 rows
How would you manage a grid which has more columns than the page width (without horizontal scrolling)?
What is CDN based referencing? Why do some site use JS files from Google or Yahoo CDN instead of their own server?
How would you optimized the javascript footprint of the page?
What all measures you would take to reduce the rendering time for a HTML page?
What are the 3 key usability consideration you would make to design a website which will be used by School Principles (the users can change based on your requirements like CTO/CEO or Lawyers)
Which tools you've used for javascript/jquery debugging? In which scenario?
How would you handle a heirarchial response in JSON?
How would you implement Error Handling in jquery or javascript?
What all validation frameworks you have used?
What all jQuery Plugins you have used? Where?? To achieve what??
Tell me a scenario where you faced an issue with a jQuery plugin and you fixed/hacked it?