Service oriented architecture & web 2.0

A Report on The integrated functionality of Service Oriented Architecture (SOA) & Web 2.0 By: 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. 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 DasAnil Kumar Sahu Roll No: 20104001Roll No: 20104004 Gandhinagar Dt: 01-03-2011 Table of Contents SL/No.DescriptionPage 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 quot;
Artifactquot;
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. 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 (HYPERLINK quot;
http://en.wikipedia.org/wiki/Prosumersquot;
quot;
Prosumersquot;
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 quot;
piece of jargonquot;
, precisely because he intended the Web in his vision as quot;
a collaborative medium, a place where we [could] all meet and read and writequot;
. He called it the quot;
Read/Write Webquot;
 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 quot;
participatory webquot;
, 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 quot;
Web 1.0quot;
. 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 quot;
tagsquot;
- 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 quot;
HYPERLINK quot;
http://en.wikipedia.org/wiki/Folksonomyquot;
quot;
Folksonomyquot;
folksonomiesquot;
(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: ,[object Object]

Social networkingThe 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 quot;
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 quot;
breaking newsquot;
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 quot;
operating systemsquot;
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 quot;
release early and release oftenquot;
, 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 ,[object Object]

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 quot;
software deployed as a hosted service and accessed over the Internet.quot;
 SaaS as a concept is often associated with the application service providers (ASPs) of the 1990s, which provided quot;
shrink-wrapquot;
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 quot;
a software system designed to support interoperable Machine to Machine interaction over a network.quot;
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 quot;
bindingsquot;
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 quot;
the computer is generating new informationquot;
, rather than humans. Andrew Keen, author of The Cult of the Amateur, considers the Semantic Web an quot;
unrealisable abstractionquot;
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 quot;
A Brave New World Of Web 3.0quot;
proposes that Web 3.0 will be a quot;
Totally Integrated Worldquot;
- 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 quot;
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.

Service oriented architecture & web 2.0

Service oriented architecture & web 2.0

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (19)

En vedette

En vedette (8)

Similaire à Service oriented architecture & web 2.0

Similaire à Service oriented architecture & web 2.0 (20)

Plus de Abhik Tushar Das

Plus de Abhik Tushar Das (13)

Dernier

Dernier (20)

Service oriented architecture & web 2.0