service oriented architecture & web 2.0

Service Oriented Architecture and Web 2.0: A Report

A Report on

The integrated functionality of

Service Oriented Architecture (SOA)

&

Web 2.0By:

Abhik Tushar Das (EMBA 2010-11 batch) Roll No. 20104001

Anil Kumar Sahu (EMBA 2010-11 batch) Roll No. 20104004

Under the mentorship of:

Dr.Parag Sanghani

Director & Pro VC ( Ackruti Ctiy University Ahmadabad)

Submitted as part-fulfillment of the course titled:

“Real time applications of Management Information Systems (MIS)”

Under the:

15-MonthExecutive MBA Programme (2010-11 batch)

SCHOOL OF PETROLEUM MANAGEMENT,

PDPU, GANDHINAGAR, GUJARAT, INDIA.

By: Abhik Tushar Das ([email protected]) & Anil Kumar Sahu ([email protected])

mailto:[email protected]


ACKNOWLEDGEMENT

We desire to express our thankfulness and sincere gratitude to

Dr.Parag Sanghani (Director & Pro VC of Ackruti City University

Ahmadabad) who had been associated with the EMBA(2010) batch as a visiting

faculty for the course “Management Information systems” and provided us a

enlightenment on the course and this opportunity to do a presentation and

project work on the topic “Service Oriented Architecture(SOA) & Web 2.0”

platform intended to broaden our prospects on the real life applications of

Management Information Systems.

We extend our heartfelt thanks to everybody who were associated

academically with this project.

Abhik Tushar Das Anil Kumar Sahu

Roll No: 20104001 Roll No: 20104004

Gandhinagar

Dt: 01-03-2011




Table of Contents

SL/

No.

Description Page No.




Abstract

In a fast changing and increasingly challenging Business

environment every progressing business organization’s functionality is being

redefined by the emerging challenges of improving technology and increasing

competition. In order to survive and progress forward, efficient use of

“Management Information systems” is changing the way of functions and

daily activities of big and small business organizations with a ever increasing

need to increasing their productivity by improving their overall efficiency in

every aspect of their operating procedure. With the progress of Information

Technology; organizations are able to have a better control of every aspect of

business like effective usage of resources and time and maximizing the

generation of revenue by enabling customized MIS modules. They are able to

emphasize on their innovative strategies to their level best at fulfilling the

needs and wants of its customers at most to their capabilities. Storage,

processing, retrieval of productivity information in today’s scenario have

become very effective as compared to past decades and tend to get better

with the emergence of improved Information Technology tools.

“Management Information systems”, has emerged to be an

effective tool to control the daily functional aspects and duly forecast the

growth in business opportunities without which it is unimaginable for business

organizations to even manage daily activities.

This project report primarily focuses on the technological,

structural, recent development aspects and economic importance and cross

functionality of Service Oriented Architecture (SOA) & Web 2.0 platforms

which are swiftly changing the way in which the web enabled communication

and information management structure function to customized requirements.




Service Oriented Architecture:

1.1--Introduction:

The widespread emergence of the Internet in the mid 1990s as a platform for electronic

data distribution and the advent of structured information have revolutionized our ability to

deliver information to any corner of the world. While the introduction of Extensible Markup

Language (XML) as a structured format was a major enabling factor, the promise offered by

SOAP based web services triggered the discovery of architectural patterns that are now

known as Service Oriented Architecture (SOA).

Service Oriented Architecture is an architectural paradigm and discipline that may be used

to build infrastructures enabling those with needs (consumers) and those with capabilities

(providers) to interact via services across disparate domains of technology and ownership.

Services act as the core facilitator of electronic data interchanges yet require additional

mechanisms in order to function. Several new trends in the computer industry rely upon

SOA as the enabling foundation. These include the automation of Business Process

Management (BPM), composite applications (applications that aggregate multiple services

to function), and the multitude of new architecture and design patterns generally referred

to as Web 2.0.

The latter, Web 2.0, is not defined as a static architecture. Web 2.0 can be generally

characterized as a common set of architecture and design patterns, which can be

implemented in multiple contexts. The list of common patterns includes the MASHUPS,

Collaboration-Participation, Software as a Service (SAAS), Semantic Tagging (FOLKSONOMY),

and Rich User Experience (also known as Rich Internet Application) patterns among others.

These are augmented with themes for software architects such as trusting your users and

harnessing collective intelligence. Most Web 2.0 architecture patterns rely on Service

Oriented Architecture in order to function.

When designing Web 2.0 applications based on these patterns, architects often have highly

specialized requirements for moving data. Enterprise adoption of these patterns requires

special considerations for scalability, flexibility (in terms of multiple message exchange

patterns), and the ability to deliver these services to a multitude of disparate consumers.

Architects often need to expand data interchanges beyond simple request-response




patterns and adopt more robust message exchange patterns, triggered by multiple types of

events. As a result, many specialized platforms are evolving to meet these needs.

2.0 An Introduction to Service Oriented Architecture

Service Oriented Architecture (SOA) is a paradigm for organizing and utilizing distributed

capabilities that may be under the control of different ownership domains and implemented

using various technology stacks. In general, entities (people and organizations) create

capabilities to solve or support a solution for the problems they face in the course of their

business. It is natural to think of one person’s needs being met by capabilities offered by

someone else; or, in the world of distributed computing, one computer agent’s

requirements being met by a computer agent belonging to a different owner. The term

owner here may be used to denote different divisions of one business or perhaps unrelated

entities in different countries.

There is not necessarily a one-to-one correlation between needs and capabilities; the

granularity of needs and capabilities vary from fundamental to complex, and any given need

may require a combination of numerous capabilities while any single capability may address

more than one need. One perceived value of SOA is that it provides a powerful framework

for matching needs and capabilities and for combining capabilities to address those needs

by leveraging others capabilities. One capability may be repurposed across a multitude of

needs.

SOA is a “view” of architecture that focuses in on services as the action boundaries between

the needs and capabilities in a manner conducive to service discovery and repurposing.

2.1 Requirements for SOA

Figure 2-1 shows an example of an information system scenario that could benefit from a

migration to SOA. Within one organization, three separate business processes use the same

functionality, each encapsulating it with a different application. In this scenario, the login

function, the ability to change the user name, and the ability to persist it are common tasks

implemented redundantly in all three processes. This is a suboptimal situation because the

company has paid to implement the same basic functionality three times.




Figure 2.1 – three business processes within one company duplicating

functionality

Moreover, such scenarios are highly inefficient and introduce maintenance complexity

within IT infrastructures. For example, consider an implementation in which the state of a

user is not synchronized across all three processes. In this environment users might have to

remember multiple login username/password tokens and manage changes to their profiles

in three separate areas. Additionally, if a manager wanted to deny a user access to all three

