SOA vs Hybrid Web service architecture

Web services of hybrid architecture having an integration layer present using for synchronous communication with the help of SOAP (complaint integration channels), actually these web services encapsulating components of different services or application.

Intigration channels are basically utilized in integration architectures to provide communication with other applications, third party utilities or partners.

This architecture is simply a distributed internet architecture that uses web services but can not take it as a service oriented architecture. SOA defines design requirements for web services as well a support them with concern of messaging models weather synchronous or asynchronous.

In SOA every service having vast scope that is clearly specified and that can accomodate a large number of requestors, current as well as future.

Only SOA architecture having tangible characteristics and variable capabilities and made for for collectively participate in number of different bussiness processes.

SOA vs Past Architecture

SOA vs Client Server

• Mainframes provided the first “client-server” computing with synchronous and asynchronous communication

• CICS – conversational and non-conversational mode

• 1980s – two-tier client server with fat clients, GUI, database. Dominated the 90s

Client Server Characteristics

• Bulk of the application logic resides with the client

• Monolithic executable on client

• Business rules were maintained in stored procedures and triggers on the database

• This abstracted a set of business logic from the client and simplified data access programming

• Overall, the client runs the show

SOA Characteristics

• Presentation layer can be any software capable of exchanging SOAP messages

• SOA principles dictate partitioning logic into autonomous units

• SOA units of logic are solution agnostic

Application Processing

• 80% - workstation, 20% server

• Even so, the database is often the bottleneck

• Two-tier solutions usually mean each client has a database connection

• Connections are often synchronous and persistent

• 80% processing on client may mean client programs run exclusively

• Processing with SOA is highly distributed

• Each service has explicit functional boundaries and resource requirements

• SOA allows many options for deploying services

• Enterprise solutions consist of multiple servers with sets of Web services and supporting middleware

• With SOA there is no fixed processing ratio

• Supports synchronous and asynchronous communication between service and requestors

• Messages are loaded with intelligence to support message-level context management

• Smart messaging promotes stateless and autonomous services

Technology

• The technology set for client-server applications included 4GLs like VB and PowerBuilder, RDBMSs

• The SOA technology set has expanded to include Web technologies (HTML, CSS, HTTP, etc)

• SOA requires the use of XML data representation architecture along with a SOAP messaging framework

Security

• Centralized at the Server level

• Databases manage user accounts and groups

• Also controlled within the client executable

• Security for SOA is much more complex

• Security complexity is directly related to the degree of security measures required

• Multiple technologies are required, many in WS-Security framework

Administration

• Significant maintenance costs associated with client-server

• Each client housed application code

• Each update required redistribution

• Client stations were subject to environment-specific problems

• Increased server-side demands on databases

• SOA solutions are not immune to client-side maintenance challenges

• Distributed back-end supports scalability, but new admin demands are introduced

• Management of server resources and service interfaces may require new admin tools and even a private registry

• Commitment to services and their maintenance may require cultural change in an organization

SOA vs Traditional Distributed Internet Architecture

• Muliple client-server architectures have appeared

• Client-server DB connections have been replaced with Remote Procedure Call connections (RPC) using CORBA or DCOM

• Middleware application servers and transaction monitors require significant attention

• Multi-tiered client-server environments began incorporating internet technology in 90s.

• The browser shifted 100% of application logic to the server

• Distributed Internet architecture introduced the Web server as a new physical tier

• HTTP replaced RPC protocols

• Distributed Internet application put all the application logic on the server side

• Even client-side scripts are downloaded from the server

• Entire solution is centralized

• Emphasis is on:

• How application logic is partitioned

• Where partitioned units reside

• How units of logic should interact

• Difference lies in the principles used to determine the three primary design considerations

• Traditional systems create components that reside on one or more application servers

• Components have varying degrees of functional granularity

• Components on the same server communicate via proprietary APIs.

• RPC protocols are used across servers via proxy stubs

• Actual references to other physical components can be embedded in programming code (tight coupling)

• SOAs also rely on components

• Services encapsulate components

• Services expose specific sets of functionality

