We have a number of heterogeneous technologies available on internet. The demand for reusable components across platforms and programming languages are high. Most of the components have the limitation that they can't share or exchange data across different platforms, they are mostly language specific or platform specific. The technologies like COM, RMI, CORBA etc. contributed best to fulfill requirements to some extent, but components result from these said technologies are mostly either language specific or platform specific.
To avoid above problem, we need to have web services. Through web services we have overcome the problem of interoperability between languages and platforms. Web services uses SOAP as transport protocol which uses a text based messaging model, i.e. XML to communicate between disparate systems.
.....................................................................................................................................................................
As Web services have become the grand vision these days, more and more people are seeking out the practicalities of implementing and using them for business benefit. It reminds me of when our Bell Labs R&D teams were prototyping cell phones in the late '70s. That vision was grand too, but at times it was hard to see the practical day-to-day applications when a receiver weighed 200 pounds and literally had to be bolted in the trunk of the car.
Still, we knew that the development we were doing had the ability to fundamentally change the way people communicate. Now Web services have the ability to fundamentally change the way applications communicate.
Web services have resulted from the convergence of three important events. The first was the emergence of the Internet as a cost-effective and widespread infrastructure. The second was the adoption of XML as a standard. And the third was the emergence of a set of common Web services standards--namely, the Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL)--which have been accepted by major platform vendors in place of proprietary standards such as CORBA and DCOM.
Simply put, Web services make application functionality available over the Internet in a standardized, programmatic way. Applications that couldn't be accessed except by following rigid proprietary protocols can now talk to one another over the Internet, regardless of their native language, platform or internal protocols.
Web services utilize existing IT infrastructures and allow companies to wrap legacy applications in a standardized, consistent and reusable format so every investment can be leveraged. They provide a low-cost way to connect internal applications and collaborate among business partners.
Few people would argue that real-time application-to-application integration is an ideal goal that has proved difficult to fully attain. The ability to have applications--internal or external--share data automatically with no human intervention creates cost savings, productivity increases, error reductions and competitive advantages that are easy to understand and easy to quantify. There's been no lack of interest or demand for a solution, but until now the cure has been harder to live with than the disease.
In the real world, applications are written in different languages using different platforms, heavily customized for specific uses within different corporations and existing behind layers of firewalls designed for the express purpose of prohibiting them from talking to applications on the outside. Typically, real-time integration has required complex and expensive solutions as well as private networks to ensure secure transport and management capabilities. The hallways to most CIOs' offices are littered with application integration solutions that came up short in delivering the grand vision of dynamic, real-time application integration.
The keys have always been the industry-wide adoption of a set of standards that would allow applications to communicate, regardless of their native language, and a cost-effective, ubiquitous network for transport. Today, with the Internet and the new standards, we're closer than we've ever been to achieving real-time application integration--and that accounts for the fever pitch surrounding Web services.
This is big news, but as with any grand vision, its value is ultimately determined by how effectively it can be applied to gain business benefit. The fact that the Internet is ubiquitous, easily accessible and decentralized encourages its use, but it also discourages businesses from using it as a cornerstone of their IT infrastructures. The current Internet and Web services standards allow applications developed in any environment to interoperate with one another, but they don't address fundamental issues such as security, reliability, performance and management.
All applications wrapped in SOAP or WSDL can communicate programmatically with one another, but they lack the key functionality that enables enterprise-class deployment. While the Web services picture painted by the press today extols universal directories and companies publishing Web services for discovery by heretofore unknown parties, the reality is that most companies--at least for now--will use Web services with prequalified audiences such as trading partners.
In order for Web services to deliver on their promise of real-time application integration using the Internet, those practical issues must be addressed, creating the need for a third component in a Web services implementation strategy. The industry term now taking hold is "Web services network." A Web services network makes the deployment of Web services practical by providing the infrastructure that requesters and providers of Web services need to conduct business.
A Web services network provides connection provisioning, including the automation of business processes. It also provides value-added services such as bandwidth metering, billing, authentication of users, nonrepudiation of messages and the gathering of analytics. Finally, a Web services network provides an optimized SOAP communications channel for guaranteed delivery, once-and-only-once delivery, message encryption and compression.
Some Web services networks utilize an EDI VAN-like model where messages are routed through a central hub. The Flamenco network, for example, combines centralized management with peer-to-peer connection capabilities. Users download a small proxy to each end point or to a gateway server. That proxy communicates with the centralized site to both route messages and report analytics. At run-time, however, Web services communicate peer-to-peer, enhancing scalability and eliminating a central point of failure.
To use an analogy from my telephony days, a Web services network serves as a "jack" allowing you to plug your Web services into the Internet while providing an infrastructure that gives Web services a safe, reliable channel and needed management capabilities with no custom coding.
Grand visions are wily creatures, but in the end they always live or die based on whether they can bring about positive change in the way people live their lives or do business. The truth about Web services is: while they won't fix everything, if combined with a sound implementation strategy, the proper infrastructure and the right tools, they can go a long way toward making real-time application integration a reality.
That's not so much a grand vision as an optimistic but realistic prediction for the future. And if you don't believe me, just think about that 6 1/2 ounce cell phone attached to your belt.
To avoid above problem, we need to have web services. Through web services we have overcome the problem of interoperability between languages and platforms. Web services uses SOAP as transport protocol which uses a text based messaging model, i.e. XML to communicate between disparate systems.
Deploying a Web Service
Deploying the .Net Web Services is as simple as any ASP.NET application. Similar to ASP.NET applications, you need to copy or upload the .ASMX file and the .DISCO files to the appropriate directories, and that's it......................................................................................................................................................................
As Web services have become the grand vision these days, more and more people are seeking out the practicalities of implementing and using them for business benefit. It reminds me of when our Bell Labs R&D teams were prototyping cell phones in the late '70s. That vision was grand too, but at times it was hard to see the practical day-to-day applications when a receiver weighed 200 pounds and literally had to be bolted in the trunk of the car.
Still, we knew that the development we were doing had the ability to fundamentally change the way people communicate. Now Web services have the ability to fundamentally change the way applications communicate.
Web services have resulted from the convergence of three important events. The first was the emergence of the Internet as a cost-effective and widespread infrastructure. The second was the adoption of XML as a standard. And the third was the emergence of a set of common Web services standards--namely, the Simple Object Access Protocol (SOAP) and Web Services Description Language (WSDL)--which have been accepted by major platform vendors in place of proprietary standards such as CORBA and DCOM.
Simply put, Web services make application functionality available over the Internet in a standardized, programmatic way. Applications that couldn't be accessed except by following rigid proprietary protocols can now talk to one another over the Internet, regardless of their native language, platform or internal protocols.
Web services utilize existing IT infrastructures and allow companies to wrap legacy applications in a standardized, consistent and reusable format so every investment can be leveraged. They provide a low-cost way to connect internal applications and collaborate among business partners.
Few people would argue that real-time application-to-application integration is an ideal goal that has proved difficult to fully attain. The ability to have applications--internal or external--share data automatically with no human intervention creates cost savings, productivity increases, error reductions and competitive advantages that are easy to understand and easy to quantify. There's been no lack of interest or demand for a solution, but until now the cure has been harder to live with than the disease.
In the real world, applications are written in different languages using different platforms, heavily customized for specific uses within different corporations and existing behind layers of firewalls designed for the express purpose of prohibiting them from talking to applications on the outside. Typically, real-time integration has required complex and expensive solutions as well as private networks to ensure secure transport and management capabilities. The hallways to most CIOs' offices are littered with application integration solutions that came up short in delivering the grand vision of dynamic, real-time application integration.
The keys have always been the industry-wide adoption of a set of standards that would allow applications to communicate, regardless of their native language, and a cost-effective, ubiquitous network for transport. Today, with the Internet and the new standards, we're closer than we've ever been to achieving real-time application integration--and that accounts for the fever pitch surrounding Web services.
This is big news, but as with any grand vision, its value is ultimately determined by how effectively it can be applied to gain business benefit. The fact that the Internet is ubiquitous, easily accessible and decentralized encourages its use, but it also discourages businesses from using it as a cornerstone of their IT infrastructures. The current Internet and Web services standards allow applications developed in any environment to interoperate with one another, but they don't address fundamental issues such as security, reliability, performance and management.
All applications wrapped in SOAP or WSDL can communicate programmatically with one another, but they lack the key functionality that enables enterprise-class deployment. While the Web services picture painted by the press today extols universal directories and companies publishing Web services for discovery by heretofore unknown parties, the reality is that most companies--at least for now--will use Web services with prequalified audiences such as trading partners.
In order for Web services to deliver on their promise of real-time application integration using the Internet, those practical issues must be addressed, creating the need for a third component in a Web services implementation strategy. The industry term now taking hold is "Web services network." A Web services network makes the deployment of Web services practical by providing the infrastructure that requesters and providers of Web services need to conduct business.
A Web services network provides connection provisioning, including the automation of business processes. It also provides value-added services such as bandwidth metering, billing, authentication of users, nonrepudiation of messages and the gathering of analytics. Finally, a Web services network provides an optimized SOAP communications channel for guaranteed delivery, once-and-only-once delivery, message encryption and compression.
Some Web services networks utilize an EDI VAN-like model where messages are routed through a central hub. The Flamenco network, for example, combines centralized management with peer-to-peer connection capabilities. Users download a small proxy to each end point or to a gateway server. That proxy communicates with the centralized site to both route messages and report analytics. At run-time, however, Web services communicate peer-to-peer, enhancing scalability and eliminating a central point of failure.
To use an analogy from my telephony days, a Web services network serves as a "jack" allowing you to plug your Web services into the Internet while providing an infrastructure that gives Web services a safe, reliable channel and needed management capabilities with no custom coding.
Grand visions are wily creatures, but in the end they always live or die based on whether they can bring about positive change in the way people live their lives or do business. The truth about Web services is: while they won't fix everything, if combined with a sound implementation strategy, the proper infrastructure and the right tools, they can go a long way toward making real-time application integration a reality.
That's not so much a grand vision as an optimistic but realistic prediction for the future. And if you don't believe me, just think about that 6 1/2 ounce cell phone attached to your belt.
Posts
0 comments:
Post a Comment