processes, it is likely that three different procedures would be required (one for each of the

applications). Corporate IT workers managing such a system would be effectively tripling

their work –and spending more for software and hardware systems.

In a more efficient scenario, common tasks would be shared across all three processes. This

can be implemented by decoupling the functionality from each process or application and

building a standalone authentication and user management application that can be

accessed as a service. In such a scenario, the service itself can be repurposed across multiple

processes and applications and the company owning it only has to maintain the

functionality in one central place. This would be a simple example of Service Oriented

Architecture in practice. The resultant IT infrastructure would resemble Figure 2.2.




Figure 2.2 – three business processes repurposing one service for common tasks.

In figure 2.2, the shared user account tasks have been separated from each process and

implemented in a way that enables other processes to call them as a service. This allows the

shared functions to be repurposed across all three processes. The common service bus is

really a virtual environment whereby services are made available to all potential consumers

on a fabric. This is typically referred to as an Enterprise Service Bus (ESB) and has a

collection of specialized subcomponents including naming and lookup directories, registry-

repositories, and service provider interfaces (for connecting capabilities and integrating

systems) as well as a standardized collection of standards and protocols to make

communications seamless across all connected devices. Advanced ESB vendors have tools

that can aggregate services into complex processes and workflows.

In the preceding example of SOA, the complications were relatively minor as the entire

infrastructure existed within one domain. In reality, enterprise SOA is much more difficult

because services may be deployed across multiple domains of ownership. To make

interactions possible, mechanisms have to be present to convey semantics, declare and

enforce policies and contracts, the ability to use constraints for data passed in and out of

the services as well as expressions for the behavior models of services. The ability to

understand both the structure and semantics of data passing between service endpoints is

essential for all parties involved.




While most SOA examples are typically shown as a request-response interaction pattern,

more robust exchanges are required. Additionally, modern service platforms also need the

flexibility to support these advanced message exchange patterns. Before discussing the

platform and reference architecture, this white paper will briefly delve into SOA in more

detail.

2.2 A Reference Model for Service Oriented Architecture

As with any other architecture, Service Oriented Architecture can be expressed in a manner

that is decoupled from implementation. Software architects generally use standardized

conventions for capturing and sharing knowledge. This group of conventions is often

referred to as an Architecture Description Language (ADL). There are also several

normalized artifacts (an "Artifact" is one of many kinds of tangible by-product produced

during the development of software) used to facilitate a shared understanding of the

structure of a system, its major components, the relationships between them, and their

externally visible properties. This will make use of two special types of these artifacts – a

Reference Model and Reference Architecture.

A Reference Model is an abstract framework for understanding significant entities and

relationships between them. It may be used for the further development of more concrete

artifacts such as architectures and blueprints. Reference models themselves do not contain

a sufficient level of detail sufficient to enable the direct implementation of a system. In the

case of a reference model for SOA, the Organization for the Advancement of Structured

Information Systems (OASIS) has a standard Reference Model for SOA, shown in Figure 2.3

that is not directly tied to any standards, technologies, or other concrete implementation

details.

In order for SOA to be meeting these challenges, services must have accompanying service

descriptions to convey the meaning and real world effects of invoking the service. These

descriptions must additionally convey both semantics and syntax for both humans and

applications to use.

Each service has an interaction model, which are the externally visible aspects of invoking a

service. In this paper, this will be decomposed further to examine the data service aspects

of SOA.




Figure 2.3 – the core OASIS Reference Model for Service Oriented Architecture

Visibility and Real World Effect are also key concepts for SOA. Visibility is the capacity for

those with needs and those with capabilities to be able to see and interact with each other.

This is typically implemented by using a common set of protocols, standards, and

technologies across service providers and service consumers. For consumers to determine if

they can interact with a specific service, Service Descriptions provide declarations of aspects

such as functions and technical requirements, related constraints and policies, and

mechanisms for access or response. The descriptions must be in a form (or can be

transformed to a form) in which their syntax and semantics are widely accessible and

understandable. The execution context is the set of specific circumstances surrounding any

given interaction with a service and may affect how the service is invoked.

Since SOA permits service providers and consumers to interact, it also provides a decision

point for any policies and contracts that may be in force. The purpose of using a capability is

to realize one or more real world effects. At its core, an interaction is “an act” as opposed to

“an object” and the result of an interaction is an effect (or a set/series of effects). Real world

effects are, then, couched in terms of changes to this shared state. This may specifically

mutate the shared state of data in multiple places within an enterprise and beyond.

The concept of policy also must be applicable to data represented as documents and

policies must persist to protect this data far beyond enterprise walls. This requirement is a

logical evolution of the “locked file cabinet” model which has failed many IT organizations in

recent years. Policies must be able to persist with the data that is involved with services,

wherever the data persists.


Service

Visibility

Service description

Interaction

Contract and Policy

Real world effect

Execution context



A contract is formed when at least one other party to a service oriented interaction adheres

to the policies of another. Service contracts may be either short lived or long lived.

2.3 Decomposing the Interaction Model

Whereas visibility introduces the possibilities for matching needs to capabilities (and vice

versa), interaction is the act of actually using a capability via the service. Typically mediated

by the exchange of messages, an interaction proceeds through a series of information

exchanges and invoked actions. There are many facets of interaction; but they are all

grounded in a particular execution context – the set of technical and business elements that

form a path between those with needs and those with capabilities. Architects building Rich

Internet Applications (RIAs), are faced with special considerations when designing their

systems from this perspective. The concept of “Mashups” surrounds a model whereby a

single client RIA may actually provide a view composed by binding data from multiple

sources persisting in multiple domains across many tiers.

Figure 2.4 – a decomposition of the Interaction Model (courtesy of OASIS Reference

Model for SOA)

As depicted in Figure 2.4, the interaction model can be further decomposed into a data

model and behavior model. The data model is present in all service instances. Even if the

value is “null”, the service is still deemed to have a data model. The data models are




strongly linked to the behavior models. For example, in a Request-Response behavior

model, the corresponding data model would have two components – the input (service

Request) data model and the output (service Response) data model. Data models may be

further specialized to match the behavior model if it is other than “Request-Response”.

The behavior model is decomposable into the action model and the process model. The

sequence of messages flowing into and out of the service is captured in the action model

while the service’s processing of those signals is captured in the processing model. The

processing model is potentially confusing as some aspects of it may remain invisible to

external entities and its inner working known only to the service provider.

3.0 A Reference Architecture for Service Oriented Architecture

Reference architecture is a more concrete artifact used by architects. Unlike the reference

model, it can introduce additional details and concepts to provide a more complete picture

for those who may implement a particular class. Reference architectures declare details that

would be in all instances of a certain class, much like an abstract constructor class in

programming. Each subsequent architecture designed from the reference architecture

would be specialized for a specific set of requirements. Reference architectures often

