CONTENTS 1. Introduction 2. Definition Of Service Oriented Architecture 3. Service Oriented Architecture 3.1 Architecture 3.

2 The Service Architecture 3.3 The SOA Platform 3.4 The Enterprise SOA 4. SOA Infrastructure 4.1 Creation Of Service Oriented Environment 5. SOA Elements 6. Benefits 7. SOAP 8. SOA Disadvantages 9.SOA Road Blocks 10. Convergence of SOA And Web 2.0 11. Software As A Service

12. Web Technologies 12.1 Client Side Technologies 12.2 Server Side Technologies 12.3 Mashups 13. Tools for SOA And Web 2.0 13.1 Microsoft Visual Studio 13.2 Microsoft Silver Light 13.3 ASP.Net.AJAX 13.4 Microsoft Expression Studio 14. Quality Of Service 15. Conclusion

1.INTRODUCTION
Service Oriented Architecture (SOA) is an architectural style that guides all aspects of creating and using business processes, packaged as services, throughout their lifecycle, as well as defining and provisioning the IT infrastructure that allows different applications to exchange data and participate in business processes regardless of the operating systems or programming languages underlying those applications. SOA represents a model in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between one or more services. It is often seen as an evolution of distributed computing and modular programming.

2. DEFINITION OF SOA
A service-oriented architecture is essentially a collection of services. These services communicate with each other.The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed.Serviceoriented architectures are not a new thing. The first service-oriented architecture for many people in the past was with the use DCOM or Object Request Brokers (ORBs) based on the CORBA specification.

SERVICE ORIENTED ARCHITECTURE

Architectures
This process view that we have examined at is a prerequisite to thinking about the type of architecture required and the horizons of interest, responsibility and integrity. For SOA there are three important architectural perspectives as shown in Figure 1.

The Application Architecture. This is the business facing solution which consumes services from one or more providers and integrates them into the business processes. The Service Architecture. This provides a bridge between the implementations and the consuming applications, creating a logical view of sets of services which are available for use, invoked by a common interface and management architecture. The Component Architecture. This describes the various environments supporting the implemented applications, the business objects and their implementations.

Figure 1. Three Architectural Perspectives These architectures can be viewed from either the consumer or provider perspective. Key to the architecture is that the consumer of a service should not be interested in the implementation detail of the servicejust the service provided. The implementation architecture could vary from provider to provider yet still deliver the same service. Similarly the provider should not be interested in the application that the service is consumed in. New unforeseen applications will reuse the same set of services. The consumer is focused on their application architecture, the services used, but not the detail of the component architecture. They are interested at some level of detail in the general business objects that are of mutual interest, for example provider and consumer need to share a view of what an order is. But the consumer does not need to know how the order component and database are implemented.

Similarly, the provider is focused on the component architecture, the service architecture, but not on the application architecture Again, they both need to understand certain information about the basic applications, for example to be able to set any sequencing rules and pre and post conditions. But the provider is not interested in every detail of the consuming application.

The Service Architecture

At the core of the SOA is the need to be able to manage services as first order deliverables. It is the service that we have constantly emphasized that is the key to communication between the provider and consumer. So we need a Service Architecture that ensures that services don't get reduced to the status of interfaces, rather they have an identity of their own, and can be managed individually and in sets. CBDI developed the concept of the Business Service Bus (BSB) precisely to meet this need. The BSB is a logical view of the available and used services for a particular business domain, such as Human Resources or Logistics. It helps us answer questions such as:

What service do I need? What services are available to me? What services will operate together? (common semantics, business rules) What substitute services are available? What are the dependencies between services and versions of services?

Rather than leaving developers to discover individual services and put them into context, the Business Service Bus is instead their starting point that guides them to a coherent set that has been assembled for their domain. The purpose of the BSB is so that common specifications, policies, etc can be made at the bus level, rather than for each individual service. For example, services on a bus should all follow the same semantic standards, adhere to the same security policy, and all point to the same global model of the domain. It also facilitates the implementation of a number of common, lower-level business infrastructure services that can be aggregated into other higher level business services on the same bus (for example, they could all use the same product code validation service). Each business domain develops a vocabulary and a business model of both process and object. A key question for the Service Architecture is 'What is the scope of the service that is published to the Business Service Bus?' A simplistic answer is 'At a business level of abstraction'. However this answer is open to interpretationbetter to have some heuristics that ensure that the service is the lowest common denominator that meets the criteria of business, and is consumer oriented, agreed, and meaningful to the business. The key point here is that there is a process of aggregation and collaboration that should probably happen separately from the implementing component as illustrated in Figure 2. By making it separate, there is a level of flexibility that allows the exposed service(s) to be adjusted without modifying the underlying components. In