• Functionality can originate from legacy systems or other sources

• Functionality is wrapped in services

• Functionality is exposed via open, standardized interface, irrespective of technology providing the solution

• Services exchange information via SOAP messages. SOAP supports RPC-style and document-style messages

• Most applications rely on document-style

• Messages are structured to be self-sufficient

• Messages contain meta information, processing instructions, policy rules

• SOA fosters reuse on a deep level by promoting solution-agnostic services

Application Processing

• Distributed Internet architecture promotes the use of proprietary communication protocols (DCOM, CORBA)

• SOA relies on message-based communication

• Messages use serialization, transmission, de-serialization of SOAP messages containing XML payloads

• RPC communication is faster than SOAP and SOAP processing overhead is a significant design issue

• Messaging framework supports a wide range message exchange patterns

• Asynchronous patterns encouraged

• Support for stateless services is supported by context management options (WS-Coordination, WS-BPEL

Technology

• Distributed Internet architecture now includes XML data representation

• XML and Web services are optional for distributed Internet architecture but not for SOA

Security

• When application logic crosses physical boundaries, security becomes more difficult

• Traditional security architectures incorporate delegation and impersonation as well as encryption

• SOAs depart from this model by relying heavily on WS-Security to provide security logic on the messaging level

• SOAP messages carry headers where security logic can be stored

Administration

• Maintaining component-base applications involves:

– keeping track of individual components

– tracing local and remote communication problems

– Monitoring server resource demands

– Standard database administrative tasks

• Distributed Internet Architecture introduces the Web server and its physical environment

• SOA requires additional runtime administration:

– Problems with messaging frameworks

– Additional administration of a private or public registry of services

Common Principles of SOA

8 common principles of SOA are as follows :

1.Reusability

Reuse is very important within service-orientation, so that it becomes a core part of that service and design processes. Non-proprietary service technology has provided

the opportunity to maximize the reuse potential of multi-purpose logic on desire level.Services are designed to potential and frequent reuse when available and required.

2.Formal Contract

Services express their purpose and capabilities via a service contract. To define service and terms of information exchange formal contract is the best way. Contract design including that services functionality, how data types and data models are defined, and how policies lies confidential. There is a constant focus on ensuring that service contracts are optimized, granular, and standardized to ensure that the outcome should be consistent and reliable.

3. Loose Coupling

Coupling defines a connection or relationship between two things. A measure of coupling is comparable to a level of dependency.

The principle of Loose Coupling promotes the independent design and evolution of a logic for a service and implementation . There are many types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract.

Figure : Coupling represents a core design consideration that spans both intra and inter-service design.

4. Abstract underlying logic

Abstraction ties into many aspects of service-orientation. This principle emphasizes the need to hide as much of the underlying details of a service as possible.

Various forms of meta data come into the picture when we are going to assess appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort for run the service.

5. Composability

The ability to compose services is a main requirement for achieving some of the most fundamental goals of SOA.

Composibility allows logic that will help to create new service at different levels of granuality and that will be capable of participating as effective composition members. The principle of Service Composability addresses this requirement by ensuring that a variety of considerations are taken into account.

6. Service are Autonomous

The logic of this principle fully based on explicit boundaries and the principle of this service supports the extent to which other design principles can be effectively realized in real world production environments that increase a service’s reliability and behavioral predictability. And all the services within this explicit boundaries are control by them and these are independent from other service.

7. Stateless

Every service should be able to remain loosely coupled and there is no need to manage state information .Service should be design such that its statelessness maximized.Services are therefore ideally designed to remain stateful only when required.

8.Discoverable

Services should always be discoverable and also should be such that it is easily understood by humans and also service requesters so that the logic can be used.

Evolution of SOA

First of all we should know actually what is Software Oriented Architecture "SOA" according to OASIS :

A paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

Or we can say that, "SOA" i.e. service-oriented architecture is a collection of services those communicate with each other. One or more than one web services can involve in communication to coordinate some activities or services.

If we look back in 90s, the first service-oriented architecture for many people was with the use DCOM or Object Request Brokers (ORBs), ORB is a part of middleware s/w that allows programmers to make program calls from one computer to another via a network in distributed computing and ORBs can handle the transformation of process data structures to and from the byte sequence while processing, which is transmitted over the network. This is called marshalling or serialization. But they had some problems, like in retrieve data required by others, for this he has to develop new S/Ws, to overcome this problem, the services has been improvised. Then XML language came under existence in SOA thing to communicate between different entities.

SOA requires loose coupling of services with OS, and other , to separates functions into different units, or services, that can easily accessible by developers for reuse and production of applications.

• Basically SOA is for building business applications.
• It is a black-box component architecture.
• Components of SOA is loosely coupled.
• SOA components are arranged in a manner that link together through processes to deliver a well defined level of service.

MASH-UP !!!

First of all, i would like to explain the term MASHUP means mixing or remix, here it is a combination of tools or we can say data from other sources or web pages. Mash-ups collect data from multiple web pages and collect required information into one web application. In simple words , A web mash-up is a web application that collect information from one or more sources and provide information in a unique layout . There are number of ways for mash-ups to use in required manner and mash-ups are like endless.

To create a mash-up, many different sources are required and usually that sources have an XML based module for make compatibility to provide data for mash-ups. This allows the mash-up to use these XML outputs as inputs. Once the required data got collected and combined , the mash-up will generate its own output after manipulate them, which displays a combination of the original data from other sources.

In Web development, a mashup is a Web page or application that uses and combines data, and to create new services it uses functions and way of presentation from other sources. The main characteristics of the mashups are combination, visualization, and aggregation.

In the past years, number of Web applications have published application programming interfaces that enable developers to integrate data and functions easily , in place of building them by themselves. We can say that Mashups played an active role for evolution of social software and Web 2.0. Generally mashup do not require programming skills and support services .

There are many types of mashups, such as

• Business mashups
• Consumer mashups
• Data mashups

Mashups are a field of interactive Web applications that based upon content retrieved from external data sources to create new and innovative services. This blog explores what it means to be a mashup, the different classes of mashups and their applications already constructed today.

Difference Between Web Applications and Web Services

According to definition Web services are that provide a standard means of inter-operating between different software applications, running on a variety of platforms and/or frameworks Web services are all about making different types of applications compatible to inter operate with other.

We can say that web services are mechanism to access remote objects or functions by using HTTP and XML in combine called SOAP(simple object access protocol). Soap has some

methods to access programmable application by some logic and methods.

Web services use soap protocol while web application use http protocol.

Clients are only have to deal with send and get for xml request using SOAP and web applications are accessible by clients.

Web services can be implemented at any client or server place to make data secure, so that when w

eb services are being use on server side,

even programmer also can not find that data.

For an example, a Web Application as defined in Java is a formal way of packaging Servlets where a "Web Service" is a single service which usually communicates with other components through SOAP messaging. Thus a "Web Services" is much closer to an Java Beans than to a whole "web application".

Web services are well defined functions having standard interfaces that just expose a behavior where web applications are browser based applications that also include an interface and functions that are bound into a single application that is run from the web. A web service, however is also an application whose purpose is to serve a service to clients or users.

A web application is like a web site. You can log onto to it, browse, do things etc and consumers are people.

Web Services

Web Services are those services that gives a path to communicate or we can say avail and provide facilities from which we can communicate with service provider or between application etc in required manner, that allows to communicate data and can convert applications into Web-applications, basically these are application components that can communicate using some protocols.

Web services are self describing and can provide services without using browser or html, whole data and respective applications are runs on server and dealing with client or software or application in terms of request .Web services are discovered using UDDI (Universal Description, Discovery and Integration).

Web services can be used by other applications, operating system, over web applications for avail or provide services or we can say facilities according to pre-configured manner as required where XML is the basis for Web services and the basic Web services platform is XML + HTTP. Where XML provides a language which can be used between different platforms and programming languages and deals with messages and functions.

There are three main elements of web services are :

• UDDI (Universal Description, Discovery and Integration)
• WSDL (Web Services Description Language)
• SOAP (Simple Object Access Protocol)