introduce concepts such as cardinality, structure, infrastructure, and other types of binary

relationship details. Accordingly, reference models do not have service providers and

consumers. If they did, then a reference model would have infrastructure (between the two

concrete entities) and it would no longer be a model.

The reference model and the reference architecture are intended to be part of a set of

guiding artifacts that are used with patterns. Architects can use these artifacts in

conjunction with others to compose their own SOA. The relationships are depicted in Figure

3.1.




Figure 3.1 – The architectural framework for SOA (Courtesy of OASIS).

The concepts and relationships defined by the reference model are intended to be the basis

for describing reference architectures that will define more specific categories of SOA

designs. Specifically, these specialized architectures will enable solution patterns to solve

particular problems. Concrete architectures may be developed based upon a combination of

reference architectures, architectural patterns, and additional requirements, including those

imposed by technology environments. Architecture is not done in isolation; it must account

for the goals, motivation, and requirements that define the actual problems being

addressed. While reference architectures can form the basis of classes of solutions, concrete

architectures will define specific solution approaches.

Architects and developers also need to bind their own SOA to concrete standards

technologies and protocols at some point. These are typically part of the requirements

process. For example, when building a highly efficient client side Mashup application, a

developer might opt for the ActionScript Messaging Format (AMF) to provide the most

efficient communication between remote services and the client.

Neutrality

The reference architecture shown in Figure 3.2 is not tied to any specific technologies,

standards, or protocols. In fact, it would be equally applicable to a .NET or J2EE environment

and can be used with either the Web Service family of technologies, plain old XML-RPC (XML

– Remote Procedure Call), or a proprietary set of standards. This reference architecture




allows developers to make decisions and adopt technologies that are best suited to their

specific requirements.

Figure 3.2 – A generic SOA Reference Architecture for implementing core Web 2.0 design

patterns (Courtesy of O’Reilly Media)

3.1 Service Tier

The server side component of the reference architecture has a number of commonly used

components. The Service Provider Interface is the main integration point whereby service

providers connect to capabilities that exist in internal systems in order to expose them as

services. These internal applications typically reside in a resource tier, a virtual collection of

capabilities that become exposed as services so consumers can access their functionality.

Service providers may integrate such capabilities using numerous mechanisms, including

using other services. In most cases, an enterprise will use the Application Programmatic

Interface (API) of the system as provided by the application vendor.

The Service Invocation Layer is where services are invoked. A service may be invoked when

an external messages being received or, alternatively, it can be invoked by an internal

system or by a non-message based event (such as a time out). It is essential to understand

that services may be invoked via messages from multiple sets of standards and protocols

working together. Common examples of external service interface endpoints include:

• Asynchronous JavaScript and XML (AJAX),

• Simple Object Access Protocol (SOAP),




• XML Remote Procedure Call (XML-RPC),

• A watched folder being polled for content,

• An email endpoint, and

• Other REST style endpoints including plain old HTTP and HTTP/S.

Services may also be invoked by local consumers including environments like J2EE and

language specific interfaces (for example - Plain Old Java Objects or POJO’s).

Each service invocation is often handed to a new instance of a service container. The service

container is responsible for handling the service invocation request for its entire lifecycle,

until either it reaches a successful conclusion or failed end state. Regardless of its ultimate

end state, the service container may also delegate responsibilities for certain aspects of the

service’s runtime to other services for common tasks. These tasks typically include logging

functions, archiving, security, and authentication, among others.

To facilitate orchestration and aggregation of services into processes and composite

applications, a registry-repository is often used. During the process design phase, the

registry-repository provides a single view of all services and related artifacts. The repository

provides a persistence mechanism for artifacts during the runtime of processes and

workflows. If multiple system actors use and interact with a form, the repository (place

where we put documents) can exist it while allowing access to privileged individuals.

Design, development and governance tools are also commonly used by humans to deploy,

monitor, and aggregate multiple services into more complex processes and applications.

3.2 Client Tier

While much attention has been focused on the server side aspects of SOA, less has been

written about the new breed of clients evolving for consuming services. The clients have

evolved to embrace many common architecture and design patterns discussed in greater

detail in the next section. A highly visible example of this is the ability of most modern

browsers to subscribe to RSS feeds.




Figure 3.3 – client application architecture

As depicted in Figure 3.3, clients must have far more robust communications services than a

decade ago. In fact, any communication standards, protocols and technologies (such as

SOAP, ActionScript Messaging Format, or XML-RPC) have to be implemented on both sides

to facilitate proper communications. Client side communications buses also need to monitor

the state of communications including potentially both synchronous and asynchronous

exchange patterns.

The main controller of each client application must be capable of launching various runtime

environments. This is typically done via launching one or more virtual machines that can

interpret scripting languages or consume byte code as in Adobe Flash. The architecture for

these virtual machines varies greatly depending upon the language used. Some compile an

intermediate level byte code just in time to run a program while others must be launched

