Ans-SOA provides several significant benefits for the distributed enterprise system.Some of the most notable benefits includes:interoperability,efficiency and standardization
Interoperability:-
Interoperability is the ability of software on different systems to communicate by sharing data and functionality.SOA/Web Services are much more about web and
Internet scale computing.Most companies will have numerous business partners throughout life of the company.Instead of writing a new addition to your application everytime you gain a new partner, you can write one interface using web Service technology like SOAP.So now your partner can dynamically find the services using UDDI and bind to them using SOAP.You can also extend interoperabilty of your system by implementing the webservices within your intranet.With the addition of Web Services to your intranet system and to your extranet, you can reduce the cost integration , increase communication and increase your customer base.
Efficiency:-SOA enable you to reuse your existing applications.Instead of creating totally new applications, you can create them using various combinations of service exposed by your existing applications.Developers can be more efficient because they can focus on learning industry standard technology.They willnot have to spend a lot of time learning every new technologies that arises.For a manager this means this means a reduction in the cost of buying new software and having to hire new developers with new skill sets.This approch will allow developers to meet changing business requirements and reduce the length of development cycles for projects.Overall, SOA provides for an increase in efficiency by allowing applications to be reused,decreasing the learning curve of developers, speeding up the total development process.
Standardization:-For something to be true starndard, it must be accepted and used by majority of the industry.One vendor or small group of vendors must not controll the evolution of technology or specification.Most if not all the industry leaders are involved in the development of Web Service Specifications.Almost all businesses now-a-days use the internet or world wide web in one form or another.The underlying protocol for WWW is ofcourse HTTP.The foundation of Web Services is built upon HTTP and XML.Although does not mandate a particular implementation framework , iteroperabilty is important and SOAP is one of the few protocol that all good SOA implementations can agree on.
Tuesday, December 21, 2010
Q.What is basics of SOA?Or What are the three roles of SOA?
Traditional distributed computing environments have been tightly coupled in that they don't want a changing environment as well.For instance if an application is interacting with another application how do they handle the data types or data encoding if data types in one system changes? How are incompatible data types handled?
The service Oriented Architechture consists of three roles : requestor, provider and broker.
Service Provider:-A service provider allows the access to the services, create a description of a service and publish it to the service broker.
Service Requestor:-A service requestor is responsible for discovering a service by searching through the service description given by the service broker.A service requestor is also responsible for binding to services provided by the service provider.
Service Broker:-A service broker hosts a registry of service descriptions.It is responsible for linking a requestor to the service provider.
The service Oriented Architechture consists of three roles : requestor, provider and broker.
Service Provider:-A service provider allows the access to the services, create a description of a service and publish it to the service broker.
Service Requestor:-A service requestor is responsible for discovering a service by searching through the service description given by the service broker.A service requestor is also responsible for binding to services provided by the service provider.
Service Broker:-A service broker hosts a registry of service descriptions.It is responsible for linking a requestor to the service provider.
Monday, December 20, 2010
SOA Frequently Asked Questions
Q.What is Service Oriented Architecture (SOA)?
A.SOA is a standards-based design approach to creating an integrated IT infrastructure capable of rapidly responding to changing business needs. SOA provides the principles and guidance to transform a company’s existing array of heterogeneous, distributed, complex and inflexible IT resources into integrated, simplified and highly flexible resources that can be changed and composed to more directly support business goals.
Q.What business value does SOA provide?
A.SOA enables businesses to realize greater agility in their business practices, delivering value across both application and IT infrastructure layers. From an application perspective, SOA enables the development of a new generation of dynamic or composite applications. These applications enable end-users to access information and processes across functional boundaries, and to consume them in a number of convenient ways, including through Web, rich client, and mobile presentation layers. From an infrastructure perspective, SOA enables IT to simplify application and system integration, to recombine and reuse application functionality, and to organize development work into a unified and consistent design framework. The combined business value of the SOA approach helps to lower IT costs; provides better, more rapidly accessible business information; and enables the organization to identify and respond to workflow problems more efficiently.
Q.What business problems does SOA solve?
A.SOA enables businesses to develop a new generation of dynamic applications that address a number of top-level business concerns that are central to growth and competitiveness. SOA solutions promote:
•
Stronger connections with customers and suppliers. By making available dynamic applications and business services to external customers and suppliers, not only is richer collaboration possible, but customer and partner satisfaction is increased. SOA unlocks critical supply and demand chain processes—such as outsourcing of specific business tasks—from the constraints of underlying IT architectures, thereby enabling better alignment of processes with organizational strategy.
•
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, and gain the flexibility to access that information in the form and presentation factor (Web, rich client, mobile device) that meets their needs.
•
Greater employee productivity. By providing streamlined access to systems and information and enabling business process improvement, businesses can drive greater employee productivity. Employees can focus their energies on addressing the important, value-added processes and on collaborative, semi-structured activities, rather than having to conform to the limitations and restrictions of the underlying IT systems.
Q.Will SOA enable alignment of business and IT?
A.SOA by itself is not sufficient to guarantee alignment of business and IT. In fact, many organizations that have attempted to roll out SOA infrastructure through a top-down approach have found that that by the time the infrastructure was delivered, it was out of sync with the needs of the business. In contrast, those customers that have driven successful alignment have started with a clear understanding of their business vision, have well-defined business initiatives and outcomes, and have chosen to incrementally deliver those “slices” of their SOA infrastructure that deliver upon these objectives. Microsoft has long advocated this approach—what we call our “real world” approach to leveraging service oriented architectures. This real world approach is focused on rapid time-to-value, and on delivering business results through iterative, incremental steps that are more closely aligned with changing business conditions. This helps enable a much tighter degree of alignment between business and IT.
Q.Is SOA a product?
A.No. SOA is not a product, but an architecture approach and set of patterns for implementing agile, loosely coupled dynamic applications. A reflection of its commitment to developing the standards, guidance, tools and technologies needed for developing cross-platform integration solutions, Microsoft has been using service orientation across its products since 1999, when the Web services model was announced and a wave of innovation began that fundamentally changed the application architecture landscape. Beginning with version 1.0 of the .NET Framework, the Microsoft investments in tools, together with platform support for Web services, have helped make Service Orientation mainstream and practical.Working with other vendors such as IBM and BEA, we invested in authoring a set of specifications referred to collectively as the WS-* architecture. Shortly thereafter, in order to promote interoperability across platforms, operating systems and programming languages, Microsoft worked with IBM to develop the Web Services Interoperability Organization (WS-I). Since it was created, WS-I has grown to roughly 150 member companies and has created Web services that address areas such as interoperability, security and the reliability of messaging.
Q.Will implementing an SOA solution require a complete overhaul of existing technologies and business processes?
A.No. The most effective approach to SOA is to build on existing investments, including legacy applications, and to take an incremental approach to integrating across diverse systems to provide specific business benefits. And because the underlying applications are accessed through an interface, the IT assets are insulated from direct change.
Q.Isn’t implementing an SOA solution a costly and complex proposition?
A.While some SOA-based solutions require a multiplicity of products to implement, increasing cost and complexity, Microsoft solutions are greatly simplified since core service orientation capabilities are built right into the Windows platform as part of the .NET framework. These core capabilities are complemented with an integrated set of development and management tools, as well as server-based solutions for composing and integrating dynamic, composite applications.
Q.Is SOA technology only for large Fortune 1000 enterprises?
A.No. The Microsoft “real world” SOA approach has been successfully adopted by organizations with very modest IT resources, since it can readily scale down to fit within their existing IT capabilities. At the same time, the Microsoft approach to SOA scales to the largest of global enterprises, supporting mission-critical processes for hundreds of thousands of employees world wide.
Q.What is the Microsoft SOA solution approach?
A.Microsoft SOA solutions help organizations access existing IT resources, assemble them into larger business processes, and make the outputs available to users in order to run their organization more effectively. This “real world” approach lets organizations begin with a focused understanding of the business problem and realize rapid success.
From a more technical standpoint, the Microsoft approach can be summarized as a three-step approach: expose, compose and consume.
1.In the expose phase, existing IT resources (such as legacy systems and line of business applications) are made available as services which can be communicated with through standardized messaging formats. The most common suite of implementation technologies is the standards-based Web services. For existing technology assets that cannot natively speak Web service protocols, interoperability is attained through the use of adapters. As the developer moves forward in deliberations about which services to expose, such decisions must be driven by clearly defined and prioritized business needs.
2.Once individual services are exposed, they must be pulled together or composed into larger business processes or workflows. The goal of the compose phase is to enable greater business flexibility and agility by allowing processes to be added or changed without being constrained by the underlying IT systems and applications.
3.In the final step of constructing an SOA solution, the dynamic (or composite) applications that consume the underlying services and processes are developed. These applications—based on Web technologies (such as portals or AJAX), rich clients, Office business applications, or mobile devices—are what drive the productivity of the end-user.It is important to recognize that all three steps are essential parts of every incremental SOA project. Without all three elements—including the delivery of the dynamic application—the business will not realize any return on the investment.
Q.How do I get started with an SOA solution?
A.The goal of the SOA approach is to deliver a business solution that enables business agility, not to build a SOA. Reuse of services is often stated as a goal of SOA, and while it is true that reuse can be a good by-product of SOA, it is not the end goal itself. The first step in any SOA implementation, therefore, is to identify key business integration challenges or priorities. Development efforts, implemented along principles of SOA, are chosen such that they: 1) best meet the stated business needs, 2) offer the fastest time to value, and 3) best support long-term growth of the business.
Q.What are common SOA pitfalls?
A.One of the most common pitfalls is to view SOA as an end, rather than a means to an end. Developers who focus on building an SOA solution rather than solving a specific business problem are more likely to create complex, unmanageable, and unnecessary interconnections between IT resources.
Another common pitfall is to try to solve multiple problems at once, rather than solving small pieces of the problem. Taking a top-down approach—starting with major organization-wide infrastructure investments—often fails either to show results in a relevant timeframe or to offer a compelling return on investment.
A.SOA is a standards-based design approach to creating an integrated IT infrastructure capable of rapidly responding to changing business needs. SOA provides the principles and guidance to transform a company’s existing array of heterogeneous, distributed, complex and inflexible IT resources into integrated, simplified and highly flexible resources that can be changed and composed to more directly support business goals.
Q.What business value does SOA provide?
A.SOA enables businesses to realize greater agility in their business practices, delivering value across both application and IT infrastructure layers. From an application perspective, SOA enables the development of a new generation of dynamic or composite applications. These applications enable end-users to access information and processes across functional boundaries, and to consume them in a number of convenient ways, including through Web, rich client, and mobile presentation layers. From an infrastructure perspective, SOA enables IT to simplify application and system integration, to recombine and reuse application functionality, and to organize development work into a unified and consistent design framework. The combined business value of the SOA approach helps to lower IT costs; provides better, more rapidly accessible business information; and enables the organization to identify and respond to workflow problems more efficiently.
Q.What business problems does SOA solve?
A.SOA enables businesses to develop a new generation of dynamic applications that address a number of top-level business concerns that are central to growth and competitiveness. SOA solutions promote:
•
Stronger connections with customers and suppliers. By making available dynamic applications and business services to external customers and suppliers, not only is richer collaboration possible, but customer and partner satisfaction is increased. SOA unlocks critical supply and demand chain processes—such as outsourcing of specific business tasks—from the constraints of underlying IT architectures, thereby enabling better alignment of processes with organizational strategy.
•
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, and gain the flexibility to access that information in the form and presentation factor (Web, rich client, mobile device) that meets their needs.
•
Greater employee productivity. By providing streamlined access to systems and information and enabling business process improvement, businesses can drive greater employee productivity. Employees can focus their energies on addressing the important, value-added processes and on collaborative, semi-structured activities, rather than having to conform to the limitations and restrictions of the underlying IT systems.
Q.Will SOA enable alignment of business and IT?
A.SOA by itself is not sufficient to guarantee alignment of business and IT. In fact, many organizations that have attempted to roll out SOA infrastructure through a top-down approach have found that that by the time the infrastructure was delivered, it was out of sync with the needs of the business. In contrast, those customers that have driven successful alignment have started with a clear understanding of their business vision, have well-defined business initiatives and outcomes, and have chosen to incrementally deliver those “slices” of their SOA infrastructure that deliver upon these objectives. Microsoft has long advocated this approach—what we call our “real world” approach to leveraging service oriented architectures. This real world approach is focused on rapid time-to-value, and on delivering business results through iterative, incremental steps that are more closely aligned with changing business conditions. This helps enable a much tighter degree of alignment between business and IT.
Q.Is SOA a product?
A.No. SOA is not a product, but an architecture approach and set of patterns for implementing agile, loosely coupled dynamic applications. A reflection of its commitment to developing the standards, guidance, tools and technologies needed for developing cross-platform integration solutions, Microsoft has been using service orientation across its products since 1999, when the Web services model was announced and a wave of innovation began that fundamentally changed the application architecture landscape. Beginning with version 1.0 of the .NET Framework, the Microsoft investments in tools, together with platform support for Web services, have helped make Service Orientation mainstream and practical.Working with other vendors such as IBM and BEA, we invested in authoring a set of specifications referred to collectively as the WS-* architecture. Shortly thereafter, in order to promote interoperability across platforms, operating systems and programming languages, Microsoft worked with IBM to develop the Web Services Interoperability Organization (WS-I). Since it was created, WS-I has grown to roughly 150 member companies and has created Web services that address areas such as interoperability, security and the reliability of messaging.
Q.Will implementing an SOA solution require a complete overhaul of existing technologies and business processes?
A.No. The most effective approach to SOA is to build on existing investments, including legacy applications, and to take an incremental approach to integrating across diverse systems to provide specific business benefits. And because the underlying applications are accessed through an interface, the IT assets are insulated from direct change.
Q.Isn’t implementing an SOA solution a costly and complex proposition?
A.While some SOA-based solutions require a multiplicity of products to implement, increasing cost and complexity, Microsoft solutions are greatly simplified since core service orientation capabilities are built right into the Windows platform as part of the .NET framework. These core capabilities are complemented with an integrated set of development and management tools, as well as server-based solutions for composing and integrating dynamic, composite applications.
Q.Is SOA technology only for large Fortune 1000 enterprises?
A.No. The Microsoft “real world” SOA approach has been successfully adopted by organizations with very modest IT resources, since it can readily scale down to fit within their existing IT capabilities. At the same time, the Microsoft approach to SOA scales to the largest of global enterprises, supporting mission-critical processes for hundreds of thousands of employees world wide.
Q.What is the Microsoft SOA solution approach?
A.Microsoft SOA solutions help organizations access existing IT resources, assemble them into larger business processes, and make the outputs available to users in order to run their organization more effectively. This “real world” approach lets organizations begin with a focused understanding of the business problem and realize rapid success.
From a more technical standpoint, the Microsoft approach can be summarized as a three-step approach: expose, compose and consume.
1.In the expose phase, existing IT resources (such as legacy systems and line of business applications) are made available as services which can be communicated with through standardized messaging formats. The most common suite of implementation technologies is the standards-based Web services. For existing technology assets that cannot natively speak Web service protocols, interoperability is attained through the use of adapters. As the developer moves forward in deliberations about which services to expose, such decisions must be driven by clearly defined and prioritized business needs.
2.Once individual services are exposed, they must be pulled together or composed into larger business processes or workflows. The goal of the compose phase is to enable greater business flexibility and agility by allowing processes to be added or changed without being constrained by the underlying IT systems and applications.
3.In the final step of constructing an SOA solution, the dynamic (or composite) applications that consume the underlying services and processes are developed. These applications—based on Web technologies (such as portals or AJAX), rich clients, Office business applications, or mobile devices—are what drive the productivity of the end-user.It is important to recognize that all three steps are essential parts of every incremental SOA project. Without all three elements—including the delivery of the dynamic application—the business will not realize any return on the investment.
Q.How do I get started with an SOA solution?
A.The goal of the SOA approach is to deliver a business solution that enables business agility, not to build a SOA. Reuse of services is often stated as a goal of SOA, and while it is true that reuse can be a good by-product of SOA, it is not the end goal itself. The first step in any SOA implementation, therefore, is to identify key business integration challenges or priorities. Development efforts, implemented along principles of SOA, are chosen such that they: 1) best meet the stated business needs, 2) offer the fastest time to value, and 3) best support long-term growth of the business.
Q.What are common SOA pitfalls?
A.One of the most common pitfalls is to view SOA as an end, rather than a means to an end. Developers who focus on building an SOA solution rather than solving a specific business problem are more likely to create complex, unmanageable, and unnecessary interconnections between IT resources.
Another common pitfall is to try to solve multiple problems at once, rather than solving small pieces of the problem. Taking a top-down approach—starting with major organization-wide infrastructure investments—often fails either to show results in a relevant timeframe or to offer a compelling return on investment.
Friday, December 17, 2010
Web Service Interview Questions and Answers
What is a Web service?
Many people and companies have debated the exact definition of Web services. At a minimum, however, a Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system.
XML is used to encode all communications to a Web service. For example, a client invokes a Web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, Web services are not tied to any one operating system or programming language--Java can talk with Perl; Windows applications can talk with Unix applications.
Beyond this basic definition, a Web service may also have two additional (and desirable) properties:
First, a Web service can have a public interface, defined in a common XML grammar. The interface describes all the methods available to clients and specifies the signature for each method. Currently, interface definition is accomplished via the Web Service Description Language (WSDL). (See FAQ number 7.)
Second, if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface. The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration. (See FAQ number 8.)
Web services currently run a wide gamut from news syndication and stock-market data to weather reports and package-tracking systems. For a quick look at the range of Web services currently available, check out the XMethods directory of Web services.
Many people and companies have debated the exact definition of Web services. At a minimum, however, a Web service is any piece of software that makes itself available over the Internet and uses a standardized XML messaging system.
XML is used to encode all communications to a Web service. For example, a client invokes a Web service by sending an XML message, then waits for a corresponding XML response. Because all communication is in XML, Web services are not tied to any one operating system or programming language--Java can talk with Perl; Windows applications can talk with Unix applications.
Beyond this basic definition, a Web service may also have two additional (and desirable) properties:
First, a Web service can have a public interface, defined in a common XML grammar. The interface describes all the methods available to clients and specifies the signature for each method. Currently, interface definition is accomplished via the Web Service Description Language (WSDL). (See FAQ number 7.)
Second, if you create a Web service, there should be some relatively simple mechanism for you to publish this fact. Likewise, there should be some simple mechanism for interested parties to locate the service and locate its public interface. The most prominent directory of Web services is currently available via UDDI, or Universal Description, Discovery, and Integration. (See FAQ number 8.)
Web services currently run a wide gamut from news syndication and stock-market data to weather reports and package-tracking systems. For a quick look at the range of Web services currently available, check out the XMethods directory of Web services.
What is new about Web services?
People have been using Remote Procedure Calls (RPC) for some time now, and they long ago discovered how to send such calls over HTTP.
So, what is really new about Web services? The answer is XML.
XML lies at the core of Web services, and provides a common language for describing Remote Procedure Calls, Web services, and Web service directories.
Prior to XML, one could share data among different applications, but XML makes this so much easier to do. In the same vein, one can share services and code without Web services, but XML makes it easier to do these as well.
By standardizing on XML, different applications can more easily talk to one another, and this makes software a whole lot more interesting.
People have been using Remote Procedure Calls (RPC) for some time now, and they long ago discovered how to send such calls over HTTP.
So, what is really new about Web services? The answer is XML.
XML lies at the core of Web services, and provides a common language for describing Remote Procedure Calls, Web services, and Web service directories.
Prior to XML, one could share data among different applications, but XML makes this so much easier to do. In the same vein, one can share services and code without Web services, but XML makes it easier to do these as well.
By standardizing on XML, different applications can more easily talk to one another, and this makes software a whole lot more interesting.
I keep reading about Web services, but I have never actually seen one. Can you show me a real Web service in action?
If you want a more intuitive feel for Web services, try out the IBM Web Services Browser, available on the IBM Alphaworks site. The browser provides a series of Web services demonstrations. Behind the scenes, it ties together SOAP, WSDL, and UDDI to provide a simple plug-and-play interface for finding and invoking Web services. For example, you can find a stock-quote service, a traffic-report service, and a weather service. Each service is independent, and you can stack services like building blocks. You can, therefore, create a single page that displays multiple services--where the end result looks like a stripped-down version of my.yahoo or my.excite.
If you want a more intuitive feel for Web services, try out the IBM Web Services Browser, available on the IBM Alphaworks site. The browser provides a series of Web services demonstrations. Behind the scenes, it ties together SOAP, WSDL, and UDDI to provide a simple plug-and-play interface for finding and invoking Web services. For example, you can find a stock-quote service, a traffic-report service, and a weather service. Each service is independent, and you can stack services like building blocks. You can, therefore, create a single page that displays multiple services--where the end result looks like a stripped-down version of my.yahoo or my.excite.
What is the Web service protocol stack?
The Web service protocol stack is an evolving set of protocols used to define, discover, and implement Web services. The core protocol stack consists of four layers:
Service Transport: This layer is responsible for transporting messages between applications. Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).
XML Messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP.
Service Description: This layer is responsible for describing the public interface to a specific Web service. Currently, service description is handled via the WSDL.
Service Discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI.
Beyond the essentials of XML-RPC, SOAP, WSDL, and UDDI, the Web service protocol stack includes a whole zoo of newer, evolving protocols. These include WSFL (Web Services Flow Language), SOAP-DSIG (SOAP Security Extensions: Digital Signature), and USML (UDDI Search Markup Language). For an overview of these protocols, check out Pavel Kulchenko's article, Web Services Acronyms, Demystified, on XML.com.
Fortunately, you do not need to understand the full protocol stack to get started with Web services. Assuming you already know the basics of HTTP, it is best to start at the XML Messaging layer and work your way up.
Service Transport: This layer is responsible for transporting messages between applications. Currently, this includes HTTP, SMTP, FTP, and newer protocols, such as Blocks Extensible Exchange Protocol (BEEP).
XML Messaging: This layer is responsible for encoding messages in a common XML format so that messages can be understood at either end. Currently, this includes XML-RPC and SOAP.
Service Description: This layer is responsible for describing the public interface to a specific Web service. Currently, service description is handled via the WSDL.
Service Discovery: This layer is responsible for centralizing services into a common registry, and providing easy publish/find functionality. Currently, service discovery is handled via the UDDI.
Beyond the essentials of XML-RPC, SOAP, WSDL, and UDDI, the Web service protocol stack includes a whole zoo of newer, evolving protocols. These include WSFL (Web Services Flow Language), SOAP-DSIG (SOAP Security Extensions: Digital Signature), and USML (UDDI Search Markup Language). For an overview of these protocols, check out Pavel Kulchenko's article, Web Services Acronyms, Demystified, on XML.com.
Fortunately, you do not need to understand the full protocol stack to get started with Web services. Assuming you already know the basics of HTTP, it is best to start at the XML Messaging layer and work your way up.
What is XML-RPC?
XML-RPC is a protocol that uses XML messages to perform Remote Procedure Calls. Requests are encoded in XML and sent via HTTP POST; XML responses are embedded in the body of the HTTP response.
More succinctly, XML-RPC = HTTP + XML + Remote Procedure Calls.
Because XML-RPC is platform independent, diverse applications can communicate with one another. For example, a Java client can speak XML-RPC to a Perl server.
To get a quick sense of XML-RPC, here is a sample XML-RPC request to a weather service (with the HTTP Headers omitted):
weather.getWeather
10016
The request consists of a simple element, which specifies the method name (getWeather) and any method parameters (zip code).
Here is a sample XML-RPC response from the weather service:
65
The response consists of a single element, which specifies the return value (the current temperature). In this case, the return value is specified as an integer.
In many ways, XML-RPC is much simpler than SOAP, and therefore represents the easiest way to get started with Web services.
The official XML-RPC specification is available at XML-RPC.com. Dozens of XML-RPC implementations are available in Perl, Python, Java, and Ruby. See the XML-RPC home page for a complete list of implementations.
XML-RPC is a protocol that uses XML messages to perform Remote Procedure Calls. Requests are encoded in XML and sent via HTTP POST; XML responses are embedded in the body of the HTTP response.
More succinctly, XML-RPC = HTTP + XML + Remote Procedure Calls.
Because XML-RPC is platform independent, diverse applications can communicate with one another. For example, a Java client can speak XML-RPC to a Perl server.
To get a quick sense of XML-RPC, here is a sample XML-RPC request to a weather service (with the HTTP Headers omitted):
The request consists of a simple element, which specifies the method name (getWeather) and any method parameters (zip code).
Here is a sample XML-RPC response from the weather service:
The response consists of a single element, which specifies the return value (the current temperature). In this case, the return value is specified as an integer.
In many ways, XML-RPC is much simpler than SOAP, and therefore represents the easiest way to get started with Web services.
The official XML-RPC specification is available at XML-RPC.com. Dozens of XML-RPC implementations are available in Perl, Python, Java, and Ruby. See the XML-RPC home page for a complete list of implementations.
What is SOAP?
SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the main focus of SOAP is Remote Procedure Calls (RPC) transported via HTTP. Like XML-RPC, SOAP is platform independent, and therefore enables diverse applications to communicate with one another.
To get a quick sense of SOAP, here is a sample SOAP request to a weather service (with the HTTP Headers omitted):
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle=" http://www.w3.org/2001/09/soap-encoding
10016
As you can see, the request is slightly more complicated than XML-RPC and makes use of both XML namespaces and XML Schemas. Much like XML-RPC, however, the body of the request specifies both a method name (getWeather), and a list of parameters (zipcode).
Here is a sample SOAP response from the weather service:
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">
65
The response indicates a single integer return value (the current temperature).
The World Wide Web Consortium (W3C) is in the process of creating a SOAP standard. The latest working draft is designated as SOAP 1.2, and the specification is now broken into two parts. Part 1 describes the SOAP messaging framework and envelope specification. Part 2 describes the SOAP encoding rules, the SOAP-RPC convention, and HTTP binding details.
SOAP is an XML-based protocol for exchanging information between computers. Although SOAP can be used in a variety of messaging systems and can be delivered via a variety of transport protocols, the main focus of SOAP is Remote Procedure Calls (RPC) transported via HTTP. Like XML-RPC, SOAP is platform independent, and therefore enables diverse applications to communicate with one another.
To get a quick sense of SOAP, here is a sample SOAP request to a weather service (with the HTTP Headers omitted):
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle=" http://www.w3.org/2001/09/soap-encoding
As you can see, the request is slightly more complicated than XML-RPC and makes use of both XML namespaces and XML Schemas. Much like XML-RPC, however, the body of the request specifies both a method name (getWeather), and a list of parameters (zipcode).
Here is a sample SOAP response from the weather service:
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">
The response indicates a single integer return value (the current temperature).
The World Wide Web Consortium (W3C) is in the process of creating a SOAP standard. The latest working draft is designated as SOAP 1.2, and the specification is now broken into two parts. Part 1 describes the SOAP messaging framework and envelope specification. Part 2 describes the SOAP encoding rules, the SOAP-RPC convention, and HTTP binding details.
What is WSDL?
The Web Services Description Language (WSDL) currently represents the service description layer within the Web service protocol stack.
In a nutshell, WSDL is an XML grammar for specifying a public interface for a Web service. This public interface can include the following:
Information on all publicly available functions.
Data type information for all XML messages.
Binding information about the specific transport protocol to be used.
Address information for locating the specified service.
WSDL is not necessarily tied to a specific XML messaging system, but it does include built-in extensions for describing SOAP services.
Below is a sample WSDL file. This file describes the public interface for the weather service used in the SOAP example above. Obviously, there are many details to understanding the example. For now, just consider two points.
First, the elements specify the individual XML messages that are transferred between computers. In this case, we have a getWeatherRequest and a getWeatherResponse. Second, the element specifies that the service is available via SOAP and is available at a specific URL.
targetNamespace="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
transport="http://schemas.xmlsoap.org/soap/http"/>
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:weatherservice"
use="encoded"/>
WSDL File for Weather Service
location="http://localhost:8080/soap/servlet/rpcrouter"/>
Using WSDL, a client can locate a Web service, and invoke any of the publicly available functions. With WSDL-aware tools, this process can be entirely automated, enabling applications to easily integrate new services with little or no manual code. For example, check out the GLUE platform from the Mind Electric.
WSDL has been submitted to the W3C, but it currently has no official status within the W3C. See this W3C page for the latest draft.
In a nutshell, WSDL is an XML grammar for specifying a public interface for a Web service. This public interface can include the following:
Information on all publicly available functions.
Data type information for all XML messages.
Binding information about the specific transport protocol to be used.
Address information for locating the specified service.
WSDL is not necessarily tied to a specific XML messaging system, but it does include built-in extensions for describing SOAP services.
Below is a sample WSDL file. This file describes the public interface for the weather service used in the SOAP example above. Obviously, there are many details to understanding the example. For now, just consider two points.
First, the
targetNamespace="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
transport="http://schemas.xmlsoap.org/soap/http"/>
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:weatherservice"
use="encoded"/>
location="http://localhost:8080/soap/servlet/rpcrouter"/>
Using WSDL, a client can locate a Web service, and invoke any of the publicly available functions. With WSDL-aware tools, this process can be entirely automated, enabling applications to easily integrate new services with little or no manual code. For example, check out the GLUE platform from the Mind Electric.
WSDL has been submitted to the W3C, but it currently has no official status within the W3C. See this W3C page for the latest draft.
What is UDDI?
UDDI (Universal Description, Discovery, and Integration) currently represents the discovery layer within the Web services protocol stack.
UDDI was originally created by Microsoft, IBM, and Ariba, and represents a technical specification for publishing and finding businesses and Web services.
At its core, UDDI consists of two parts.
First, UDDI is a technical specification for building a distributed directory of businesses and Web services. Data is stored within a specific XML format, and the UDDI specification includes API details for searching existing data and publishing new data.
Second, the UDDI Business Registry is a fully operational implementation of the UDDI specification. Launched in May 2001 by Microsoft and IBM, the UDDI registry now enables anyone to search existing UDDI data. It also enables any company to register themselves and their services.
The data captured within UDDI is divided into three main categories:
White Pages: This includes general information about a specific company. For example, business name, business description, and address.
Yellow Pages: This includes general classification data for either the company or the service offered. For example, this data may include industry, product, or geographic codes based on standard taxonomies.
Green Pages: This includes technical information about a Web service. Generally, this includes a pointer to an external specification, and an address for invoking the Web service.
You can view the Microsoft UDDI site, or the IBM UDDI site. The complete UDDI specification is available at uddi.org.
Beta versions of UDDI Version 2 are available at:
Hewlett Packard
IBM
Microsoft
SAP
UDDI (Universal Description, Discovery, and Integration) currently represents the discovery layer within the Web services protocol stack.
UDDI was originally created by Microsoft, IBM, and Ariba, and represents a technical specification for publishing and finding businesses and Web services.
At its core, UDDI consists of two parts.
First, UDDI is a technical specification for building a distributed directory of businesses and Web services. Data is stored within a specific XML format, and the UDDI specification includes API details for searching existing data and publishing new data.
Second, the UDDI Business Registry is a fully operational implementation of the UDDI specification. Launched in May 2001 by Microsoft and IBM, the UDDI registry now enables anyone to search existing UDDI data. It also enables any company to register themselves and their services.
The data captured within UDDI is divided into three main categories:
White Pages: This includes general information about a specific company. For example, business name, business description, and address.
Yellow Pages: This includes general classification data for either the company or the service offered. For example, this data may include industry, product, or geographic codes based on standard taxonomies.
Green Pages: This includes technical information about a Web service. Generally, this includes a pointer to an external specification, and an address for invoking the Web service.
You can view the Microsoft UDDI site, or the IBM UDDI site. The complete UDDI specification is available at uddi.org.
Beta versions of UDDI Version 2 are available at:
Hewlett Packard
IBM
Microsoft
SAP
How do I get started with Web Services?
The easiest way to get started with Web services is to learn XML-RPC. Check out the XML-RPC specification or read my book, Web Services Essentials. O'Reilly has also recently released a book on Programming Web Services with XML-RPC by Simon St.Laurent, Joe Johnston, and Edd Dumbill.
Once you have learned the basics of XML-RPC, move onto SOAP, WSDL, and UDDI. These topics are also covered in Web Services Essentials. For a comprehensive treatment of SOAP, check out O'Reilly's Programming Web Services with SOAP, by Doug Tidwell, James Snell, and Pavel Kulchenko.
The easiest way to get started with Web services is to learn XML-RPC. Check out the XML-RPC specification or read my book, Web Services Essentials. O'Reilly has also recently released a book on Programming Web Services with XML-RPC by Simon St.Laurent, Joe Johnston, and Edd Dumbill.
Once you have learned the basics of XML-RPC, move onto SOAP, WSDL, and UDDI. These topics are also covered in Web Services Essentials. For a comprehensive treatment of SOAP, check out O'Reilly's Programming Web Services with SOAP, by Doug Tidwell, James Snell, and Pavel Kulchenko.
Does the W3C support any Web service standards?
The World Wide Web Consortium (W3C) is actively pursuing standardization of Web service protocols. In September 2000, the W3C established an XML Protocol Activity. The goal of the group is to establish a formal standard for SOAP. A draft version of SOAP 1.2 is currently under review, and progressing through the official W3C recommendation process.
On January 25, 2002, the W3C also announced the formation of a Web Service Activity. This new activity will include the current SOAP work as well as two new groups. The first new group is the Web Services Description Working Group, which will take up work on WSDL. The second new group is the Web Services Architecture Working Group, which will attempt to create a cohesive framework for Web service protocols.
The World Wide Web Consortium (W3C) is actively pursuing standardization of Web service protocols. In September 2000, the W3C established an XML Protocol Activity. The goal of the group is to establish a formal standard for SOAP. A draft version of SOAP 1.2 is currently under review, and progressing through the official W3C recommendation process.
On January 25, 2002, the W3C also announced the formation of a Web Service Activity. This new activity will include the current SOAP work as well as two new groups. The first new group is the Web Services Description Working Group, which will take up work on WSDL. The second new group is the Web Services Architecture Working Group, which will attempt to create a cohesive framework for Web service protocols.
What is Web Service?
The term webservices describe a standardized way of integrating web-based applications using the XML,SOAP,WSDL and UDDI open standards over an internet protocol backbone.
XML is used to tag the data,SOAP is used to transfer the data,WSDL is used for describing the services available and UDDI is used for listing what services are available.
Web Services used primarily as a means for business to communicate with each other and with clients.Web Services allows organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall.
Unlike traditional client/server model,such as webServer/web page System, Web services don't provide the user with a GUI.Web Services instead share business,data and processes through a programatic interface acrros a network.The applications interface, not the users.Developers then can add the web services to the GUI(such as an webpage or an excecutable program) to offer specific functionality to users.
Web services allow different applications from different sources to communicate with each other without time-consuming custom coding and because all communication is in XML,web services are not tied to any operating system or progamming langauage.For eg Java can talk with Perl, windows application can talk with Unix applications.
Web services don't require the use of browser or HTML.
Web Services are sometimes called application services.
XML is used to tag the data,SOAP is used to transfer the data,WSDL is used for describing the services available and UDDI is used for listing what services are available.
Web Services used primarily as a means for business to communicate with each other and with clients.Web Services allows organizations to communicate data without intimate knowledge of each other's IT systems behind the firewall.
Unlike traditional client/server model,such as webServer/web page System, Web services don't provide the user with a GUI.Web Services instead share business,data and processes through a programatic interface acrros a network.The applications interface, not the users.Developers then can add the web services to the GUI(such as an webpage or an excecutable program) to offer specific functionality to users.
Web services allow different applications from different sources to communicate with each other without time-consuming custom coding and because all communication is in XML,web services are not tied to any operating system or progamming langauage.For eg Java can talk with Perl, windows application can talk with Unix applications.
Web services don't require the use of browser or HTML.
Web Services are sometimes called application services.
Wednesday, December 15, 2010
Advantages and disadvantages of adopting SOA in an Organization
The advantages of a service oriented architecture
Service Oriented Architecture, commonly referred to as SOA, is a leading architectural practice followed by organizations to reduce total cost of ownership, ease of maintenance in software development. Many organizations today are looking up to SOA as an architectural solution to provide a robust computing platform to connect to legacy systems. In this architectural paradigm there is focus on exposing software as a service rather than an application. With the following distinct advantages:In SOA an organization clearly demarcates its business process in terms of a web service. For example, a bank may expose a web service called openaccountNumber() to the outside world for opening an account. This web service can be used anywhere across the globe for opening bank accounts. You need not write separate applications for the same business function.
*Ease of Maintenance*
Organizations can maintain the web services at a lower cost as compared to the separate applications.
*Reduced Development Cost *
With this as a architectural standard and many IDE’s in marketplace it is easier and cost effective to develop web services on SOA pattern
*Maintainability*
SOA promises to be great in terms of maintainability of code as web services can be put in repository and located according to geographical and business purposes.
*Total Cost of Ownership*
Umbrella term used to denote the costs involved in maintaining supporting, and owning, governing applications throughout the organizations.
*Interoperability*
SOA architectural solutions promises organizations to interoperate the various businesses exposed as webservices that will allow the organizations to interoperate as in a webservice to getCustomerdeatils() can be used by other departments, say Home loan line of credit, can issue a request to the customer details. Similarly the Credit online system may use the same web service to get the customer details .
*Standards*
SOA brings in standards to the organization. A web service built on SOA rigidly follows W3C standards for data interchange and exposing the wsdl to the outside world.
SOA has also standardized the way web services operate and in terms of data exchange and interaction with backend systems. SOA has been incorporated by many banks as standard for developing web applications across the world, SOA advantages come with the disadvantages of a large cost involved in transitioning legacy systems to new SOA based solutions as lot of research is done on the previous system data formats and business significance before migrating on to SOA based solution.SOA based solutions promise a much better landscape in terms of all the benefits mentioned above and has proven be boon to large scale organizations .
Define SOA
SOA is the abbreviation of Service Oriented Architecture. SOA is used for developing software applications that use services available in a network such as web.It promotes loose coupling between the components so that they can be reused.Applications in soa are built based on services available.A service is an implementation of a well-defined business functionality and such services can be consumed by clients in different applications or business processes.At one moment, an application could act as a client by calling an external service, while moments later, it may act as a service-provider when called by another application to perform a task.
SOA allows for the reuse of existing assets where new services can be generated from the existinf IT-infrastructure systems.In other words, it enables business to leverage existing investments by allowing them to reuse the existing applications and promises interoperability between hetrogeneous applications and technologies.SOA provides a level of flexiblity in the sense that:
1.services are software componets with well-defined interfaces that are implementation-independent.An important aspect of SOA is the separation of the services interface(the what) from it's implementation(the how).Such services are consumed by the clients that are not concerned with how these services will execute their requests.
2.Services are self contained(perform predetermined task) and loosely coupled(for independence).
3.Services can be dynamically discovered.
4.Composite services can be built from aggregates of other services.
SOA uses the find-bind-execute paradigm.In this paradigm the service provider register their service in a public registery.This registery is used by the consumers to find certain criteria.If the registery has such a service it provides, it provides the consumer with the contract and end point address for that service.
SOA based applications are distributed-multitier applications that have presentation , business logic and persistence layers.Services are the building blocks of SOA applications.While any functionality can be made into a service, the challenge is to define service interface that is at the right level of abstraction.Services should provide coarse-grained functionality.
SOA allows for the reuse of existing assets where new services can be generated from the existinf IT-infrastructure systems.In other words, it enables business to leverage existing investments by allowing them to reuse the existing applications and promises interoperability between hetrogeneous applications and technologies.SOA provides a level of flexiblity in the sense that:
1.services are software componets with well-defined interfaces that are implementation-independent.An important aspect of SOA is the separation of the services interface(the what) from it's implementation(the how).Such services are consumed by the clients that are not concerned with how these services will execute their requests.
2.Services are self contained(perform predetermined task) and loosely coupled(for independence).
3.Services can be dynamically discovered.
4.Composite services can be built from aggregates of other services.
SOA uses the find-bind-execute paradigm.In this paradigm the service provider register their service in a public registery.This registery is used by the consumers to find certain criteria.If the registery has such a service it provides, it provides the consumer with the contract and end point address for that service.
SOA based applications are distributed-multitier applications that have presentation , business logic and persistence layers.Services are the building blocks of SOA applications.While any functionality can be made into a service, the challenge is to define service interface that is at the right level of abstraction.Services should provide coarse-grained functionality.
Tuesday, December 14, 2010
SOA Interview Questions for Architects
2) Advantages and disadvantages of adopting SOA in an Organization?advantages-and-disadvantages
3) Is SOA best suit for every business? (Ex: for a simple system where no services are reusable it’s not a good choice, also real time systems may be tough due to performance reasons.)
4) Are web services must in SOA? Any alternatives?
5) Can set of web services in your project mean you are doing a SOA project? Justify.
6) Need for Registry and repositories in SOA?
7) Need for SOA Governance?
8) Is ESB a must for SOA?
9) Difference b/w ESB and EAI (tough one).
10) Difference b/w ESB and BPEL Engine.
11) Need for Orchestration?
12) Difference b/w BPEL engine and ESB?
13) Importance of Granularity of a Service?
14) What are composite services? How they are different from business processes?
15) What are the important features of an ESB?
16) Difference between BPEL and BPMN?
17) Role of business analyst in SOA projects?
18) Describe your approach for starting an SOA project in an Organization?
19) Possible Security issues in SOA projects? Can achieve an End to End Security?
20) How can we handle Transactions in SOA?
Monday, December 13, 2010
Thursday, December 9, 2010
soa deployment plan
http://blogs.oracle.com/soa_how_to/soa11/
http://technology.amis.nl/blog/2371/oracle-soa-suite-further-build-and-deployment-automation-for-enterprise-service-bus-components
http://biemond.blogspot.com/2009/04/using-weblogic-deployment-plan-to.html
http://technology.amis.nl/blog/2371/oracle-soa-suite-further-build-and-deployment-automation-for-enterprise-service-bus-components
http://biemond.blogspot.com/2009/04/using-weblogic-deployment-plan-to.html
Subscribe to:
Posts (Atom)