Important aspects in using Web services

Tasks

Important aspects in using Web services

Business issues

Web services offer a common, non-proprietary level of abstraction between the client and the service provider. The key benefits here are that the client can discover and use business services that we provide, generating goodwill and business opportunities, while allowing we the flexibility to alter or replace the back-end logic transparently to the client. The importance of this varies with the type of clients targeted.

Is there business functionality that can be shared? The typical reason to use a Web service is to reuse existing infrastructure, reducing redundancy.

What business functionality will we expose to external parties? We have the option to expose as much or as little of the app as we want, ranging from single business functions exposed as services to the entire app wrapped up as a single Web service.

Does the architecture of the app allow individual business functions to be exposed as web services?

Are the clients internal or external to the enterprise?

Are there a limited set of clients?

Technical issues

Does the business logic we wish to expose have state dependency? If we intend to expose the app over the Internet, we will probably be using the HTTP communications protocol. HTTP is a stateless protocol with no guarantees regarding message delivery, order, or response. It has no knowledge of prior messages or connections. Multiple request transactions that require a state to be maintained (say for a shopping cart or similar functionality) will need to address this shortcoming. This can be done by using messaging middleware based on JMS or other protocols that provide for the maintenance of state.
The bottom line is that stateful Web services are something of which to be wary. It is best to keep Web services as simple and stateless as possible.

Are there stringent non-functional requirements? Although the basic mechanisms underlying Web services have been around for some time, some of the other newly adopted standards, such as security and transaction workflows, are still in flux with varying levels of maturity. Take care to ensure that only industry-adopted standards are used. This might influence the decisions on candidate business functions for Web service enablement.

What are we using Web services for? Web services are designed for interoperability, not performance. Use Web services in the context of providing exposure to external parties and not internally in the place of messaging between parts of the app. Web services use XML to represent data as human readable text for openness and interoperability. When compared to a binary format, it is quite inefficient, especially where it requires the use of parsers and other post-processing.

+
Search Tips | Advanced Search

Enter your search terms Submit search form

Search the Web | Search skywayradio

Is there business functionality that can be shared?	The typical reason to use a Web service is to reuse existing infrastructure, reducing redundancy.
What business functionality will we expose to external parties?	We have the option to expose as much or as little of the app as we want, ranging from single business functions exposed as services to the entire app wrapped up as a single Web service.
Does the architecture of the app allow individual business functions to be exposed as web services?
Are the clients internal or external to the enterprise?
Are there a limited set of clients?

Does the business logic we wish to expose have state dependency?	If we intend to expose the app over the Internet, we will probably be using the HTTP communications protocol. HTTP is a stateless protocol with no guarantees regarding message delivery, order, or response. It has no knowledge of prior messages or connections. Multiple request transactions that require a state to be maintained (say for a shopping cart or similar functionality) will need to address this shortcoming. This can be done by using messaging middleware based on JMS or other protocols that provide for the maintenance of state. The bottom line is that stateful Web services are something of which to be wary. It is best to keep Web services as simple and stateless as possible.
Are there stringent non-functional requirements?	Although the basic mechanisms underlying Web services have been around for some time, some of the other newly adopted standards, such as security and transaction workflows, are still in flux with varying levels of maturity. Take care to ensure that only industry-adopted standards are used. This might influence the decisions on candidate business functions for Web service enablement.
What are we using Web services for?	Web services are designed for interoperability, not performance. Use Web services in the context of providing exposure to external parties and not internally in the place of messaging between parts of the app. Web services use XML to represent data as human readable text for openness and interoperability. When compared to a binary format, it is quite inefficient, especially where it requires the use of parsers and other post-processing.