and make multiple passes over a script (usually once to check it for errors, another time to

run the script, and a concurrent iteration to collect garbage and free up memory as it

becomes possible to reallocate.

Most modern clients have some form of data persistence and state management. This

usually works in conjunction with the clients’ communications services to allow the

controller to use cached resources rather than attempting to synchronize states if

communications are down. Additionally, rendering and media functionality specific to one

or more languages is used to ensure the view of the application is built in accordance with

the intentions of the application developer.

The security models used by different clients also vary somewhat. The usual tenets are to

prevent unauthorized and undetected manipulation of local resources. In distributed

computing architectures, identity (knowing who and what) is a major problem that requires

a complex architecture to address. Each client side application must be architected in

accordance with the acceptable level of risk based on the user requirements.




3.3 Architectural Conventions spanning multiple tiers

While examining the client and service tiers of the reference architecture, developers will

note some commonalities. Architects need to employ common models for determining

what constitutes an object, what constitutes an event, how an event gets noticed or

captured, what constitutes a change in state, and more. As a result, architecture must take

note of several common architectural models over all tiers of modern SOAs.

First and foremost, the core axioms of service oriented architecture should be observed.

Services themselves should be treated as subservient to the higher level system or systems

that use them. If you are deploying services to be part of an automated process

management system, the services themselves should not know (or care) what they are

being used for.

Services that are designed otherwise are architecturally inelegant for a number of reasons.

First, if services were required to know the state of the overall process, state misalignment

would likely result if two services had differing states for even a fraction of a second. In such

instances, errors might be thrown when this is detected or worse, developers would have to

rely on using a series of synchronous calls to services rather than forking a process into

asynchronous calls. As depicted in Figure 3.4, services should remain agnostic to what they

are used for. The state of a process or other application using services should be kept within

the higher layer of logic that uses consumers to invoke the services.

Figure 3.4 – services within overall architecture

Second, if the overall process stalled or failed for some reason, each service used would

have to be notified and rolled back to a previous state. Having services maintain or store the

overall state of a process that uses more than one service is an anti-pattern of SOA and

should be avoided.




Another core architectural convention is to keep the service consumers agnostic to how the

services are delivering their functionality. This results in a clean decoupling of components,

another architecturally elegant feature of modern service oriented systems. Having

dependencies on knowing the internal working of the services functionality is another anti-

pattern of SOA and should also be avoided.

Service composition, the act of building an application out of multiple services, is likewise an

anti-pattern of SOA, if composition is defined as per Unified Modeling Language (UML) 2.0.

Composition is depicted as a “has a” relationship and the whole is composed of the parts.

The correct terminology should be service aggregation.

Aggregation is a “uses a” type of relationship. The differences are quite subtle but

nevertheless important to grasp. In composition relationships, the life cycles of parts are

tied to the lifecycle of the whole and when the whole no longer exists, the parts no longer

exist either. In aggregation, the parts exist independent of the whole and can go on living

after the entity that uses them no longer exists. This terminology is common within both

OOPSLA and UML. Regardless, the term “service composition” has been misused widely

within the computer industry and will likely prevail as a norm. Architects and developers

should pay close attention to the types of binary relationships between components in

loosely coupled, distributed systems and bear these definitions in mind.

3.4 Events

Architects and developers using the reference architecture within this paper should also

consider the event architecture. Events often must be detected and acted upon. Each

specific programming language has a form of event architecture for detection, dispatching

messages, and capturing and linking behaviors to events. The main challenge presented in

distributed, service oriented systems is that the event model must traverse multiple

environments and possibly span multiple domains. Detecting an event in one domain,

dispatching a message to a remote system and linking the event to an action in a virtual

machine running on the remote system presents multiple challenges. Architects and

developers must often bridge disparate systems. Having a common model used by all

systems makes the traversal of systems much easier for developers and architects alike.




3.5 Objects

In much the same way they treat events, each disparate environment in a distributed

service oriented environment might have a distinct notion of what constitutes an object.

Relying on programming environments and languages that are aligned conceptually with

respect to objects (that is, “object-oriented”) makes the work of architects and developers

much easier. Languages such as JavaScript (specifically JavaScript Object Notation or JSON),

Java, ActionScript, and others have alignment on object concepts. (Note: ECMA’s

ActionScript 3.0 is much more object-oriented than previous incarnations and is strongly tied

to Java). When a developer must implement a pattern where an object’s state must be

tracked in a remote location and action taken upon a state change on the object, a common

model for object and encapsulation is important.

3.6 Architectural Patterns

As noted in the reference architecture in Figure 3.1, architecture and design patterns are an

important aspect of any architecture.

Patterns are recurring solutions to recurring problems. A pattern is composed of a problem,

the context in which the problem occurs, and the solution to resolve this problem. The focus

of a documented software architecture pattern is to illustrate a model to capture the

structural organization of a system, relate that to its requirements and highlight the key

relationships between entities within the system. The modern day concept of patterns

evolved from work by Christopher Alexander, the primary author of a book called “A Pattern

Language”xiii which had a great influence on object-oriented programming. The basic

concept of the book was a realization that patterns are the same when architecting a city, a

block, a house and a room. Each of these entities employs similar patterns.

The concepts of patterns in software architecture have been widely adopted since being

modified by the infamous Gang of Fourxiv and are now an accepted part of the engineering

trade.

4.0 Data and Message Exchange Patterns for Enterprise SOA

The most basic message exchange pattern is a common Request-Response where the

parties can simply communicate with each other. This is the basic building block of most

SOA interactions and is depicted below.




4.1 Request-Response

Request-Response is a pattern in which the service consumer uses configured client

software to issue an invocation request to a service provided by the service provider. The

request results in an optional response, as shown in Figure 4-1.

Figure 4-1. SOA Request-Response pattern

4.2 Request-Response via Service Registry (or Directory)

An optional service registry (database of configuration settings) can be used within the

architecture to help the client automatically configure certain aspects of its service client.

The service provider pushes changes regarding the service’s details to the registry to which

the consumer has subscribed. When the changes are made, the service consumer is notified

of these changes and can configure its service client to talk to the service. This is

represented conceptually in

Figure 4-2:

Figure 4-2. SOA Request-Response pattern with a service registry

4.3 Subscribe-Push




A third pattern for interaction is called Subscribe-Push, shown in Figure 4-3. In this pattern,

one or more clients register subscriptions with a service to receive messages based on some

criteria. Regardless of the criteria, the externally visible pattern remains the same.

Subscriptions may remain in effect over long periods before being canceled or revoked. A

subscription may, in some cases, also register another service endpoint to receive

notifications. For example, an emergency management system may notify all fire stations in

the event of a major earthquake using a common language such as the OASIS Common

Alerting Protocol (CAP).

Figure 4-3. SOA Subscribe-Push pattern

Note that this pattern can be triggered by a multitude of events. In figure 4-3, an auditable

event is triggering a message being sent to a subscribed client. The trigger could be a service

consumer’s action, a timeout action, or a number of other actions that are not listed in the

example above. Each of these represents a specialization of the Subscribe-Push pattern.

4.4 Probe and Match

A pattern used for discovery of services is the Probe and Match pattern. In this variation,

shown in Figure 4-4, a single client may multicast or broadcast a message to several

endpoints on a single fabric, prompting them to respond based on certain criteria. For

example, this pattern may be used to determine whether large numbers of servers on a

server farm are capable of handling more traffic by checking if they are scaled at less than

50% capacity. This variation of the SOA message exchange pattern may also be used to

locate specific services. There are caveats with using such a pattern, as it may become

bandwidth-intensive if used often. Utilizing a registry or another centralized metadata

facility may be a better option because the registry interaction does not require sending the




messages to all endpoints to find one. By convention, they allow the query to locate the

endpoint using a filter query or other search algorithm.

Figure 4-4. SOA Probe and Match pattern

In the Probe and Match scenario in Figure 4-4, the service client probes three services, yet

only the middle one returns an associated match() message. A hybrid approach could use

the best of both the registry and the probe and match models for locating service

endpoints. In the future, registry software could implement a probe interface to allow

service location without requiring wire transactions going to all endpoints and the searching

mechanism could probe multiple registries at the same time.

4.5 Patterns for RIAs

Creating Rich Internet Applications (RIAs) requires a level of data management that goes

beyond the traditional Request-Response model. Providing a richer, more expressive

experience often requires more data-intensive interaction and introduces new challenges in

managing data between the client and server tiers.

Data synchronization is a key concept and requires states to be shared among multiple

machines. These are usually the clients who have subscribed to the state of an object

somewhere within the tier of a distributed system as depicted in Figure 4.5.




Figure 4.5 – data synchronization across multiple clients.

4.6 Data paging

Some services automatically facilitate the paging of large data sets, enabling developers to

focus on core application business logic instead of worrying about basic data management

infrastructure.

Modern service oriented clients and server infrastructures automatically handle temporary

disconnects, ensuring reliable delivery of data to and from the client application.

4.7 Data push

Some services offer data-push capability, enabling data to automatically be pushed to the

client application without polling (contrast this pattern to the “Subscribe-Push pattern listed

above). This can be done via intuitive or inference methods to ensure data is provided as

required. This highly scalable capability can push data to thousands of concurrent users,

providing up-to-the-second views of critical data, such as stock trader applications, live

resource monitoring, shop floor automation, and more.

Data push can be further specialized into broadcast, unicast, multicast, and several other

specializations of the basic pattern.




5.0 SOA Benefits

SOA enables development of a new generation of dynamic applications that address a

number of top-level business concerns that are central to grow and competitiveness. It

provides the framework through which to simplify the creation and management of

integrated systems and applications, and a way to align IT assets with the business model

and changing business needs. The benefits of implementing SOA include:

Enhanced business decision making:

By aggregating access to business services and information into a set of dynamic, composite

business applications, decision makers gain more accurate and more comprehensive

information.

Greater employee productivity:

By providing streamlined access to systems and information and enabling business process

improvement, businesses can drive greater employee productivity.

Stronger connections with customers and suppliers:

The benefits of SOA extend beyond organizational boundaries. Mergers and acquisitions

become more profitable, since it is easier to integrate disparate systems and applications.

Integration with trading partners and streamlining of supply chain processes are readily

attainable goals.

More productive, more flexible applications:

The service oriented approach enables IT to make existing IT assets—including legacy

systems and applications—more productive and more profitable to the business without the

need for custom-coded one-off integration solutions.

Faster, more cost-effective application development:

Standards-based service design enables IT to create a repository of reusable services that

can be combined into higher level services and composite applications as new business

needs arise.




More manageable and secure applications:

Service oriented solutions provide a common infrastructure (and documentation) for

developing secure, monitored, and predictable services. As business needs change, SOA

makes it easier to add in new services and capabilities that map onto critical business

processes.

Web 2.0:

The term Web 2.0 is associated with web applications that facilitate participatory

information sharing, interoperability, user-centered design, and collaboration on the World

Wide Web. A Web 2.0 site allows users to interact and collaborate with each other in a

social media dialogue as creators (prosumers) of user-generated content in a virtual

community, in contrast to websites where users (consumers) are limited to the passive

viewing of content that was created for them. Examples of Web 2.0 include social

networking sites, blogs, wikis, video sharing sites, hosted services, web applications,

mashups and folksonomies.

The term is closely associated with Tim O'Reilly because of the O'Reilly Media Web 2.0

conference in late 2004. Although the term suggests a new version of the World Wide Web,

it does not refer to an update to any technical specification, but rather to cumulative

changes in the ways software developers and end-users use the Web. Whether Web 2.0 is

qualitatively different from prior web technologies has been challenged by World Wide Web

inventor Tim Berners-Lee, who called the term a "piece of jargon", precisely because he

intended the Web in his vision as "a collaborative medium, a place where we [could] all

meet and read and write". He called it the "Read/Write Web"

Web 2.0 Technologies

The client-side/web browser technologies used in Web 2.0 development are Asynchronous

JavaScript and XML (Ajax), Adobe Flash and the Adobe Flex framework, and JavaScript/Ajax

frameworks such as Yahoo! UI Library, Dojo Toolkit, MooTools, and jQuery. Ajax

programming uses JavaScript to upload and download new data from the web server

without undergoing a full page reload.




To allow users to continue to interact with the page, communications such as data requests

going to the server are separated from data coming back to the page (asynchronously).

Otherwise, the user would have to routinely wait for the data to come back before they can

do anything else on that page, just as a user has to wait for a page to complete the reload.

This also increases overall performance of the site, as the sending of requests can complete

quicker independent of blocking and queuing required to send data back to the client.

The data fetched by an Ajax request is typically formatted in XML or JSON (JavaScript Object

Notation) format, two widely used structured data formats. Since both of these formats are

natively understood by JavaScript, a programmer can easily use them to transmit structured

data in their web application. When this data is received via Ajax, the JavaScript program

then uses the Document Object Model (DOM) to dynamically update the web page based

on the new data, allowing for a rapid and interactive user experience. In short, using these

techniques, Web designers can make their pages function like desktop applications. For

example, Google Docs uses this technique to create a Web-based word processor.

Adobe Flex is another technology often used in Web 2.0 applications. Compared to

JavaScript libraries like jQuery, Flex makes it easier for programmers to populate large data

grids, charts, and other heavy user interactions.[22] Applications programmed in Flex, are

compiled and displayed as Flash within the browser. As a widely available plugin

independent of W3C (World Wide Web Consortium, the governing body of web standards

and protocols), standards, Flash is capable of doing many things which were not possible pre

HTML 5, the language used to construct web pages. Of Flash's many capabilities, the most

commonly used in Web 2.0 is its ability to play audio and video files. This has allowed for the

creation of Web 2.0 sites where video media is seamlessly integrated with standard HTML.

In addition to Flash and Ajax, JavaScript/Ajax frameworks have recently become a very

popular means of creating Web 2.0 sites. At their core, these frameworks do not use

technology any different from JavaScript, Ajax, and the DOM. What frameworks do is

smooth over inconsistencies between web browsers and extend the functionality available

to developers. Many of them also come with customizable, prefabricated 'widgets' that

accomplish such common tasks as picking a date from a calendar, displaying a data chart, or

making a tabbed panel.

On the server side, Web 2.0 uses many of the same technologies as Web 1.0. New languages

such as PHP, Ruby, ColdFusion, Perl, Python, JSP and ASP are used by developers to




dynamically output data using information from files and databases. What has begun to

change in Web 2.0 is the way this data is formatted. In the early days of the Internet, there

was little need for different websites to communicate with each other and share data. In the

new "participatory web", however, sharing data between sites has become an essential

capability. To share its data with other sites, a web site must be able to generate output in

machine-readable formats such as XML, RSS, and JSON. When a site's data is available in

one of these formats, another website can use it to integrate a portion of that site's

functionality into itself, linking the two together. When this design pattern is implemented,

it ultimately leads to data that is both easier to find and more thoroughly categorized, a

hallmark of the philosophy behind the Web 2.0 movement.

In brief, AJAX is a key technology used to build Web 2.0 because it provides rich user

experience and works with any browser whether it is Firefox, Internet Explorer or another

popular browser. Then, a language with very good web services support should be used to

build Web 2.0 applications. In addition, the language used should be iterative meaning that

it will help easy and fast the addition and deployment of features.

Concepts

Web 2.0 can be described in 3 parts which are as follows:

Rich Internet Application (RIA) - It defines the experience brought from desktop to

browser whether it is from a graphical point of view or usability point of view. Some

buzz words related to RIA are AJAX and Flash.

Service-oriented Architecture (SOA) - It is a key piece in Web 2.0 which defines how

Web 2.0 applications expose its functionality so that other applications can leverage

and integrate the functionality providing a set of much richer applications (Examples

are: Feeds, RSS, Web Services, Mash-ups)

Social Web - It defines how Web 2.0 tends to interact much more with the end user

and making the end user an integral part.

As such, Web 2.0 draws together the capabilities of client- and server-side software, content

syndication and the use of network protocols. Standards-oriented web browsers may use

plug-ins and software extensions to handle the content and the user interactions. Web 2.0

sites provide users with information storage, creation, and dissemination capabilities that

were not possible in the environment now known as "Web 1.0".




Web 2.0 websites include the following features and techniques: Andrew McAfee used the

acronym SLATES to refer to them

Search

Finding information through keyword search.

Links

Connects information together into a meaningful information ecosystem using the

model of the Web, and provides low-barrier social tools.

Authoring

The ability to create and update content leads to the collaborative work of many

rather than just a few web authors. In wikis, users may extend, undo and redo each

other's work. In blogs, posts and the comments of individuals build up over time.

Tags

Categorization of content by users adding "tags" - short, usually one-word

descriptions - to facilitate searching, without dependence on pre-made categories.

Collections of tags created by many users within a single system may be referred to

as "folksonomies" (i.e., folk taxonomies).

Extensions

Software that makes the Web an application platform as well as a document server.

These include software like Adobe Reader, Adobe Flash player, Microsoft Silverlight,

ActiveX, Oracle Java, Quicktime, Windows Media, etc.

Signals The use of syndication technology such as RSS to notify users of content changes.

While SLATES forms the basic framework of Enterprise 2.0, it does not contradict all of the

higher level Web 2.0 design patterns and business models. In this way, a new Web 2.0

report from O'Reilly is quite effective and diligent in interweaving the story of Web 2.0 with

the specific aspects of Enterprise 2.0. It includes discussions of self-service IT, the long tail of

enterprise IT demand, and many other consequences of the Web 2.0 era in the enterprise.

The report also makes many sensible recommendations around starting small with pilot

projects and measuring results, among a fairly long list.

Web2.0 Usage

A third important part of Web 2.0 is the social Web, which is a fundamental shift in the way

people communicate. The social web consists of a number of online tools and platforms




where people share their perspectives, opinions, thoughts and experiences. Web 2.0

applications tend to interact much more with the end user. As such, the end user is not only

a user of the application but also a participant by:

Podcasting

Blogging

Tagging

Contributing to RSS

Social bookmarking

Social networking

The popularity of the term Web 2.0, along with the increasing use of blogs, wikis, and social

networking technologies, has led many in academia and business to coin a flurry of 2.0s,

including Library 2.0, Social Work 2.0, Enterprise 2.0, PR 2.0, Classroom 2.0, Publishing 2.0,

Medicine 2.0, Telco 2.0, Travel 2.0, Government 2.0, and even Porn 2.0. Many of these 2.0s

refer to Web 2.0 technologies as the source of the new version in their respective disciplines

and areas.

The meaning of web 2.0 is role dependent, For example, some use Web 2.0 to establish and

maintain relationships through social networks, while some marketing managers might use

this promising technology to "end-run traditionally unresponsive I.T. departments”.

There is a debate over the use of Web 2.0 technologies in mainstream education. Issues

under consideration include the understanding of students' different learning modes; the

conflicts between ideas entrenched in informal on-line communities and educational

establishments' views on the production and authentication of 'formal' knowledge; and

questions about privacy, plagiarism, shared authorship and the ownership of knowledge and

information produced and/or published on line.

Marketing

For marketers, Web 2.0 offers an opportunity to engage consumers. A growing number of

marketers are using Web 2.0 tools to collaborate with consumers on product development,

service enhancement and promotion. Companies can use Web 2.0 tools to improve

collaboration with both its business partners and consumers. Among other things, company




employees have created wikis—Web sites that allow users to add, delete and edit content—

to list answers to frequently asked questions about each product, and consumers have

added significant contributions. Another marketing Web 2.0 lure is to make sure consumers

can use the online community to network among themselves on topics of their own

choosing.

Mainstream media usage of web 2.0 is increasing. Saturating media hubs—like New York

Times, PC Magazine and Business Week—with links to popular new web sites and services,

is critical to achieving the threshold for mass adoption of those services.

Web 2.0 offers financial institutions abundant opportunities to engage with customers.

Networks such as Twitter,Linkedin & Facebook are now becoming common elements of

multichannel and customer loyalty strategies, and banks are beginning to use these sites

proactively to spread their messages. In a recent article for Bank Technology News, Shane

Kite describes how Citigroup's Global Transaction Services unit monitors social media outlets

to address customer issues and improve products. Furthermore, CitiGroup uses Twitter to

release "breaking news" and upcoming events, and YouTube to disseminate videos that

feature executives speaking about market news.

Small businesses have become more competitive by using Web 2.0 marketing strategies to

compete with larger companies. As new businesses grow and develop, new technology is

used to decrease the gap between businesses and customers. Social networks have become

more intuitive and user friendly to provide information that is easily reached by the end

user. For example, companies use Twitter to offer customers coupons and discounts for

products and services.

According to Google Timeline, the term Web 2.0 was discussed and indexed most frequently

in 2005, 2007 and 2008. Its average use is continuously declining by 2–4% per quarter since

April 2008.

Web 2.0 Web-based applications and desktop Applications

Ajax has prompted the development of websites that mimic desktop applications, such as

word processing, the spreadsheet, and slide-show presentation. In 2006 Google, Inc.

acquired one of the best-known sites of this broad class, Writely. WYSIWYG wiki and

blogging sites replicate many features of PC authoring applications.




Several browser-based "operating systems" have emerged, including EyeOS and YouOS.

Although coined as such, many of these services function less like a traditional operating

system and more as an application platform. They mimic the user experience of desktop

operating-systems, offering features and applications similar to a PC environment, and are

able to run within any modern browser. However, these operating systems do not directly

control the hardware on the client's computer.

Numerous web-based application services appeared during the dot-com bubble of 1997–

2001 and then vanished, having failed to gain a critical mass of customers. In 2005, WebEx

acquired one of the better-known of these, Intranets.com, for $45 million.

Internet applications

Rich Internet Applications (RIAs) are web 2.0 applications that have many of the

characteristics of desktop applications and are typically delivered via a browser.

Distribution of Media

XML and RSS

Many regard syndication of site content as a Web 2.0 feature. Syndication uses standardized

protocols to permit end-users to make use of a site's data in another context (such as

another website, a browser plugin, or a separate desktop application). Protocols which