principle, the level of abstraction will be developed such that services are at a level that is relevant and appropriate to the consumer. The level might be one or all of the following:

Business Services Service Consumer Oriented Agreed by both Provider and Consumer Combine low-level implementation-based services into something meaningful to business Coarser Grained Suitable for External Use Conforms to pre-existing connection design

Figure 2. Levels of Abstraction

The SOA Platform

The key to separation is to define a virtual platform that is equally relevant to a number of real platforms. The objective of the virtual platform is to enable the separation of services from the implementation to be as complete as possible and allow

components built on various implementation platforms to offer services which have no implementation dependency. The virtual SOA platform comprises a blueprint which covers the development and implementation platforms. The blueprint provides guidance on the development and implementation of applications to ensure that the published services conform to the same set of structural principles that are relevant to the management and consumer view of the services. When a number of different applications can all share the same structure, and where the relationships between the parts of the structure are the same, then we have what might be called a common architectural style. The style may be implemented in various ways; it might be a common technical environment, a set of policies, frameworks or practices. Example platform components of a virtual platform include:

Host environment Consumer environment Middleware Integration and assembly environment Development environment Asset management Publishing & Discovery Service level management Security infrastructure Monitoring & measurement

Diagnostics & failure Consumer/Subscriber management Web service protocols Identity management Certification Deployment & Versioning

The Enterprise SOA

The optimum implementation architecture for SOA is a componentbased architecture. Many will be familiar with the concepts of process and entity component, and will understand the inherent stability and flexibility of this component architecture, which provide a one to one mapping between business entities and component implementations. Enterprise SOA (ESOA) brings the two main threadsWeb services and CBD (or CBSE)together. The result is an enterprise SOA that applies to both Web services made available externally and also to core business component services built or specified for internal use. It is beyond the scope of this article to explore ESOA in more depth. For more on this topic there is a five part CBDI Report Series on Enterprise SOA.

Figure 2. A sample service architecture.

In Figure 2, several service consumers can invoke services by sending messages. These messages are typically transformed and routed by a service bus to an appropriate service implementation. This service architecture can provide a business rules engine that allows business rules to be incorporated in a service or across services. The service architecture also provides a service management infrastructure that manages services and activities like auditing, billing, and logging. In addition, the architecture offers enterprises the flexibility of having agile business processes, better addresses the regulatory requirements like Sarbanes Oxley (SOX), and changes individual services without affecting other services. Companies have long sought to integrate existing systems in order to implement information technology (IT) support for business processes that cover all present and prospective systems requirements needed to run the business end-to-end. A variety of designs can be used to this end, ranging from rigid point-to-point electronic data interchange (EDI) interactions to Web auctions. By updating older technologies, such as Internet-enabling EDI-based systems, companies can make their IT systems available to internal or external customers; but the resulting systems have not proven to be flexible enough to meet business demands.A flexible, standardized architecture is required to better support the connection of various applications and the sharing of data. SOA is one such architecture. It unifies business processes by structuring large applications as an ad-hoc collection of smaller

modules called services. These applications can be used by different groups of people both inside and outside the company, and new applications built from mix of services from the global pool exhibit greater flexibility and uniformity. One should not, for example, have to provide redundantly the same personal information to open an online checking, savings or IRA account, and further, the interfaces one interacts with should have the same look and feel and use the same level and type of input data validation. Building all applications from the same pool of services makes achieving this goal much easier and more deployable to affiliate companies. An example of this might be interacting with a rental car company's reservation system even though you are doing so from an airline's reservation system. SOA's build applications out of software services. Services are relatively large, intrinsically unassociated units of functionality, which have no calls to each other embedded in them. They typically implement functionalities most humans would recognize as a service, such as filling out an online application for an account, viewing anService Oriented Architecture.online bank statement, or placing an online book or airline ticket order. Instead of services embedding calls to each other in their source code, protocols are defined which describe how one or more services can talk to each other. Relative to earlier attempts to promote software reuse via modularity of functions, or by use of predefined groups of functions known as classes, SOA's atomic level objects are 100 to 1,000 times larger, and are associated by an application designer or engineer using orchestration. In the process of orchestration, relatively large chunks of software functionality (services) are

