There has been a significant increase in the implementation of open source software and Java development platforms. The specific revision supported by a given server may vary, but competitive forces in the market inevitably mandate supporting the latest industry standard.
An efficient use of web services requires understanding the flow of control, what is being controlled, and coding the XML control and binding files. Many applications implement third-tier business logic as standard JEE components. Exposing these components as SOAP web services provides uniform accessibility and component integration. One technique is to have applications based on
compositions of services discovered and marshaled dynamically at runtime; this is just-in-time integration of services. When the flow is understood by application developers, this facilitates the process of component integration. There is a diverse technology associated with web services.
A provider creates, assembles, and deploys a web service using the designated programming language, middleware, and platform. The provider defines the web service in WSDL: Web Services
A WSDL document describes a web service. The provider optionally registers the service in UDDI: Universal Description, Discovery, and Integration registries which developers use to publish web services and enable software to search for services offered by others.
A prospective user finds the service by searching a UDDI registry. The userís application binds to the web service and invokes the
serviceís operations using SOAP: Simple Object Access Protocol.
JEE and Web Services Standards
The major reasons for the increased utilization and support of JEE and web services standards include:
|Web Services and
SOA Standards Compliance
|A fundamental tenet of SOA and network-based applications is the leverage and reuse of code and business logic across the enterprise. This is achieved through the utilization of the base protocols and industry standards.
|Common Architectural Model
||As an organizationís scale and needs change overtime, it will be necessary to migrate and redeploy applications on different physical hardware. Sharing a common architecture, facilitates the migration of web server applications.
||A standardized application architecture provides an efficient and cost effective utilization of information technology staff: application development and maintenance.
||Web server and application performance are fundamental to user satisfaction and return on investment. Performance design provides for efficient future growth with minimal new capital investment.
||As an organization's information technology requirements evolve, application servers will need to scale without service disruptions or substantial redeployment efforts. Software scalability combined with savvy hardware choices can reduce energy, floor space, and operational management demands.
|Application Infrastructure Virtualization
||In order to realize a return on investment, an organization will need its application environment to have a comprehensive level of virtualization: server, storage, networking, and application. The dynamic allocation of application infrastructure resources will result in a better utilization of existing hardware and application servers and reduced energy requirements.
Design Framework and Service Orientation Views
Systems are developed based upon a design framework. A service model is the separation between the interface and the implementation. The invoker of a service needs only to understand the interface; this allows the implementation to evolve over time without
interruption of the service to the client. The benefits of service orientation derive from the abstraction of the delivery. The same interface can be offered in multiple implementations without affecting the application.
A service orientation views everything as a service provider. The service model is fractal in that a service can call any other service to implement its functionality. This includes both
services which provide business functionality and nonfunctional services for logging, monitoring, data transformation, and so on. The newly formed process is a service itself; it exposes a new aggregated capability. Systems are developed to contain services;
the services are programs which interact using well-defined message exchanges.
Web Service Interface and Management
URIs are a main part of a web service interface. Once services have been published and used by internal and external clients, there will be difficulties in making changes.
The URI should be concise, easy to remember, and uniquely identify the target resource. The URL only should include nouns; it will need to identify the resource, not action.
HTTP Request Method implies action:
In any non-trivial web-service, the number of methods can grow to a relatively large number. The first part of the URI should identify the module and all URIs for that module will be within the subordinate hierarchy.
1- GET implies search.
2- POST implies create.
|3- PUT implies update.
|4- DELETE implies removal of resource.
Versioning will need to be built into the services. Once services are published, it will be difficult to introduce versioning. If a new release of services is not backward compatible, then it probably will be necessary to maintain two versions during the period of client upgrade. A client will need to pass version information in the 'Accept' request header that the server can use. In the event, that the version
passed is unsupported, the server will need to respond with HTTP Response Code 415 and an accompanying message.
Services should be granular. Services typically will map to top level domain objects. In a well designed domain model, operations on top level domain objects will map to business use cases.
Exposing each persistent object using a web service is not a recommended practice. It exposes internal application design, adds redundant and unused services and makes service difficult to understand and use.
Request/Response Mime Types
Service should use standard HTTP headers to consume and produce different mime types. New content types then can be supported without changing service interface. Content-type header of the request determine the type of the content service
to expected and accept header of the request will determine the type of response body that services produce. The typical content-type and accept headers will be: application/xml and application/json.
Client-specific Examples and Exercises
Client-specific operational requirements and performance objectives are taught:
||A single, interactive user experience.
||Communications layer that is common to the architecture.
||Composes and arranges applications and services.
||Federates, merges, and moves the enterprise data.
|Build to Integrate
||Builds and deploys new applications and services.
Best Practices and Guidelines
Services should cache only successful GET requests. Caching at multiple layers is needed to have good performance. Persistent layer caching is important. Method level caching can be added. Services also should include a cache-control header in the response, this will allow the client to cache the response.
For cacheable responses, server should set HTTP 'Vary' header to indicate that the response is cacheable based on the URL plus the returned Content-Type: Vary as follows: Vary: Content-Type.
Logging should be based on one log per request pattern. In a multi-user environment, it will be useful in problem resolution to have one log per request. All logs for the request can be accumulated in request thread and printed once at the end of the request.
1. Service should apply HTTP Status Codes for communicating success and failure that can be used by program clients. It might be necessary to add Custom HTTP Status Codes for specific use case.
However, this should be kept to a minimum. Contextual information about an error should be included in reason phrase of HTTP response or custom HTTP response headers.
2. Service requests involving user entered data with POST and PUT should include a list of user error messages in the response body
to correct the error condition. Adding a new custom HTTP Status code (450) will communicate the user data validation error to the client.
The document should include for each service method:
|1. HTTP Method
|3. Accept and Content-Type HTTP Request Headers.
||4. All possible HTTP Response codes.
|5. Any custom Headers
||6. Sample Response
|7. Sample request body for PUT, POST requests.
8. Schema with xsd files for each request and response.