permit syndication include RSS (really simple syndication, also known as web syndication),

RDF (as in RSS 1.1), and Atom, all of them XML-based formats. Observers have started to

refer to these technologies as web feeds.

Specialized protocols such as FOAF and XFN (both for social networking) extend the

functionality of sites or permit end-users to interact without centralized websites.

Web APIs

Web 2.0 often uses machine-based interactions such as REST and SOAP. Servers often

expose proprietary APIs (Application Programming Interfaces), but standard APIs (for

example, for posting to a blog or notifying a blog update) have also come into use. Most

communications through APIs involve XML or JSON payloads.




REST APIs, through their use of self-descriptive messages and hypermedia as the engine of

application state, should be self describing once an entry URI is known. Web Services

Description Language (WSDL) is the standard way of publishing a SOAP API and there are a

range of web service specifications. EMML, or Enterprise Mashup Markup Language by the

Open Mashup Alliance, is an XML markup language for creating enterprise mashups.

Web 2.0 Buzzwords

Here are a few of the buzzwords that are driving the Web 2.0 era:

API: Application Programming Interface is a code interface over which programmer can built

their own applications. APIs make it possible for the programmers to use some great

features on the web without any complex coding.

Atom: Atom is a commonly used syndication format for web feeds. It is based on XML and is

