Chapter 7 SOA and Web Services
SOA or service-oriented architecture has been one of the growing trends in the information technology realm over the last few years. Support for this approach has been on the rise, partly due to industry and vendor marketing hype, but also because IT organizations are looking for concrete solutions to manage their growing infrastructure and to be able to respond to the changing business demand. According to Kostas, (Kostas et al., 2007) service orientation has been touted as one of the most important technologies for designing, implementing, and deploying large-scale service provision software systems.
But what is SOA really, and why is it having such an influence on how we are architecting systems today? This chapter offers some discussion around that question and provides some basics around implementing web services within your architecture.
Pinning Down SOA
Arriving at a concrete definition of SOA can be somewhat difficult. The Open Group provides a robust and consumable definition of SOA (Group, 2006) as follows.
Service-oriented architecture (SOA) is an architectural style that supports service orientation. Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services. A service
• Is a logical representation of a repeatable business activity that has a specified outcome (for example, checking customer credit, providing weather data, or consolidating drilling reports)
• Is self-contained
• May be composed of other services
• Is a “black box” to consumers of the service
An architectural style is the combination of distinctive features in which architecture is performed or expressed.
The SOA architectural style has the following distinctive features:
• It is based on the design of the services—which mirror real-world business activities—comprising the enterprise (or inter-enterprise) business processes.
• Service representation utilizes business descriptions to provide context (that is, business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.
• It places unique requirements on the infrastructure—it is recommended that implementations use open standards to realize interoperability and location transparency.
• Implementations are environment-specific—they are constrained or enabled by context and must be described within that context.
• It requires strong governance of service representation and implementation.
• It requires a “litmus test,” which determines a “good” service.
This definition is a bit long but it helps to define the concepts around a service. Going forward with some of the points provided, a service is a self-contained consumable resource. Often when we talk about SOA and services we think about web services. One important point that has been made abundantly clear over the last few years is the idea of separating the concept of a SOA from the actual technology used in the implementation; that is, web services. While a web service and SOA seemingly go hand-in-hand, one does not always imply the other. One can embark upon an SOA strategy using technologies other than web services, and conversely, implementing web services within your organization does not mean that you are embracing a service-oriented strategy.
As Brenda Michelson states (Mamdouh et al., 2007), “Service-oriented architecture is much broader than the technology underpinnings that often describe it. Service-oriented architecture provides a means to express business activities as modular, configurable and composable software services.” This idea is important because it allows organizations to design a robust enterprise architecture that incorporates a number of implementation technologies, although standardization can also be an important factor. Web services definitely have a place within most infrastructures, providing a platform for interoperability between heterogeneous applications, but limitations also exist, depending upon the functional requirements of the applications being designed.
How to Implement SOA
Implementation patterns for SOA cross a wide range of technologies again based on existing systems and end requirements. Enterprise Service Bus is one such pattern that allows for the integration of new and existing systems using JMS, RMI, or of course, web services, but also provides for heterogeneous integration with translation, mediation, and other capabilities that are required in complex environments. Providing on-the-fly interoperability plays a big role in SOA and web services alone cannot fill that gap.
Service Modeling
Most SOA experts will tell you that building a service model is one of the first steps that is necessary. The need for a cohesive information model behind your collection of services is important because it allows services to be built intelligently within the organization. Simply wrapping data sources as services can result in a cumbersome approach that is just as ugly as the current point-to-point integration approach.
In addition to a specific set of models, a roadmap for implementing SOA within your organization is required. IBM provides roadmaps and best practices around specific industries and approaches and is available to any organization. Currently roadmaps are available for banking, healthcare, insurance, telecommunication, retail, and industrial organizations. These roadmaps enable your organization to undertake an SOA approach at a pace that your team can afford, allowing you to get the most benefit from SOA within your enterprise.
Modeling your business and understanding the benefits and impact from each service deployed within the organization can help provide a cost-benefit analysis of services and when and where they should be deployed.
Services as Business Functions
As a segue from service modeling, one important question that often gets raised is “what types of services should I build?” As Luciano and Feng state (Luciano and Feng, 2007) in their paper on service data objects, “These services [SOA] will offer business functionality as a unit or as a whole. These services will access data from different data source types and potentially need to aggregate data from different data source types with different data formats. In this type of environment, handling of different forms of data poses a big challenge for application developers, and the challenge increases in size when you consider the broad diversity of programming models in use.”
With this in mind extending the technology beyond just the use of web services has been a major goal of many vendors. Message Queue and Enterprise Service Bus technology are examples of growing trends in SOA, as well as the use of additional technologies to help take advantage of SOA implementations within the enterprise. Business process management and process services are additional technology advancements that are becoming increasingly useful as organizations continue to embrace SOA.
Other Types of Services
The concept of application and infrastructure type services is also continuing to grow within many IT shops. These utility types of services are perhaps even more important in some ways than business services, because they get used by all or many different applications. The idea of managing or retrieving a user profile comes to mind as a reusable IT services that can be made available across multiple applications within the enterprise. Often a user profile can be considered a standard business function or an extension of Customer Data. However, user profile information can come from different sources, so it may be a unique service that gets aggregated into the composite Customer Data service, or it may be used independently as some type of authentication or authorization service.
Managing Service Data Elements
Two seemingly minor advancements that will have a big impact on managing service data elements are the use of Service Data Objects (SDO) and the concept of a Service Component Architecture (SCA). Working together these technologies will further allow the abstraction of unique sources and provide for increased interoperability in areas other than web services. With the release of SDO specification version 1 in early 2007 by the OSOA (OSOA, 2007), application server vendors are starting to provide technical previews and build this functionality into their products. Think of SDOs as data or value objects on steroids, providing a robust API that allows you to combine, share, and update from multiple heterogeneous data sources.
You can think of SCA as a service layer abstraction that allows you to build services using a number of technologies and within any tier of your infrastructure, and then expose those services using a variety of communication protocols.
A Commitment from the Business
Governance and management of services play a big role in SOA. Without a strong commitment from IT management, and from the business owners, the benefit of SOA cannot be realized effectively. Development, evolution, and maintenance of SOA-based systems demands rethinking traditional roles for performing these activities (Mira, Grace, and Dennis, 2007). Some of the key factors that play into this effort include ensuring that everyone who is involved understands the investment required to embrace an SOA strategy. Additionally there are many technical issues, like scaling services as demand increases, locating existing services, and service maintenance, as new requirements are put into place. Exiting roles change when in the course of an SOA transition, traditional silo'ed applications no longer exist. A silo'ed application is one that exists by itself and cannot interoperate with other applications. New applications are being composed out of many new and existing services, and all service owners are involved and are responsible for the success of these new applications. Conversely, when an application fails, some amount of advanced detective work is necessary to understand whether the cause lies within the application itself, or is because of some underlying service that does not have the necessary service-level agreements in place to keep up with performance requirements (Liam, Paulo, and Len, 2007). New approaches for managing these problems are being proposed such as a stakeholder-driven service lifecycle model (Qing and Patricia, 2007), where stakeholder roles such as service provider and service consumer gain new responsibilities and commitments to the organization.
The business is also finding new responsibility for defining services that will drive the organization. Business Process Management, or BPM, is gaining new ground in determining which processes can help to drive the business and help maintain a competitive edge by using Business Process Modeling to analyze business processes (Bala, Kaori, Makoto, Akio, and Jay, 2006) and drive process transformation across the business.
One fact that everyone—vendors, academics, and IT shops—can agree on is that SOA is not easy. The benefits appear to be high. Increasing service granularity and improving reuse can allow the business to respond more quickly to changing business demand (Joseph, 2006). But the cost of achieving the benefits of SOA is not trivial when trying to build a flexible and scalable set of services across a large organization. Many organizations have adopted a strategy of applying SOA in stages across many projects and years in an attempt to manage investment and realize appropriate value. A green field or clean slate approach to designing a new application is simply not feasible for any organization that has been around for any length of time and that has existing legacy applications.
Things to Consider about Web Services
Web services, or most types of services, offer several great advantages, two of which are interoperability and distribution. Interoperability allows systems and applications to work together in ways that they never were able to before. Organizational IT departments are filled with a mish-mash of legacy systems that were never designed to work with other systems. In some cases, legacy could mean a system that is only a few years old and still cannot be used outside of its own world. But, if we can expose those systems through some standard service protocols then we can begin to see how applications can work together, or parts of a legacy system can be consumed and used by the business in new ways. The power can be intoxicating. Distribution of web services can be more of a concern when considering performance, which is discussed in detail in Chapter 8, “Caching and Performance.”
But what are the disadvantages of this type of approach? Are there really any? Well, not in the sense that there really is a disadvantage, but there are risks that can occur if you jump headlong without checking the waters for hidden boulders. Let's take a look at a few potential boulders.
Performance
Performance is a big issue, and one that worries me the most. There are two main components to this concern:
• Distribution: Distribution of services raises several questions. Latency is one aspect, but also how services will be used. How course grained are the services to be defined? Will you have to make several calls to retrieve the data that you need, how responsive are the services designed, and over what speed will the network calls be provided? There are many questions to be answered in the design phase of the service project.
• Dependency: We now have applications that are dependent upon other applications. When a problem occurs, the end user–facing application is the one that will get blamed. I have learned this firsthand working in the portal space with IBM WebSphere Portal.
Just these two factors alone can work against you. Combine them with the fact that composite services are dependent upon other services within the enterprise or legacy back-end systems, and you can see that problems can occur that are very difficult to recover from without redesigning the application.
Standardization
Standards are slowly converging into some generally recognized approaches, but they are still slow in coming and there are still gaps to be filled. Even with sets of industry standards available, you still have battles to fight within your own organization. Microsoft, IBM, Sun, and other vendors all have their own agenda in getting you to adopt their standard approach. You might think that web services are all about integration so it shouldn't matter, but publishing a service with one standard or technology and trying to consume or use that service with a different standard can sometimes cause problems. Usually you can overcome these issues, but the goal is to streamline the development approach, not make it harder.
Web Service Interoperability (WS-I) is an important idea that has been established across the industry. The WS-I organization at http://www.ws-i.org/ is designed to confirm and publish the best practices for web service interoperability across platforms, operating systems, and languages.
Manageability
Managing and governance over a service or set of services is probably the biggest issue of all. Once the simplest service is put in place within the enterprise the trouble may start. Other applications begin to consume and depend upon that service. Any change can now break these dependencies, wreaking havoc across the enterprise.
Maybe the result wouldn't be that drastic, but those dependencies will exist. And the owners of each part of the application may be different. Some of the questions that need to be asked around this aspect include
• What services are available within the enterprise?
• Who is using which services and what are their SLA requirements?
• What versions exist for different services, and what is the maintenance schedule?
Obviously, this discussion barely scratches the surface of the this topic, but you can see that as services and their dependencies grow, then the effort and investement needed to manage those services needs to keep up with this growth. Standards are currently lacking in this area, but IBM is providing some leadership with best practices and products to help fill the gap. WebSphere Registry and Repository is a complete system for managing and versioning services within an organization.
Web Services Feature Pack for WAS
As of this writing, IBM has implemented the Java API for XML Web Services (JAX-WS) programming model in the form of a Web Services Feature Pack for WebSphere 6.1. The feature pack takes an open standards approach toward building web services and includes the following standards:
• Web Services Reliable Messaging (WS-RM)
• Web Services Addressing (WS-Addressing)
• Java API for XML Web Services (JAX-WS 2.0)
• Java Architecture for XML Binding (JAXB 2.0)
• SOAP Message Transmission Optimization Mechanism (MTOM)
• SOAP 1.2
• SOAP with Attachments API for Java (SAAJ 1.3)
This model allows developers to create web services using JAX-WS annotations. Additional tooling, shown in Figure 7.1, helps with implementation and is also available within the latest Rational Application Developer (RAD) versions.
Figure 7.1 RAD WS Tooling
The feature pack also supports the Java Architecture for XML Binding 2.0 (JAXB) specification. This binding replaces the WS-RPC binding scheme.
Annotations are a major attraction of this feature pack and allow you to build web services as easily as you built EJBs in Chapter 3, “Persistence Matters.”
Credit Limit Service
Walking through a simple example will illustrate how easy implementing a simple web service can be using the Web Service Feature Pack. Keep in mind that this example is kept simple and does not take into account any security or exception handling that would definitely be necessary in any enterprise service. The example is a simple web service that provides the credit limit for any given customer. This task could be realistic in the sense that credit limits would be stored or calculated separately from other customer data. Because this information is sensitive, access may be limited to specific sets of users within the organization.
Start by defining a simple interface that outlines the service function. This interface defines one method, getCreditLimit(), which is in line with the goal of keeping things as simple as possible for examples. All of the sample code discussed within this book is listed in Appendix B, “Running the Examples,” along with information on where to download the samples.
package com.ibmpress.cm.services.credit;
public interface ICreditLimit {
public double getCreditLimit( int custnum);
}
Implementing this interface is a Plain Old Java Object (POJO) that looks like most any class that you would find within an application. The method getCreditLimit() uses the provided customer number to do a database query on the CUSTOMER table and retrieve the credit limit for the customer. In some cases returning the entire customer record may make sense, but for simplicity pretend that this credit limit service serves a unique purpose.
public class CreditLimit implements ICreditLimit {
public CreditLimit() {
…get datasource here.
}
public double getCreditLimit( int custnum) {
System.out.println("customer number: " + custnum);
…look up credit limit with provided customer number here
return result; }
}
So far you have seen nothing new, but now you can create a web service using JAX-WS and some custom annotations. By creating a wrapper class with the annotations the application server will create a dynamic WSDL and the bindings needed to call the class when the web service is accessed. Figure 7.2 shows the class diagram of the credit limit service.
Figure 7.2 Credit limit service diagram
The wrapper class, called CreditLimitDelegate(), creates an instance of the actual class and provides a wrapper to the methods within that class.
package com.ibmpress.cm.services.credit;
@javax.jws.WebService
(targetNamespace="http://credit.services.cm.ibmpress.com/",
serviceName="CreditLimitService", portName="CreditLimitPort")
public class CreditLimitDelegate{
com.ibmpress.cm.services.credit.CreditLimit _creditLimit = new
com.ibmpress.cm.services.credit.CreditLimit();
public double getCreditLimit(int custnum) {
return _creditLimit.getCreditLimit(custnum);
}
The first annotation you will notice is the @WebService annotation. It identifies this class as a web service. Because the WSDL is created dynamically from this class, this annotation is all that is needed. Once the code is deployed, you can browse to view the WDSL that has been defined via the annoations. Browsing to http://localhost:9081/CreditLimitService/ CreditLimitService/creditlimitservice.wsdl shows the results in Figure 7.3.
Figure 7.3 Dynamic WSDL generation
This example is, of course, the simplest implementation of a web service using JAX-WS, where the service was created via a bottom-up scenario. This means that the Java object was created first, and then the web service was created from that definition. In many cases your service will need to adhere to a specific type of WSDL. In these cases a top-down approach will probably be desired by defining the WSDL first and then creating the Java object stubs to fill with the required business logic.
Testing the Service
Rational Application Developer (RAD) tools for the Web Service Feature Pack allows the generation of a test client that you can use to test the created web service. This full-featured client, shown in Figure 7.4, is eerily reminiscent of the Web Services Universal Test Client that also comes with RAD.
Figure 7.4 Web service test application
Nevertheless this application generates all the client code that will be necessary to create your own application. Ignoring all the JSPs that make up most of the user interface, two parts are the core of the application. The CreditLimitPortProxy class can be used to call the web service from your own application. Figure 7.5 shows the web service client code that is generated by the wizard.
Figure 7.5 Web service client code
The CreditLimitPortProxy is the entry way into accessing the web service. This class has an inner class called a Descriptor that allows the dispatch information to be encapsulated into a member of the proxy class. This nice use of an inner class helps organize much of the mess that web services seem to raise.
public class CreditLimitPortProxy{
protected Descriptor _descriptor;
public class Descriptor {
private CreditLimitService _service = null;
private CreditLimitDelegate _proxy = null;
private Dispatch<Source> _dispatch = null;
public Descriptor() {
_service = new CreditLimitService();
initCommon();
}
public Descriptor(URL wsdlLocation, QName serviceName) {
_service = new CreditLimitService(wsdlLocation,
serviceName);
initCommon();
}
private void initCommon() {
_proxy = _service.getCreditLimitPort();
} public CreditLimitDelegate getProxy() {
return _proxy;
} public Dispatch<Source> getDispatch() {
…
}
}
public CreditLimitPortProxy() {
_descriptor = new Descriptor();
}
public CreditLimitPortProxy(URL wsdlLocation, QName serviceName) {
_descriptor = new Descriptor(wsdlLocation, serviceName);
}
public Descriptor _getDescriptor() {
return _descriptor;
}
public double getCreditLimit(int arg0) {
return _getDescriptor().getProxy().getCreditLimit(arg0);
}
}
At the bottom of the proxy class is the method that you are after, which wraps the web service method call into a simple local function. Additionally the data transfer objects, GetCreditLimit and GetCreditLimitResponse, are generated to be used by JAXB. As you may remember JAXB defined a Java-to-XML translation protocol, which is used in this sample instead of a standard SOAP message protocol.
The CreditLimitDelegate interface defines the @WebService and @WebMethod information in place of a WSDL file in the local client. These annotations allow the JAX-WS libraries to generate a dynamic WSDL to access the remote service.
package com.ibmpress.cm.services.credit;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebResult;
import javax.jws.WebService;
import javax.xml.ws.RequestWrapper;
import javax.xml.ws.ResponseWrapper;
@WebService(name = "CreditLimitDelegate", targetNamespace =
"http://credit.services.cm.ibmpress.com/")
public interface CreditLimitDelegate {
@WebMethod
@WebResult(targetNamespace = "")
@RequestWrapper(localName = "getCreditLimit", targetNamespace =
"http://credit.services.cm.ibmpress.com/", className =
"com.ibmpress.cm.services.credit.GetCreditLimit")
@ResponseWrapper(localName = "getCreditLimitResponse", targetNamespace = "http://credit.services.cm.ibmpress.com/", className =
"com.ibmpress.cm.services.credit.GetCreditLimitResponse")
public double getCreditLimit(
@WebParam(name = "arg0", targetNamespace = "")int arg0);
}
Building a New Client Application
You can now use the generated web service client code in any application or local service layer to access this web service. A new web application, shown in Figure 7.6, can be developed that allows a user to interact more comfortably with the credit limit service.
Figure 7.6 Service client
By posting the entered customer number to a servlet, the generated proxy can be instantiated to serve as an interface for this application.
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
PrintWriter out = response.getWriter();
Short customerid = Short.valueOf(request.getParameter("customerid"));
out.println("Customer ID: " + customerid);
out.println("<br><br>getting proxy.<br><br>");
CreditLimitPortProxy myProxy = new CreditLimitPortProxy();
out.println("Credit Limit: " + myProxy.getCreditLimit(customerid));
}
This servlet uses the proxy to access the service with very little code written on our part except to instantiate the proxy and use the available methods. Figure 7.7 illustrates the outcome of the client application.
Figure 7.7 Access the web service
You can easily imagine the next steps of moving this proxy to a utility library or local service layer that can proxy the service, and perhaps adding additional information to the query. For example, instead of retrieving just the credit limit, you could have the local customer lookup retrieve additional customer information and return a data object containing all the information about that customer.
Figure 7.8 shows just this case, where the proxy has been moved to a business layer that processes a number of lookups and then provides an aggregated view of the customer information.
Figure 7.8 Service integration
Simple REST-Based Services
Recently there has been a trend in another direction when building web services. Representational State Transfer or REST has seen a surge in popularity for building quick and simple services, especially for work with the presentation layer. Put another way, you can think of REST as a protocol for transferring the representation of some resources current state, either what it currently is, or by modifying the state to what you need it to be by updating or perhaps deleting the resource.
REST builds off of those aspects of the World Wide Web that have made it so popular—using a simple HTTP protocol and generic interfaces to access available resources. These interfaces follow the current HTTP approach using GET, POST, PUT, and DELETE. Using the HTTP protocol, responses are streamed directly in XML rather than using SOAP to wrap the request/response cycle.
REST-based services, in conjunction with Ajax or Asynchronous Java with XML, have become very popular because you can update the display of a page without having to do a full page refresh on the server. Just specific sections of the page can be updated either in real time or when the user requests an update.
Building a REST service using the servlet interface can be a simple exercise. Note that you are not using any web service tooling here; it is just a simple output of basic XML. The example servlet works like any other servlet but the output will not be HTML.
public class CurrentCreditLimit extends javax.servlet.http.HttpServlet
implements javax.servlet.Servlet {
static final long serialVersionUID = 1L;
javax.sql.DataSource ds = null;
public CurrentCreditLimit() {
super();
…setup data source
}
The doGet() method has been implemented to return the current representation state of a customer's credit limit. The servlet output is a simple XML stream for use by any client. Also present is a helper method that does the credit limit lookup. The implementation of this aspect is not important for this example.
protected void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
PrintWriter out = response.getWriter();
response.setContentType("text/plain");
int custnum = Short.valueOf(request.getParameter("customerid"));
System.out.println("customer number: " + custnum);
out.println("<customer>");
out.println("<customerid>" + custnum + "</customerid>");
out.println("<creditlimit>" + getCreditLimit(custnum) +
"</creditlimit>");
out.println("</customer>");
}
private String getCreditLimit(int custid){
…Lookup credit limit for customer
}
Finally, some additional servlet methods are included that map directly to the generic interfaces that the REST architecture suggests you should follow such as the put method. These methods have not been implemented in this example.
protected void doPost(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
…modify resource
}
protected void doPut(HttpServletRequest request, HttpServletResponse response) throws
ServletException, IOException {
super.doPut(request, response);
…create resource
}
protected void doDelete(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
super.doDelete(request, response);
…delete resource
}
As mentioned, there is no defined WSDL for these types of services. This can be both good and bad. Without some type of service definition it is hard for the client to know how to use the service and what the response will look like.
Client Interaction with REST
Much of the focus in the industry today is to use REST within the presentation layer, but this does not necessarily have to be the case. REST services can be placed anywhere within the enterprise for consumption by other clients. One could easily use some java.net code to create a URL and interact with a REST service, but these services do lend themselves well to presentation layer functionality because of the commonality with web-based protocols. Ajax has played nicely into that collaboration with the use of asynchronous data calls to services. The simple client shown in Figure 7.9 illustrates how you might consume a REST service within your web page.
Figure 7.9 Building a REST-based application
Much of the page is routine Ajax. The function creditLimitCallback()can be used to parse and use the XML that is returned from the service. This function will be passed the data from a good response to the service.
<%@ page language="java" contentType="text/html; charset=ISO-8859-1"
pageEncoding="ISO-8859-1"%> <
!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>Test JSP</title>
<style type="text/css">
@import "dojoroot/dijit/themes/soria/soria.css"
@import "dojoroot/dojo/resources/dojo.css"
</style>
<script type="text/javascript" src="dojoroot/dojo/dojo.js"
djConfig="parseOnLoad: true"></script>
<script type="text/javascript">
dojo.require("dijit.form.TextBox");
dojo.require("dijit.form.Button");
function creditLimitCallback(data,ioArgs) {
alert(data);
}
function creditLimitError(data, ioArgs) {
alert(‘Error when retrieving data from the server!’;);
}
</script>
</head>
The body of the page has two form elements: a textbox and a button. In the button is an embedded script that creates a URL to the service, adding the customer ID that should be entered into the text box. This script then performs an xhrGet command to send the request to the servlet and pass the returned data to the creditLimitCallback() function that was shown earlier.
<body>
<h2>Credit Limit REST Client</h2>
Customer ID:
<input dojoType="dijit.form.TextBox" id="customerid" type=text name="customerid"/>
<br><br>
<button dojoType="dijit.form.Button" id="creditLimitButton">GetCreditLimit
<script type="dojo/method" event="onClick">
var urlValue = "/CreditLimitRESTService/CurrentCreditLimit?customerid="
urlValue = urlValue + dojo.byId('customerid').value;
dojo.xhrGet({
url: urlValue,
load: creditLimitCallback,
error: creditLimitError
});
</script>
</button>
</body>
</html>
Figure 7.10 shows the page in action. The user should type in a customer ID in the text box and click the button; the script will make a GET request to the service with the customer ID parameter. The resultant XML is then shown in an alert box.
Figure 7.10 Sample REST client
This simple example hopefully enables you to see how you can incorporate REST services into your application. As with most things, REST and Ajax are tools to help you deliver the best value to your customer and end user. Used in this way, the approach actually goes against the SOA principle of reuse. Consider that not every feature within your application has to be Ajax enabled, as that may be considered a poor use of business dollars. But do not let that dissuade you from understanding the principles and approach where REST may add good value to your application.
Conclusion
You may have noticed that there was no manual WSDL building within this chapter. That is actually not common in SOA and web service work. The Web Service Definition Language is the contract that your services need to abide by, and hence are pretty important. But they are also ugly and complicated to build, so anytime you can use tooling to do the dirty work you should try to take that route. Not everyone in an organization is going to be an expert at using a WSDL document so you should make it as easy as possible to create and consume web services across the enterprise. With the new WSDL 2.0 specification these tasks are getting easier, but as requirements increase, things also tend to get more complicated.
Links to developerWorks Articles
A7.1 developerWorks SOA and Web Services Zone, http://www.ibm.com/developerworks/webservices
A7.2 Developing Web services for WebSphere using JAX-WS Annotations, Jeff Barrett, Dustin Amrhein, Bruce Tiffany, http://www.ibm.com/developerworks/websphere/library/
techarticles/0711_tiffany/0711_tiffany.html
References
Bala, R., Kaori, F., Makoto, K., Akio, K., and Jay, B. (2006). Business process transformation patterns & the business process transformation wizard. Paper presented at the Proceedings of the 38th Conference on Winter simulation. Retrieved October 2, 2007, from http://delivery. acm.org.dml.regis.edu/10.1145/1220000/1218232/p636-ramachandran. pdf?key1=1218232&key2=5810404911&coll=ACM&dl=ACM&CFID=41408235&
CFTOKEN=96264195
Group, Open Group (2006, June 8, 2006). Service Oriented Architecture (SOA). Retrieved October 10, 2007, from http://www.opengroup.org/projects/soa/doc.tpl?gdid=10632.
Joseph, B. (2006). Service-oriented architecture (SOA): a new paradigm to implement dynamic e-business solutions. Ubiquity, 7(30), 1-1.
Kostas, K., Grace, A. L., Dennis, B. S., Marin, L., Hausi, M., Stefan, S., et al. (2007). The Landscape of Service-Oriented Systems: A Research Perspective. Paper presented at the Proceedings of the International Workshop on Systems Development in SOA Environments. Retrieved October 2, 2007, from http://portal.acm.org.dml.regis.edu/citation.cfm?id= 1270298&coll=ACM&dl=ACM&CFID=41408235&CFTOKEN=96264195#
Liam, O. B., Paulo, M., and Len, B. (2007). Quality Attributes for Service-Oriented Architectures. Paper presented at the Proceedings of the International Workshop on Systems Development in SOA Environments. Retrieved October 2, 2007, from http://portal.acm. org.dml.regis.edu/citation.cfm?id=1270300&coll=ACM&dl=ACM&CFID=41408235&CFTOKEN=96264195#.
Luciano, R., and Feng, R. (2007). Handling heterogeneous data sources in a SOA environment with service data objects (SDO). Paper presented at the Proceedings of the 2007 ACM SIGMOD international conference on Management of data. Retrieved October 2, 2007, from http://doi.acm.org/10.1145/1247480.1247582.
Mamdouh, H. I., Kerrie, H., Nicolai, M. J., Brenda, M., Dave, T., and John, D. (2007). The future of SOA: what worked, what didn't, and where is it going from here? Paper presented at the Companion to the 22nd ACM SIGPLAN conference on Object-Oriented Programming Systems and Applications Companion. Retrieved October 2, 2007, from http://portal.acm. org.dml.regis.edu/citation.cfm?id=1297975&coll=ACM&dl=ACM&CFID=41408235&CFTOKEN=96264195#
Mira, K.-M., Grace, A. L., and Dennis, B. S. (2007). A Framework for Roles for Development, Evolution and Maintenance of SOA-Based Systems. Paper presented at the Proceedings of the International Workshop on Systems Development in SOA Environments. Retrieved October 2, 2007, from http://delivery.acm.org.dml.regis.edu/10.1145/1280000/1270304/29600007. pdf?key1=1270304&key2=2695304911&coll=ACM&dl=ACM&CFID=41408235&CFTOKEN =96264195
OSOA (2007). Service Component Architecture Specification – Assembly Model V1.00, Open Service Oriented Architecture (OSOA). Available from http://www.osoa.org/display/Main/ Service+Component+Architecture+Specifications.
Qing, G., and Patricia, L. (2007). A stakeholder-driven service life cycle model for SOA. Paper presented at the 2nd International Workshop on Service Oriented Software Engineering: in conjunction with the 6th ESEC/FSE joint meeting. Retrieved October 2, 2007, from http://portal.acm.org.dml.regis.edu/citation.cfm?id=1294930&coll=ACM&dl=ACM&CFID=41408235&CFTOKEN=96264195#.