Featured end-to-end paths

These end-to-end paths feature the latest design. Start here for step-by-step guidance in using the product to reach your goals. First, identify the scenario that most closely matches our own project goal, such as updating and redeploying an existing application to include telephony services. Follow one of the linear paths to reach the goal. Conceptual background is provided to help to adapt each path to the specific situation.

Subtopics

• Migrate cells using the command-line tools
  

• Set up the communications enabled application samples
  We can set up a single-server environment to use the computer telephony integration (CTI) and web collaboration capabilities of IBM WebSphere Application Server v8.5.

• Making phone calls in web applications
  We can embed the ClickToCall widget in an existing application to enable users to enter their phone number and request an immediate callback from the company. You embed the communications enabled applications (CEA) widget using the Dojo Toolkit provided with the CEA feature.

• Receiving call notifications in web applications
  We can embed the CallNotification widget in an existing application to enable users to enter their phone number and receive notifications of incoming calls. You embed the communications enabled applications (CEA) widget using the Dojo Toolkit provided with the CEA feature.

• Collaborating and cobrowsing in web applications
  We can embed the Cobrowse widget in an application so that users can share the same browsing session, with one user controlling the session. We can use the Dojo Toolkit that comes with the CEA feature to embed the CEA widgets in the applications.

• Implement two-way forms in web applications
  We can create and configure two-way forms in web applications using the communications enabled applications (CEA) TwoWayForm widget.

• Access telephony services with web services clients
  We can integrate telephony services into new and existing applications using the web services interface of communications enabled applications (CEA). Telephony services include making phone calls, receiving phone calls, and receiving call notifications within the web application.

• Configure external web service providers to use CEA
  We can configure communications enabled applications (CEA) to use an external web service provider that supports the CEA WSDL file.

• Access telephony services with REST APIs
  We can integrate web telephony into new and existing applications using a Representational State Transfer (REST) API. Telephony features include making phone calls, receiving phone calls, and receiving call notifications within the web application.

• Share data across two sessions with REST APIs
  We can build cobrowsing into applications using REST APIs. A cobrowsing session allows two web users to share the same browsing session using side-by-side modal windows. One user controls the session; the other user has no control, but can view the activity of the other user.

• Implement EJB 2.x applications
  Use this task when we are implementing EJB 2.x applications.

• Implement EJB 3.x applications
  Use this task when we are implementing EJB 3.x applications.

• Implement EJB applications that use timers
  Use this task when we are implementing EJB applications that use timers.

• Secure web services applications at the transport level
  Transport-level security is a well-known and often used mechanism to secure HTTP Internet and intranet communications. Transport level security can be used to secure web services messages. Transport-level security functionality is independent from functionality provided by message-level security (WS-Security) or HTTP basic authentication.

• Authenticating web services clients using HTTP basic authentication
  A simple way to provide authentication data for the service client is to authenticate to the protected service endpoint by using HTTP basic authentication. HTTP basic authentication uses a user name and password to authenticate a service client to a secure endpoint.

• Secure JAX-WS web services using message-level security
  Web Services Security standards and profiles address how to provide message-level protection for messages that are exchanged in a web service environment.

• Secure JAX-RPC web services using message-level security
  Standards and profiles address how to provide protection for messages that are exchanged in a web service environment.

• Secure web services using Security Markup Assertion Language (SAML)
  The Security Assertion Markup Language (SAML) is an XML-based OASIS standard for exchanging user identity and security attributes information. Using SAML, a client can communicate assertions regarding the identity, attributes, and entitlements of a SOAP message. We can apply policy sets to JAX-WS applications to use SAML assertions in web services messages and in web services usage scenarios. Use SAML assertions to represent user identity and user security attributes, and optionally, to sign and to encrypt SOAP message elements.

• Authenticating web services using generic security token login modules
  We can use the generic security token login modules to issue, validate, and exchange security tokens using an external Security Token Service (STS).

• Configure LTPA and working with keys
  We must configure LTPA> (LTPA) when you set up security for the first time. LTPA is the default authentication mechanism for WebSphere Application Server. After we have configured LTPA we can generate LTPA keys manually or automatically.

• Customize application login with Java Authentication and Authorization Service
  Using JAAS, we can customize the application login.

• Create a single sign-on for HTTP requests using SPNEGO Web authentication
  Creating single sign-ons for HTTP requests using the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) web authentication for WebSphere Application Server requires the performance of several distinct, yet related functions that when completed, allow HTTP users to log in and authenticate to the Microsoft domain controller only once at their desktop and to receive automatic authentication from the WAS.

• Set up Kerberos as the authentication mechanism for WebSphere Application Server
  We must perform the steps to set up Kerberos as the authentication mechanism for WebSphere Application Server.

• Task overview: Accessing data from applications
  Various enterprise information systems (EIS) use different methods for storing data. These backend data stores might be relational databases, procedural transaction programs, or object-oriented databases.

• (zos) Use optimized local adapters for inbound support
  Use this task when we are implementing the optimized local adapters support for calling inbound to WebSphere Application Server for z/OS EJB applications.

• (zos) Use optimized local adapters for outbound support
  Use this task when we are implementing the optimized local adapters support for calling programs in external address spaces from WebSphere Application Server for z/OS applications.