supported by most standard feed readers.

Blog: Blog or a Weblog is an online journal, which provides an easy to use interface for users

to publish content. Blogs enable people to have an online presence without having any

technical knowledge.

Feeds: Feeds allow you to get updates from the websites. It allows you to check the recent

articles and content from web pages on the internet. A person may subscribe to a news feed

to get the latest news right on his desktop.

Folksonomy: Folksonomy is the practice of collaboratively categorizing content by tagging

the content under various connotations. This method is popularly applied in social

bookmarking and tagging webpages and photos.

Mashup: Mashups are a interactive genre of web applications which accumulates data from

various sources and conflates it in a single integrated application. Mashup generally collects

data from Feeds and Web Services.

Microformats: Microformats are a set of simple open data formats, which allows the normal

data in HTML and XHTML to be categorized by providing annotations in the existing markup.




It aims at easier access of information such as contact addresses, locations etc making it

easily place able by the searching software.

Perpetual Beta: Perpetual Beta is the software stage where the software is launched and is

always under constant updates, which could be monthly, weekly or even daily. It follows the

principle of "release early and release often", thus software is released at a premature state

and new features are added frequently.

Podcast: Podcast is a form of a feed carrying digital media files which could be downloaded

or streamed on media players. Online radio is a well comprehensible example of a podcast.

