Showing posts with label ramya. Show all posts
Showing posts with label ramya. Show all posts

Wednesday, 27 April 2011


SOA versus Distributed Architecture:

Application logic:

Distributed applications place all their application logic on the server side. Here the emphasis is given on,
  1. how application logic is partitioned.
  2. where the partitioned units of processing logic should reside.
  3. how the units of processing logic should interact.

In distributed applications components are designed with different degrees of functionality and to what extent they are considered reusable by other tasks. Components residing on same server communicates API’s. In SOA web services establishes a loosely coupled environment, allowing individual services to participate.

Another difference is in how services exchange information.  Traditional components provides the methods which send and receive parameter data. Web services communicate with SOAP messages which rely on document-style messages.

Distributed internet architecture use proprietary communication protocols like DCOM and CORBA for data exchange where as SOA relies on message-based communication.

Security:

To ensure safe transportation of information and to identify user credentials encryption is assed to HTTP protocol. SOA emphasizes on placement of security logic onto messaging level. SOAP messages provide header blocks where security logic can be placed.




Thursday, 31 March 2011

Principles of SOA



Following are the principles of SOA:-

   1. Re-usability of services : Services are designed in such a way that they can be reused in the future.

   2. Stateless services : Services are designed so that their previous state  information is not stored. This feature supports the loosely coupled nature.

   3. Services share a formal contract : For services to interact they need to describe each services and the information to be exchanged.

   4. Composable services : Logic is represented at different levels, this feature facilitates reusable.

   5. Loose coupling : Services are not dependent on each other for operation.

   6. Services are autonomous : Services are not dependent on each other within the explicit boundary.

   7. Loosely coupled services : Services are designed in such a way that they interact with each other without the tight coupling and dependencies.

   8. Services abstract underlying logic : Service exposed via service contract is visible to outside world. Underlying logic other than what is specified in the contract is invisible.

SOA vs Client-Server architecture


Client-server has multiple intelligent clients which are connected to database on the server. In this environment the application logic will be placed in client software. Client work station is responsible for bulk of the processing, thus consuming most of the system resources and memory. Proprietary database connections were expensive and imposing latency. 

In contrast processing in SOA has an explicit functional boundary and related resource requirements. Most of the intelligence has been placed in the messages. There is no fixed processing ratio for SOAs.

Like client-server applications SOA also uses the visual basic and relational databases. However SOA requires that XML data representation architecture along with SOAP messaging has to be established. 

In client-server architecture the security is centralized at the server level. Operating system-level security can also be incorporated. That is the data is protected through a single point of authentication, but in SOA the security becomes significantly complex.

The major drawback of client-server architecture is the large maintenance cost. Updating the application code on each client caused high maintenance overhead.

Tuesday, 8 March 2011

EXE 7.1, 7.2

cars.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE cars SYSTEM "cars.dtd">

<cars>
    <car>
        <make> suzuki </make>
        <model> swift </model>
        <year> 2010 </year>
        <color> white </color>
        <engine>
               <no_of_cylinder> 4 </no_of_cylinder>
               <fuel_system> diesel </fuel_system>
        </engine>
                <no_of_doors> 4 </no_of_doors>
        <transmission_type> paddle shift </transmission_type>
        <accessories  radio="no"
                     air_conditioning="no"
                     power_windows="no"
                     power_steering="yes"
                     power_brakes="yes">accessories </accessories>
      </car>
       <car>
        <make> honda </make>
        <model> honda city </model>
        <year> 2008 </year>
        <color> red </color>
        <engine>
               <no_of_cylinder> 4 </no_of_cylinder>
               <fuel_system> petrol </fuel_system>
        </engine>
        <no_of_doors> 4 </no_of_doors>
        <transmission_type> tiptronic </transmission_type>
        <accessories  radio="yes"
                            air_conditioning="no"
                     power_windows="yes"
                     power_steering="no"
                     power_brakes="yes">accessories </accessories>
      </car>
 </cars>

cars.dtd