associated in a non-hierarchical arrangement (in contrast to a class's hierarchies) by a software engineer, or process engineer, using a special software tool which means to record the designer's choices which the designer can manage and the software system can consume and use at run-time. Underlying and enabling all of this is metadata which is sufficient to describe not only the characteristics of these services, but also the data that drives them. XML has been used extensively in SOA to create data which is wrapped in a nearly exhaustive description container. Analogously, the services themselves are typically described byWSDL, and communications protocols by SOAP. Whether these description languages are the best possible for the job, and whether they will remain the favorites going forward, is at present an open question. What is certain is that SOA is utterly dependent on data and services that are described using some implementation of metadata which meets two criteria. The metadata must be in a form which software systems can consume to dynamically configure to maintain coherence and integrity, and in a form which system designers can understand and use to manage that metadata.Service Oriented Architecture.The goal of SOA is to allow fairly large chunks of functionality to be strung together to form ad-hoc applications which are built almost entirely from existing software services. The larger the chunks, the fewer the interface points required to implement any given set of functionality; however, very large chunks of functionality may not be granular enough to be easily reused. Each interface brings with it some amount of processing overhead, so there is a performance consideration in choosing the granularity of services. The great promise of SOA is that the marginal

cost of creating the n-th application is zero, as all of the software required already exists to satisfy the requirements of other applications. Only orchestration is required to produce a new application. The key is that there are no interactions between the chunks specified within the chunks themselves. Instead, the interaction of services (all of whom are unassociated peers) is specified by humans in a relatively ad-hoc way with the intent driven by newly emergent business requirements. Thus the need for services to be much larger units of functionality than traditional functions or classes, lest the sheer complexity of thousands of such granular objects overwhelm the application designer. The services themselves are developed using traditional languages like Java, C#, C+ +, C or COBOL. SOA services are loosely coupled, in contrast to the functions a linker binds together to form an executable, a DLL, or an assembly. SOA services also run in "safe" wrappers such as Java or .NET, which manage memory allocation and reclamation, allow ad-hoc and late binding, and provide some degree of indeterminate data typing. Increasing numbers of third-party software companies are offering software services for a fee. In the future, SOA systems may consist of such third-party services combined with others created in-house. This has the potential to spread costs over many customers, and customer uses, and promotes standardization both in and across industries. In particular, the travel industry now has a well-defined and documented set of both services and data, agency Service Oriented Architecture. software using entirely off-the-shelf software services. Other industries, such as the SOA is an architecture that relies on service-orientation as its fundamental design principle. In an SOA environment independent

services can be accessed without knowledge of their underlying platform implementation.

SOA INFRASTRUCTURE
To run and manage SOA applications, enterprises need an SOA infrastructure that is part of the SOA platform. An SOA infrastructure must support all the relevant standards and required runtime containers. A typical SOA infrastructure looks like Figure 3. The following sections discuss the infrastructure's individual pieces.

Figure 3. A typical SOA infrastructure. Click on thumbnail to view full-sized

Creation of a Service Oriented Environment

The goal for a SOA is a world wide mesh of collaborating services, which are published and available for invocation on the Service Bus. Adopting SOA is essential to deliver the business agility and IT flexibility promised by Web Services. These benefits are delivered not by just viewing service architecture from a technology perspective and the adoption of Web Service protocols, but require the creation of a Service Oriented. Environment that is based on the following key principals: Service is the important concept. Web Services are the set of protocols by which Services can be published, discovered and used in a technology neutral, standard form.

SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed.

With SOA it is critical to implement processes that ensure that there are at least two different and separate processesfor provider and consumer.

Rather than leaving developers to discover individual services and put them into context, the Business Service Bus is instead their starting point that guides them to a coherent set that has been assembled for their domain. Service Oriented Architecture .

SOA ELEMENTS

SOA

Aplication frondend

Service

Service Repository

Service Bus

Contact

Implimentation

Interface

Business Logic

Data

An SOA is based on four abstraction elements: application frontend, service, service repository, service bus. These abstractions are the key elements involved in a Service Oriented Architecture. Application frontend is the user interface through which the owner of the business process interacts with the system. Services provide business functionality that can be used by the application frontends and other services. The service contains an implementation which contains the business logic and data; a contract defining the functionality and constraints for users; and an interface that exposes the functionality.The service repositories store the service contracts of the individual services and acts as a meta base for the services. The service bus interconnects the services to the application frontends. Service Oriented Architecture

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, productivity. businesses can drive greater employee

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 assetsincluding legacy systems and applicationsmore productive and more profitable to the business without the need for custom-coded one-off integration solutions.Service Oriented Architecture -

Faster, more cost-effective application development. Standardsbased 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. Service Oriented Architecture

In architectural terms, a modern architectural design should be Service Oriented, loosely coupled, driven by events, able to support both integration and assembly, aligned with valuable life cycle support processes, and able to leverage existing infrastructure and applications. When it comes to Service Oriented Architecture, it tends to offer a variety of different advantages over more traditional methods of distributing computing. These include offering business services across several platforms; providing location independence; providing authentication as well as authorization support on ever tier; a loosely coupled approach; and dynamic search and connectivity to other services. At the same time, it allows that services do not have to be located on a particular system or network. Some of the short term benefits of Service Oriented Architecture implementation include an enhancement of reliability; a reduction of hardware acquisition costs; an acceleration of movement towards standards based servers and application consolidation; the leveraging of existing development skills; and the providing of a data bridge that connects previously incompatible forms of technology. There are also numerous long-term benefits of Service Oriented Architecture implementation. These include the creation of a self healing infrastructure that effectively reduces management costs; the proven ability to build composite applications; the access to truly real

time decision making applications; the resulting compilation of a unified taxonomy of data across an enterprise, which includes both partners and customers; and a whole lot more. From the perspective of Business Value, the advantages of Service Oriented Architecture include the ability to meet customer demands at a much faster pace than ever before; a reduction of costs previously associated with the maintenance and acquisition of key technological needs; the management of business functionality at a physically closer location to the business units; a reduction in reliance on pricey custom development; and a leverage of existing investments in the technological sector.

SOAP
Simple Object Access Protocol, or SOAP based web services have evolved as the most common SOA implementation. There are, however, non-web service implementations that exist that provide similar benefits. Service Oriented Architectures protocol independence thus means that consumers can communicate with the service in a variety of ways.

SOA DISADVANTAGES
Service Oriented Architecture Disadvantages & Applicability

Service Oriented Architecture may not always be the best architectural choice because optimal utilization of SOA requires additional development and design attempts as well as infrastructure which translates into costs escalation When it comes to applications, Web Services and Service Oriented Architecture is not recommend for the following:

Stand alone, non distributed applications that do not necessitate

application or component integration; that would include, for instance, a word processing application that does not require request and .

response

based

calls.

Short lived applications or applications that are in any way

limited in scope. This would include, for instance, an application that has been built as an interim solution that is not intended to provide full .

functionality

or

reuse

for

future

applications.

Applications in which one way asynchronous communication is

necessary, and where loose coupling is considered undesirable and unnecessary. .

Homogenous application environments, like, for instance, an

environment wherein all applications were built utilizing J2EE components. In these instances, it is not a good idea to introduce

XML over HTTP for inter-component communications rather than utilizing .

Java

remote

method

invocation.

Applications that need GUI based functionality. Like, for

instance, a map manipulation application that has lots of geographical data manipulation. Such an application is not suited for heavy data exchange that is service based. Of course, vast majority of these scenarios do not even apply to enterprise applications. Service Oriented Architecture is a network centric approach that requires complex service auditing and monitoring. Owing to the fact that service reuse and sharing tend to be the main features of Service Oriented Architecture, the quantity of service consumers will be rather high. This give raise to issues, as well as versioning and change management problems. Such problems necessitate a management infrastructure, that may become too costly for certain projects. Service Oriented Architecture is a strategic solution with a lot of meaningful benefits and tactical applications. At the same time, however, you have to pass over a threshold in order to reap the full benefits of Service Oriented Architecture. Service Oriented Architecture typically entails an analysis of both costs and benefits. The question then becomes: Will Service Oriented Architecture make the application integration process go smoother? Most of them will tell you, Yes. The Information Technology managers are currently utilizing Service Oriented Architecture to tie

together legacy, custom, and commercial applications as a means of improving mission critical Business Processes. The fact is, compared to past integration approaches, Service Oriented Architecture provides numerous benefits to a company. These include reusable Business Services that are independent of platforms, development based in standards, as well as the ability to make changes fast when it is necessary to keep with the speed of Business.

SERVICE ORIENTED ARCHITECTURE ROAD BLOCKS

It is quiet normal to feel impatient while adopting Service Oriented Architecture. It is essential not stress out by expecting an overnight success like all things, Service Oriented Architecture takes time to start functioning properly.

The truth is that a lot of companies are finding it difficult to put Service Oriented Architecture in to practice. While most Businesses nowadays possess a keen awareness of what Service Oriented Architecture is, that does not mean they always know how to go about implementing it so that it yields the best results right away. In fact, a lot of Businesses are finding that a combination of architectural, organizational, and technological issues

are bringing their Service Oriented Architecture implementation efforts to a standstill. Still, other Businesses may lack the sufficient buy-in from the company executives that they need to take Service Oriented Architecture to the next level. Below, we will explore some of the most common road blocks to Service Oriented Architecture implementation. First of all, users must keep in mind that true interoperability is still out of reach. Todays Service Oriented Architecture vision depends largely on loosely coupled interactions among heterogeneous systems. This vision is largely dependent upon standards based interoperability. After all, cross platform and cross product interoperability is the modus operandi of Web services. In order to get past this particular road block, businesses have to push their vendor suppliers to become compliant with at least a few of the most basic service standards. What is more, a lot of businesses do not have architects that contain the necessary skills to successfully implement Service Oriented Architecture. In order to be a service oriented architect, one must possess a solid grasp of enterprise wide architecture, while also being familiar with information architecture, technical architecture, data architecture, and business process architecture. Individuals with all these skills are indeed hard to find.

Another major Service Oriented Architecture road block is the fact that standards tend to be incomplete, badly conceived, or otherwise limited in some way. A lot of standards bodies have compiled elaborate maps of proposed standards that cover such components as security, integration, and management. While they continue to make progress on assembling standards on such maps, there is still a long way to go before a coherent set of interoperability standards for Service Oriented Architecture evolves.

Then there is the issue of corporate politics. For a lot of businesses, the relationship between the Information Technology side and the business side is strained if not outright hostile. A lot of times, the business side of the operation will view Information Technology as a high risk, costly enterprise that places numerous limitations on the businesss ability to execute its strategic goals. At the same time, a lot of Information Technology individuals admit that their Information Technology history is littered with failed projects, overruns in cost, and a lot of activities do nothing to aid the actual requirement.

A Service Oriented Architecture that lasts twenty two months might be eighteen months too long. It is best to be take a shorter time and get things done right. That way, you will not

have to deal with business managements attempts at blocking your progress towards Service Oriented Architecture optimization. Then, you might have to deal with the nasty three Ss that is, selfishness, stubbornness, and skepticism. While one should always remain realistic in the face of the numerous problems posed by Service Oriented Architecture, in every business there will always be an individual whose skepticism transcends all reason and wants to turn it in to an emotional issue.

A lot of people also resist new approaches, not because they really think there is anything wrong with the approach, but just because they are too lazy to learn new skills. Businesses who want to have a chance with implementing Service Oriented Architecture should identify who the road blockers in the organization are and take them aside for a long conversation about the potential benefits of Service Oriented Architecture. While these road blocks may seem problematic, they can each be overcome with a little bit of effort. In fact, none of these road blocks should prevent you from taking the first steps towards the implementation of Service Oriented Architecture. Road blocks very well might slow you down, but for the vast majority of businesses utilizing Service Oriented Architecture methods today, the advantages, by far, outweigh the disadvantages and that is a fact.

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 brickand-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 that 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.

SOFTWARE AS A SERVICE
Another concept closely related to SOA is the notion of Software as a Service(orSaaS).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 onpremise applications than with modern SaaS applications in some ways, such as licensing and architecture. Because these applications were originally built as single trent 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.

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 users 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.

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++, Perl 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..

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 general. 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.

TOOLS FOR SOA AND WEB 2.0

There are various tools available in the market for developing SOA and Web 2.0 based applications. Here are some of the Microsoft Products for developers: Microsoft BizTalk Server BizTalk Server is a server product targeted at IT Professionals and Architects that enables customers to integrate systems, employees, and trading partners. With its core architecture based on XML and the .NET Framework, BizTalk Server fully supports all the open standards upon which Web services are built. BizTalk acts as the management layer that orchestrates Web services, controlling the flow and interaction between them and aggregating individual services into a larger composite solution. Microsoft SharePoint Server By providing a simple, consistent user experience through familiar client applications, Microsoft Office SharePoint Server 2007 makes human-centric business process initiation, participation, tracking, and reporting easier and more flexible. Designed to help empower users to optimize the way people, content, and processes interact within and across organizations, Office SharePoint Server enables users to take advantage of workflows to automate and gain more visibility into common business activities like document review and approval, issue tracking, and signature collection.

Microsoft Visual Studio

Visual Studio is the professional development environment for building applications on the Windows platform. Visual Studio

enables consumption of Web services in Windows, Web, Mobile and Office-based applications. It also makes it easier for developers to publish and locate new Web services across the enterprise, and supports unit and load testing of Web services.

Microsoft Silver Light

Microsoft Silverlight is a proprietary runtime for browser-based Rich Internet Applications, providing a subset of the animation, vector graphics, and video playback capabilities of Windows Presentation Foundation. Silverlight provides a retained mode graphics system and integrates multimedia, graphics, animations and interactivity into a single runtime.

ASP.Net AJAX (Atlas)

ASP.NET AJAX, formerly code-named Atlas, is a set of extensions to ASP.NET developed by Microsoft for implementing Ajax functionality. Including both client-side and server-side components, ASP.NET AJAX allows the developer to create web applications in ASP.NET 2.0 (and to a limited extent in other environments) which can update data on the web page without a complete reload of the page. Microsoft Expression Studio Microsoft Expression Studio is a suite of design and media applications aimed at developers and designers. It consists of:

Expression Web - WYSIWYG website designer and HTML editor; Expression Blend - visual user interface builder for Windows Presentation Foundation applications; Expression Design - raster and vector graphics editor; Expression Media - digital asset and media manager; and Expression Encoder - VC-1 content professional encoder Windows Live APIs It is a suite of APIs for programmatic access of various Windows Live services, from other web sites or applications. There are currently 13 services available on Windows Live Dev for developers to help build their applications on the Windows Live Platform: Alerts, Contacts, Custom Domains, Expo, Gadgets, ID, Messenger, Spaces, Spaces Photo Control, Writer, Search, Silverlight Streaming and Virtual Earth.

QUALITY OF SERVICE
Existing mission-critical systems in enterprises address advanced requirements such as security, reliability, and transactions. As enterprises start adopting service architecture as a vehicle for developing and deploying applications, basic Web services specifications like WSDL, SOAP, and UDDI aren't going to fulfill these advanced requirements. As mentioned previously, these requirements are also known as quality of services. Numerous specifications related to QoS are being worked out in standards bodies like the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS). Sections below discuss some of the QoS artifacts and related standards.

CONCLUSION
The goal for a SOA is a world wide mesh of collaborating services, which are published and available for invocation on the Service Bus. Adopting SOA is essential to deliver the business agility and IT flexibility promised by Web Services. These benefits are delivered not by just viewing service architecture from a technology perspective and the adoption of Web Service protocols, but require the creation of a Service Oriented Environment that is based on the following key principals we have articulated in this article;

Service is the important concept. Web Services are the set of protocols by which Services can be published, discovered and used in a technology neutral, standard form. SOA is not just an architecture of services seen from a technology perspective, but the policies, practices, and frameworks by which we ensure the right services are provided and consumed. With SOA it is critical to implement processes that ensure that there are at least two different and separate processesfor provider and consumer.

Rather than leaving developers to discover individual services and put them into context, the Business Service Bus is instead their starting point that guides them to a coherent set that has been assembled for their domain.