RSS: Really Simple Syndication is a collection of feed formats. It is used to syndicate updated

content from a website.

SEO: Search Engine Optimization is a process of improving your rankings on the search

engines by using a set of techniques, which include ameliorating the quality of content and

code of the website, placing links at strategic locations on the web and adhering to some

web standards.

Social Bookmarking: Social Bookmarking is a folksonomy practice through which users

bookmark pages on the web and create custom tags to annotate these pages.

Social Networking: Social networking is a method to promote online collaboration of people

by creating communities of (net) citizens with similar interests. It is a popular method to

connect with friends online.

Tagging:

Tagging is a practice of annotating the web content by creating tags or keywords to identify

them.

Web Service: Web Services are the modules enable a programmer to use these modules in

their programs without actually coding them. It allows machine to machine data transfer

between applications in XML format that follow the SOAP standard.




Wiki: Wiki is a web application which allows you to easily create and edit content on the

web. It is used to create collaborative websites and is a great tool for social content creation

and organization.

XML: eXtensible Markup Language is a markup language which allows users to generate

their own tags. It enables creation of structured data that could be easily exchanged over

the web.

3.2 Web 1.0 vs. Web 2.0

The transition from Web 1.0 to Web 2.0 can be effectively presented by the following

transformations:

Read only to read/write web

Less user generated content to more

250,000 sites to about 80 million sites (2006) and crossed 100 million in 2010.

45 million users to 1.5 billion users and still growing rapidly

Static published content to user contributed dynamic published content.




Convergence of SOA and Web 2.0

There are at least two significant connection points which relate Web 2.0 and SOA. One is

that Web 2.0 can be conceptualized as a global SOA. Two, that many traditional brick and

mortar business that are currently using SOA as their architectural model will want to

connect their Web/Web 2.0 faces up to their SOA. This makes Web 2.0 not just being the

Global SOA but makes meeting smaller SOAs everywhere not just likely, but inevitable. Note

that the respected industry analysis firm, Gartner, recently said that by 2008 80% of all

software development will be based on SOA. And interestingly by 2006, Gartner believes

that 60% of the $527 billion IT professional services industry will be based on exploiting Web

services and technology. We're talking serious convergence of focus here folks. If true, this

means that more than half of all software development, SOA and otherwise, will revolve

around the Web, inside or outside organization boundaries. All of this means Web 2.0 and

SOA will meet each other both coming and going, and begin to become each other as well.

Figure 1: Differences and Similarities between Web 2.0 and SOA




Software as a Service

Another concept closely related to SOA is the notion of Software as a Service (SaaS).Simply

put, SaaS can be defined as "software deployed as a hosted service and accessed over the

Internet."

SaaS as a concept is often associated with the application service providers (ASPs) of the

1990s, which provided "shrink-wrap" applications to business users over the Internet. These

early attempts at Internet-delivered software had more in common with traditional on

premise applications than with modern SaaS applications in some ways, such as licensing

and architecture. Because these applications were originally built as single tenant

applications, their ability to share data and processes with other applications was limited,

and they tended to offer few economic benefits over their locally installed counterparts.

Today, SaaS applications are expected to take advantage of the benefits of centralization

through a single-instance, multi-tenant architecture, and to provide a feature-rich

experience competitive with comparable on-premise applications. A typical SaaS application

is offered either directly by the vendor or by an intermediary party called an aggregator,

which bundles SaaS offerings from different vendors and offers them as part of a unified

application platform.

In contrast to the one-time licensing model commonly used for on-premise

software, SaaS application access is frequently sold using a subscription model, with

customers paying an ongoing fee to use the application. Fee structures vary from

application to application; some providers charge a flat rate for unlimited access to some or

all of the application's features, while others charge varying rates that are based on usage.




Web Technologies

The web technologies used for SOA and Web 2.0 can be divided into four classes: Client

Side, Server Side, Web Services and Mashups. The subsequent sections will provide the

details about these.

6.1 Client Side Technologies

The client side technologies are a set of programming methodologies which are sent as

raw code to the client and are rendered by the application running on the user’s system.

Some of the commonly used technologies are:

