Download Language support

BTW: if you go, my advice to you
Language support
Version 1.0
BTW: if you go, my advice to you
Language support
Version:
1.0
Date: 2008-11-03
Revision History
Date
Version
Description
Author
2008-11-03
0.01
Initial Draft
Abhishek
2008-11-03
0.02
Language consistency
Anand
Doc. No.:
Internal-1
Page 3
BTW: if you go, my advice to you
Language support
Version:
1.0
Date: 2008-11-03
1. Introduction
1.1 Purpose of this document
The purpose of this document is to provide overview of btw tool language support i.e. MACHSUP.
1.2 Document organization
The document is organized as follows:



Section 1, Introduction, describes contents of this guide.
Section 2 Overview of Mashup for development and BTW, describes an overview of MACSHUPS with
a focus on our project requirements
Section 3 Conclusion, Concludes with the selection of Mashup.
1.3 Intended Audience
The intended audience is:
 Project group: This document would help to make decision on which technology to be used for the
current project BTW under the given circumstances.
 Steering group: To provide the proof of choosing technology.
1.4 Scope
The scope of document will provide details of possible technology for BTW implementation.
1.5 Definitions and acronyms
1.5.1 Definitions
Keyword
BTW
Definitions
By The Way
Page 4
BTW: if you go, my advice to you
Language support
2.
Version:
1.0
Date: 2008-11-03
Overview of Mashup for development for BTW
2.1 Mashups: In web development, a mashup is a web application that combines data from more than one
source into a single integrated tool. As an example, the use of geographic data from Google Maps to add
location information to BTW knowledge base, thereby creating a new and distinct web service that was not
originally provided by either source.
The content used in mashups are obtained from third party via a public interface oe API (web services). Other
methods of obtaining content for mashups include Web feeds (e.g. RSS or Atom), and screen scraping.
Experiments are going with yahoo, googlemap APIs, which has led to the creation of mashup editors. Some
programming languages, such as Orc, offer support for the creation of mashups.
Mashup web application has three parts:

A web page that provides a new service using its own data and data from other sources (from
additional content providers).

Additional content provider: Data is made available across the web through an API and using different
web protocols such as HTTP, RSS, REST, or other web services.

The client: is the user of the mashup, often using a web browser displaying a web page containing the
mashup. Various mashup platforms support the emission of RSS, Web Services, instant messages or
email messages, which are consumed by feed readers, rich applications, IM clients or email clients
respectively.
Mashups are different from simple embedding of data from another site to form a compound page. A site that
allows a user to embed a YouTube video for instance, is not a mashup site. A mashup site must access third
party data using an API, and process that data to add value for the site's users.
2.2 Types of Mashup:
Many types of Mashup are available such as consumer Mashup, data Mashup, and Business Mashup.
1.
Consumer Mashup are aimed for general public. Examples are Google maps applications, iGuide.
2.
Data Mashup combine similar types of media and information from multiple sources into a single
graphical representation. An example is the Havaria Information Services' AlertMap, which combines
data from over 200 sources related to severe weather conditions.
3.
Business mashups focus aggregate into a single presentation, and allow for collaborative action among
businesses and developers
2.3 Mashups versus portals:
Mashups differ from portals in the following aspects:
Page 5
BTW: if you go, my advice to you
Language support
Version:
1.0
Date: 2008-11-03
Table 1: Difference between Mashup and Portal
Portal
Classification
Mashup
Older technology, extension to traditional
Using newer, loosely defined "Web 2.0"
web server model using well defined
techniques
approach
Approaches aggregation by splitting role of
Uses APIs provided by different content
web server into two phases - mark-up
Philosophy/Approach
sites to aggregate and reuse the content in
generation and aggregation of mark-up
another way
fragments
Aggregates presentation-oriented mark-up Can operate on pure XML content and also
Content dependencies fragments (HTML, WML, VoiceXML, on presentation-oriented content (e.g.,
etc.)
HTML)
Location
dependencies
Traditionally content aggregation takes Content aggregation can take place either
place on the server
on the server or on the client
Aggregation style
"Melting Pot" style - Individual content
"Salad bar" style - Aggregated content is
may be combined in any manner, resulting
presented 'side-by-side' without overlaps
in arbitrarily structured hybrid content
Event model
CRUD operations are based on REST
Read and update event models are defined
architectural principles, but no formal API
through a specific portlet API
exists
Relevant standards
Portlet behaviour is governed by standards
JSR 168, JSR 286 and WSRP, although
portal page layout and portal functionality
are undefined and vendor-specific
Base standards are XML interchanged as
REST or Web Services. RSS and Atom are
commonly used. More specific Mashup
standards are expected to emerge.
2.4 Mashups in a business environment:
Mashup is a key component of integrating business and data services, as Mashup provide the ability to develop
new integrated services quickly, to combine internal services with external or personalized information, and to
make these services tangible to the business user through user interfaces.
2.5 Architectural aspects of mashups
Mashups appear to be a variation of a Facade pattern.It is software engineering design pattern that provides a
simplified interface to a larger body of code.
Mashup can be used with software provided as a service. Its role in service oriented architecture is often to give
Page 6
BTW: if you go, my advice to you
Language support
Version:
1.0
Date: 2008-11-03
the end user a more customised, familiar, or simply easy to implement interface. Geodata provided as a service,
for example, is the ideal companion for a mashup with the Google Maps API.
2.6 Mashup editors:
There are already several mashup editors that help users to create or edit mashups. (alphabetically):