• Implement web services applications with JAX-WS
  When starting from existing JavaBeans or enterprise beans, we can use a bottom-up approach to developing Web services based on the JAX-WS programming model.

• Implement web services applications from existing WSDL files with JAX-WS
  When starting with an existing Web Services Description Language (WSDL) file, we can use a top-down approach to developing web services based on the JAX-WS programming model.

• Implement static JAX-WS web services clients
  We can develop static web services clients based on the Web Services for Java EE specification and the JAX-WS programming model.

• Implement dynamic JAX-WS web services clients
  We can develop dynamic web services clients based on the Web Services for Java EE specification and the JAX-WS programming model.

• Implement JAX-RS web applications
  

• Use XML content in JAX-RS application requests and responses
  XML is a common media format that RESTful services consume and produce. To deserialize and serialize XML, we can represent requests and responses by JAXB annotated objects.

• Use JSON content in JAX-RS application requests and responses
  JavaScript Object Notation (JSON) is a common media format that RESTful services consume and produce. We can use this lightweight data-interchange format based on the object-literal notation of JavaScript to exchange data.

• Use Atom content in JAX-RS application requests and responses
  We can use the Atom Syndication Format (Atom) to format web feeds, which communicate news and updates of episodic information about websites. Using Atom content in JAX-RS applications, we can take advantage of web content syndication that provides the same decentralized, dynamic mechanisms for adding new metadata and content supported by RSS, but does so in a way that helps protect core interoperability between implementations.

• Use custom entity formats
  Even though the Java API for RESTful Web Services (JAX-RS) runtime environment includes several entity providers for handling serialization from and deserialization to Java types, it does not support all possible media types. We can develop a custom entity provider to handle binding Java types to message bodies.

• Use content negotiation to serve multiple content types in JAX-RS applications
  One of the advantages of RESTful applications is the ability to return different representations of resources. With Representational State Transfer (REST), clients and servers can exchange resources of the same media type or use differing media types. Content negotiation enables clients and servers to agree on the content format used to exchange data.

• Use JAX-RS context objects to obtain more information about requests
  Java API for RESTful Web Services (JAX-RS) provides different types of context to resource classes and providers. We can use context objects to access request information such as discovering the HTTP headers sent as part of the request. Context objects also provide convenience methods for evaluating a request and building an appropriate response.

• Implement RESTful views of EJB applications using JAX-RS
  If we have enterprise JavaBeans (EJB) applications, we can expose a RESTful interface to the enterprise bean using Java API for RESTful Web Services (JAX-RS). By implementing JAX-RS annotated enterprise beans, we keep the EJB functionality including transaction support, injection of Java EE components and resources, and other EJB session bean capabilities.

• Use Java contexts and dependency injection with JAX-RS
  Java API for RESTful Web Services (JAX-RS) root resources and providers can be used in a Java Contexts and Dependency Injection (JCDI) enabled web archive (WAR). Simply add a valid WEB-INF/beans.xml file to the WAR file and any JAX-RS root resources and providers that are valid JCDI beans can use JCDI functionality.

• Use handlers to enhance request and response processing
  We can implement handlers on the server-side of a Java API for RESTful Web Services (JAX-RS) application to enhance request and response processing.

• Use multipart content in JAX-RS application requests and responses
  Using multipart messages, servers and clients can transmit multiple messages using a single message. Multipart messages are useful when both the client and server need to send multiple requests but want to save the cost of sending and receiving entire HTTP request and responses for each part.

• Use multipart/form-data content in JAX-RS application requests and responses
  A frequently used content type for submitting files through an HTML form is multipart/form-data. The IBM implementation of Java API for RESTful Web Services (JAX-RS) greatly simplifies the processing of such data by automatically splitting the parts and automatically decoding them. If such automatic processing is not desired, the resource may instead receive the parts in an object so processing of the parts is under the complete control of the resource method.

• Implement secure JAX-RS applications
  The IBM runtime environment for Java API for RESTful Web Services (JAX-RS) is driven by a servlet derived from the Apache Wink project. Within the WAS environment, the lifecycle of servlets is managed in the web container. Therefore, the security services offered by the web container are applicable to REST resources that are deployed in WebSphere Application Server.

• Use WADL to generate service documentation
  Web Application Description Language (WADL) is a description language for HTTP-based applications. It is currently a World Wide Web Consortium (W3C) Member Submission. WADL can be used by programs to give information about the service in a machine-processable method. For instance, we can use an Extensible Stylesheet Transformation (XSLT) document to transform the WADL documentation by using a custom XSLT and a XSLT processor.

• Use the Apache Wink REST client inside server applications to issue requests
  We can use the Apache Wink REST client as a client that can be run to send requests to the JAX-RS application.

• Use the Apache Wink REST client as a stand-alone thin client
  Instead of using the Apache Wink REST client inside a server application, we can use the Thin Client for JAX-RS provided with WebSphere Application Server as a stand-alone thin client to send requests to the RESTful service. The Thin Client for JAX-RS is a stand-alone Java SE 6 client environment that enables running unmanaged JAX-RS RESTful web services client applications in a non-WebSphere environment to invoke JAX-RS RESTful web services that are hosted by the application server.

Related concepts

Web resources for learning