XHTML: eXtensible HyperText Markup Language is a standard W3C markup language, which

is a reformation of HTML adhering to the XML standard.

CSS: Cascading Style Sheets is a W3C standard for defining styles of the elements on a web

page. It enables the separation of content from the layout, thus providing more flexibility

and control of the elements on a web page. Also, it enables layering of the content on the

page.

AJAX: Asynchronous JavaScript and XML is a scripting technique to develop interactive and

fast web applications with enhanced functionality. The most commendable feature of AJAX

is its ability of partial exchange of data with the server, enabling the changes to appear on

the browser without reloading the complete page.

VRML: Virtual Reality Modeling Language is a standard file format for representing 3-

dimensional (3D) interactive vector graphics, designed particularly for the Internet.

6.2 Server Side Technologies

Server Side technologies are a group of languages used to program the functionalities which

have to be executed on the server. The most common examples of such functionality are

the applications which require accessing the database. Some commonly used server side

technologies are as follows:




ASP.NET: ASP.NET is a web application framework marketed by Microsoft that programmers

can use to build dynamic web sites, web applications and XML web services. It is part of

Microsoft's .NET platform and is the successor to Microsoft's Active Server Pages (ASP)

technology. ASP.NET is built on the Common Language Runtime, allowing programmers to

write ASP.NET code using any Microsoft .NET language.

PHP: PHP Hypertext Preprocessor is an open-source web scripting language to generate

dynamic web pages. It can also be used from a command line interface or in standalone

graphical applications.

CGI: Common Gateway Interface is a standard protocol for interfacing external application

software with an information server, commonly a web server. This allows the server to pass

requests from a client web browser to the external application. The web server can then

return the output from the application to the web browser. The external application may be

written in any high level language like C++, Pearl etc.

JSP: Java Server Pages is a Java technology that allows software developers to dynamically

generate HTML, XML or other types of documents in response to a Web client request. The

technology allows Java code and certain pre-defined actions to be embedded into static

content.

6.3 Web Services

The W3C defines a Web Service as "a software system designed to support interoperable

Machine to Machine interaction over a network." Web services are frequently just Web APIs




that can be accessed over a network, such as the Internet, and executed on a remote

system hosting the requested services. The W3C Web service definition encompasses many

different systems, but in common usage the term refers to clients and servers that

communicate using XML messages that follow the SOAP standard. Common in both the field

and the terminology is the assumption that there is also a machine readable description of

the operations supported by the server written in the Web Services Description Language

(WSDL).

Simple Object Access Protocol (SOAP): An XML-based, extensible message envelope format

with "bindings" to underlying protocols. The primary protocols are HTTP and HTTPS,

although bindings for others, including SMTP and XMPP, have been written.

Web Services Description Language (WSDL): An XML format that allows service interfaces

to be described along with the details of their bindings to specific protocols. Typically used

to generate server and client code, and for configuration.

Universal Description Discovery and Integration (UDDI): A protocol for publishing and

discovering metadata about Web services that enables applications to find them, either at

design time or runtime.

6.4 Mashups

Mashups are an interactive genre of web applications which accumulates data from various

sources and conflates it in a single integrated application. Mashup generally collects data

from Web feeds (e.g. RSS or Atom), web services and screen scraping. A mashup application

is architecturally comprised of three different participants that are logically and physically

disjoint (they are likely separated by both network and organizational boundaries):

API/content providers, the mashup site, and the client's Web browser.

Much like how blogs revolutionized online publishing, mashups are revolutionizing

web development by giving creative power to the masses. Many mashups are relatively easy

to design with minimal technical knowledge, and thus custom mashups are being designed

by unlikely innovators, utilizing data in creative and unique ways. While there are several

useful mashups, many are simple novelties or gimmicks, with minimal practical utility.

Mashups are certainly an exciting new genre of Web applications. The

combination of data modeling technologies stemming from the Semantic Web domain and




the maturation of loosely-coupled, service-oriented, platform-agnostic communication

protocols is finally providing the infrastructure needed to start developing applications that

can leverage and integrate the massive amount of information that is available on the Web.

As mashup applications gain higher visibility, it will be interesting to see how the genre

impacts social issues such as fair-use and intellectual property as well as other application

domains that integrate data across organizational boundaries, such as grid computing and

business-to-business workflow management.

Web 3.0

Definitions of Web 3.0 vary greatly. Some believe its most important features are the

Semantic Web and personalization. Focusing on the computer elements, Conrad Wolfram

has argued that Web 3.0 is where "the computer is generating new information", rather

than humans.

Andrew Keen, author of The Cult of the Amateur, considers the Semantic Web an

"unrealisable abstraction" and sees Web 3.0 as the return of experts and authorities to the

Web. For example, he points to Bertelsmann's deal with the German Wikipedia to produce

an edited print version of that encyclopedia. CNN Money's Jessi Hempel expects Web 3.0 to

emerge from new and innovative Web 2.0 services with a profitable business model. Others

still such as Manoj Sharma, an organization strategist, in the keynote "A Brave New World

Of Web 3.0" proposes that Web 3.0 will be a "Totally Integrated World" - cradle-to-grave

experience of being always plugged onto the net.

Futurist John Smart, lead author of the Metaverse Roadmap echoes Sharma's perspective,

defining Web 3.0 as the first-generation Metaverse (convergence of the virtual and physical

world), a web development layer that includes TV-quality open video, 3D simulations,

augmented reality, human-constructed semantic standards, and pervasive broadband,

wireless, and sensors. Web 3.0's early geosocial (Foursquare, etc.) and augmented reality

(Layar, etc.) webs are an extension of Web 2.0's participatory technologies and social

networks (Facebook, etc.) into 3D space. Of all its metaverse-like developments, Smart

suggests Web 3.0's most defining characteristic will be the mass diffusion of NTSC-or-better

quality open video to TVs, laptops, tablets, and mobile devices, a time when "the internet

swallows the television. Smart considers Web 4.0 to be the Semantic Web and in particular,

the rise of statistical, machine-constructed semantic tags and algorithms, driven by broad




collective use of conversational interfaces, perhaps circa 2020. David Siegel's perspective in

Pull: the Power of the Semantic Web, 2009, is consonant with this, proposing that the

growth of human-constructed semantic standards and data will be a slow, industry-specific

incremental process for years to come, perhaps unlikely to tip into broad social utility until

after 2020.

According to some Internet experts Web 3.0 will allow the user to sit back and let the

Internet do all of the work for them. Rather than having search engines gear towards your

keywords, the search engines will gear towards the user. Keywords will be searched based

on your culture, region, and jargon. For example, when going on a vacation you have to do

separate searches for your airline ticket, your hotel reservations, and your car rental. With

Web 3.0 you will be able to do all of this in one simple search. The search engine will

present the results in a comparative and easily navigated way to the user.