<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT cars(car+)>
<!ELEMENT car(make,model,year,color,engine,no_of_doors,transmission_type,accessories)>
<!ELEMENT make(#PCDATA)>
<!ELEMENT model(#PCDATA)>
<!ELEMENT year(#PCDATA)>
<!ELEMENT color(#PCDATA)>
<!ELEMENT engine(no_of_cylinders,fuel_systems)>
<!ELEMENT no_of_cylinders(#PCDATA)>
<!ELEMENT fuel_systems(#PCDATA)>
<!ELEMENT no_of_doors(#PCDATA)>
<!ELEMENT transmission_type(#PCDATA)>
<!ELEMENT accessories(#PCDATA)>
<!ATTLIST accessories radio CDATA #REQUIRED>
<!ATTLIST accessories air_conditioning CDATA #REQUIRED>
<!ATTLIST accessories power_windows CDATA #REQUIRED>
<!ATTLIST accessories power_steering CDATA #REQUIRED>
<!ATTLIST accessories power_brakes CDATA #REQUIRED>


Wednesday, 2 March 2011

Evolution of SOA

The main reason which led to the evolution of SOA is the difficulty faced by the programmers in writing the software. In the early days the programmers were rewriting the exiting piece of code, to over come this disadvantage modular design principles were introduced. Even though this code can be reused with this technology, it led to the maintenance and deployment problems.

To solve this problem classes and object-oriented techniques were introduced. This also led to the reuse of just code and not the functionality of the program. Component based approach is introduced to reuse the functionality. Todays software development faces the problems like distributed software,application integration, varying platform, varying protocols.

All above problems could be solved by using SOA. SOA has following components service, message, dynamic discovery and web services.








Mashup

Mashup can be defined as web page which is used to create new web services by using and combining the data or functionality of two or more services. Mashups are generally client applications, which allows the permanent access to the data of other services. 

Mashup tools d'not require programming skills rather support GUI widgets, which makes them easy to be used by the end users. Depending on the location where data is used and re-formated mashups can be classified into following types,
  • Web-based mashups, these use the user's web browsers to use and re-format data
  • Server-based mashups, these use and re-format the data on remote server, the result will be sent to the user's web browsers.
Web protocols like SOAP and REST leads to the development of mashup as they allow clients to interact with the remote services without knowing their implementation. Mashup uses screen scraping technology in order obtain the data specially from public sectors.

Mashup applications architecture has three different components
  • Content provider
  • Mashup site
  • Client's web browser
Data pollution is the major problem faced by the mashup developers as they support data to be entered by the user, it leads to inconsistent and incorrect data entry and access. Data acquisition using screen scapping may also lead to problem as it requires reverse engineering in order to interpret how the source site represent the data.

Tuesday, 1 March 2011

Web services v/s Web application

Web applications resides on the server and are meant to use by the end users. All the interactions are done through web pages, data is stored and manipulated on the servers. Web services are server-based applications which are accessed over the web, these are meant for interaction with other programs i,e they are used by the developers.

Even though the capabilities of  web applications can be accessed by the users universally, web applications d'not allow the users to add or extend their capabilities. Web services solve this problem by allowing the users to add to their capabilities using industry standard interfaces and protocols.

Using web applications companies can interact with each through capabilities, but most of the time use of web applications requires human being interacting with web applications.But web services remove this need for human interaction as the companies can interact with each other through programmatic conversations between applications. Web applications are like web sites where as web services represent the business logic.


Web Services


Real world services available on web as components which are interoperable are called "Web Services". These are used by the developers.

Web services are API's on the web, they allows applications to communicate with each other using XML a meter data and using SOAP as protocol. SOAP, WSDL and UDDI are the technologies which form the foundations of web services. SOAP provides a mechanism to exchange the information between applications, WSDL describes the web services and UDDI is the registry of information for web services.

Before web services, using software for delivering any services lead to various implications. Inorder to deliver a service to clients different  web components has to communicate with each other. Since there were no standard format for communication between different components it lead to compatibility issues. This interoperability issues are be solved by web services.

XML, eXtensible Markup Language is a text based data description language is used to represent business data. Use of  XML interoperability issues as it makes data transport independent of networking, operating system or platform.


Web services involve three categories of business: Service provider, Service broker(Registry) and Service requester. The interaction among these business components can be described by the following triad,