Web services architecture

The Web services architecture includes three roles:

• Service provider
  Web service providers create components, then publish them to a repository. On the WebSphere Application Server - Express platform, these components include:
  • Java beans
  • DB2 Universal Database stored procedures
  • Server-side scripts that implement the Bean Scripting Framework (BSF)

  Web service providers can also unpublish components (remove them from the repository) when they are no longer needed.

• Service broker
  Web service brokers categorize Web services as they are published, and search for them as service requests are received. Web brokers are roughly analagous to Internet search engines, except that they locate components instead of Web pages. The Universal Description, Discovery, and Integration (UDDI) specification defines a way to publish and discover information about Web services.

• Service requester
  Web service requesters look up, or locate and invoke components as services. They act as the client for published Web services.

This diagram illustrates how client and server roles can interact to provide Web services.

Refer to the following topics for more information about Web services architecture:

• Characteristics of the Web service architecture
• Properties of a service-oriented architecture
• Plan to use Web services

Characteristics of the Web service architecture

The presented SOA employs a loose coupling between the participants, which provides greater flexibility in the following ways:

• A client is not coupled to a server, but to a service. Therefore, the integration of the server takes place outside the scope of the client application programs.
• Old and new functional blocks, or applications and systems, are encapsulated into components that work as services.
• Functional components and their interfaces are separate, allowing new interfaces to be plugged in more easily.
• Within complex applications, the control of business processes can be isolated. A business rule engine can be incorporated to control the workflow of a defined business process. Depending on the state of the workflow, the engine calls the respective services.
• Services can be incorporated dynamically during run time.
• Bindings are specified using configuration files and can be easily adapted to new needs.

Properties of a service-oriented architecture

The service-oriented architecture offers the following properties:

• Web services are self-contained.

  On the client side, no additional software is required. A programming language with extensible markup language (XML) and Hyper Text Transport Protocol (HTTP) client support is enough to get you started. On the server side, a Web server and a SOAP server are required. It is possible to Web services-enable an existing application without writing a single line of code.

• Web services are self-describing.

  Neither the client nor the server knows or cares about anything besides the format and content of request and response messages (loosely coupled application integration). The definition of the message format travels with the message; no external metadata repositories or code generation tool are required.

• Web services can be published, located, and invoked across the Internet.

  This technology uses established lightweight Internet standards such as HTTP. It leverages the existing infrastructure. Some additional standards that are required to do so include SOAP, WSDL, and UDDI.

• Web services are language-independent and interoperable.

  Client and server can be implemented in different environments. Existing code does not have to be changed in order to be Web service enabled.

• Web services are inherently open and standard-based.

  XML and HTTP are the major technical foundation for Web services. A large part of the Web service technology has been built using open-source projects. Therefore, vendor independence and interoperability are realistic goals this time.

• Web services are dynamic.

  Dynamic e-business can become reality using Web services because, with UDDI and WSDL, the Web service description and discovery can be automated.

• Web services are composable.

  Simple Web services can be aggregated to more complex ones, either using workflow techniques or by calling lower-layer Web services from a Web service implementation. Web services can be chained together to perform higher-level business functions. This shortens development time and enables best-of-breed implementations.

• Web services build on proven mature technology.

  There are a lot of commonalties, as well as a few fundamental differences to other distributed computing frameworks. For example, the transport protocol is text based and not binary.

• Web services are loosely coupled.

  Traditionally, application design has depended on tight interconnections at both ends. Web services require a simpler level of coordination that allows a more flexible re-configuration for an integration of the services in question.

• Web services provide programmatic access.

  The approach provides no graphical user interface; it operates at the code level. Service consumers need to know the interfaces to Web services but do not need to know the implementation details of services.

• Web services provide the ability to wrap existing applications.

  Already existing stand-alone applications can easily be integrated into the service-oriented architecture by implementing a Web service as an interface.

Plan to use Web services

You should plan your use of Web services that are developed and implemented based on the Web Services for Java 2, Enterprise Edition (J2EE) specification.

To plan to use Web services based on Web Services for J2EE, consider the following decision points:

• Design Web services to fit your e-business solution.
  Consider what you want to accomplish by using Web services, how Web services fit into your current topology, applications and programming model. Decide how the Web services will process requests on the server and how the clients will manage and use the Web service.

  Design your Web services for reliability, availability, manageability and security. For example, you want your Web services to process a transaction in a reasonable time at all hours of the day and provide users with good security characteristics, such as authentication for buyers. Planning to use Web services to work with WebSphere Application Server - Express helps to meet these requirements.

  To support Web services, extend WebSphere Application Server - Express to support Web services standards. For interoperable Web services running on platforms supplied by multiple vendors, standards are essential. WebSphere Application Server - Express uses Web services standards developed for the Java language under the Java Community Process (JCP). These standards include the Web Services for J2EE and JAX-RPC specifications.

• Decide what development and implementation tools to use.
  You can use a variety of manual development and implementation tasks. Whether you have an existing Web service to implement or you want to develop your own from a Java bean, you can choose different tasks respective to your resources. You can also use the WebSphere Development Studio for iSeries to complete development and implementation tasks.

  See Develop Web services for information about developing Web services based on the Java language through WebSphere Application Server.