Google Mashup Editor

IBM Mashup Center

IBM Sharable Code

JackBe Presto

Kapow

Microsoft Popfly

Mozilla Ubiquity

WaveMaker Visual Ajax Studio

Yahoo pipes

zembly
2.7 How to Make Your Own Web Mashup [1]:
1. Pick a subject:
For building a complex system with multiple data sources: maps + photos + bookmarks + more, we
want to keep it simple to start. This helps define what APIs and tools we will be looking at: maps,
news, auctions, products, etc. By browse this site's API Database and sort by Category to get a sense of
API types. You can also browse the Mashup Listing to see which interesting applications have been
built using which APIs.
2. Decide where your data is coming from:
The selection of APIs depend on the source of data.. For example, if you want to do something with
your photos on Flickr or sale items on eBay, then those vendors APIs are the likely candidates. Or, you
may be inputting the data yourself such as with simple map markers. In which case your options are
more open.
3.
Weigh your coding skills:
Mashups, as of today, are mostly a programmer's affair although there are some tools such as
MapBuilder and Wayfaring that can help you create basic maps without coding.
How much of a coder are you?
Maps APIs are simplest but more sophisticated APIs, such as those for conducting financially-sensitive
operations like auctions, are more complex.
How much time do you have?
Again, development speed is inversely proportional to complexity.
Do you have a server to run this on?
Simpler APIs can be used from JavaScript in a web page or take especially formated XML file as input
(as shown here at Engadget). While this is indeed simple, security issues limit JavaScript's suitability
for true client-only mashups. Odds are that you will need to run your application from a web server
which you manage or have access to.
What language will you use?
Page 7
BTW: if you go, my advice to you
Language support
Version:
1.0
Date: 2008-11-03
This is primarily driven by what programming languages you know. While your decision may also be
influenced by vendor-provided toolkits, most web APIs aim to be language-agnostic so this is less of a
vendor-dictacted issue than your own choice. You can use the API reference to see if an API has a
language-specific toolkit (such as Flickr which has many).
4. Sign-up for an API:
API providers require you to have a developer/application ID, a user account with their service, or
both. Some services give you one ID for as many applications as you write while others require you to
get an ID for each application that you create. While this signup may sound complicated, and for a few
services it is, most of the time this takes only a minute or two to complete. As an example, take a look
at the Google Sign-up Page.
5. Start coding:
For this step, the big one, rather than describe the many variations in detail, I'll refer you to a variety of
well-written and useful API-specific tutorials and introductions. You can also check the profile for any
of the APIs and refer to resources from the reference section as needed.
3. Conclusion
We can develop our machups in BTW project by use of java or php and using database of our choice as
backend. We can use web service for server side API. This will also result in better “look and feel” and better
performance. We can use HTML, CSS, AjaX and client side scripting such as java script. For integration of
Google map or yahoo map we can use their api key in our code or develop our own map by use of PHP or Java
or .NET.
2.9 References
[1] http://www.programmableweb.com/howto
Page 8