IBM WebSphere Developer Technical Journal: Accelerated JSF development for XML-based SOA using Rational Application Developer and WebSphere Application Server -- Part 1

Introducing the XSD SDO transform feature

This article series presents a solution that accelerates presentation development for XML-based Service Oriented Architecture (SOA) applications. This solution includes an Eclipse feature that enables the generation of statically typed Service Data Objects (SDO) for an XSD Schema, and provides a runtime framework for using SDOs in the transformation of presentation element data to and from XML data.

Narinder Makin, Software Architect, IBM Rational SOA tools, IBM

Narinder Makin is a software architect at IBM Research Triangle Park Lab in Durham, North Carolina. He works in the area of Deployment tools for the Rational Software Architect team. He has worked on variety of Model Driven Development/Deployment tools over the past 12 years. He has several patents and published articles. He holds an undergraduate degree in Computer Sc. and Engg. from K.N.I.T, India and also holds a MS in Computer Science from University Of Bridgeport, Connecticut.



Ritchie Schacher (schacher@us.ibm.com), Advisory Software Engineer, J2EE Tools, IBM Research Triangle Park Lab, North Carolina

Ritchie Schacher is a software engineer at IBM Research Triangle Park Lab in Durham, North Carolina. He is a developer of J2EE tools for WebSphere Studio Application Developer. You can reach Ritchie at schacher@us.ibm.com



Daimar Hernandez (daimarh@us.ibm.com), Staff Software Engineer, IBM, PVT Team

Daimar Hernandez is a software engineer at IBM Research Triangle Park Lab in Durham, North Carolina. She is a developer in the PVT team for the Rational Application Developer team.



Daniel Berg (danberg@us.ibm.com), Senior Software Engineer, IBM, Rational SOA tools

Daniel Berg is a software engineer at IBM Research Triangle Park Lab in Durham, North Carolina. He is a lead architect for J2EE and SOA/SDO tools for the Rational Application Developer team.



01 December 2004

Introduction

Loosely coupled, coarse-grain Service Oriented Architecture (SOA) applications developed around XML Data Interchange often require some level of presentation development. A basic requirement of such an architecture is the binding of presentation controls to the data objects and the transformation of data objects to/from XML data. The existing frameworks used for presentation development, such as JavaServer™ Faces (JSF), enable the data transfer between the presentation elements to the attributes and references of the Java™ bean classes. The tedious task of accomplishing transformation from XML to/from data objects is left to the developer, either by using third party specialized frameworks or by writing code.

This five-part article series presents a solution that accelerates presentation development of XML-based SOA applications, and includes an Eclipse feature that enables the generation of statically typed service data objects (SDO) for an XSD Schema, and a runtime framework for the transformation of presentation element data to/from XML data using SDOs.

In Part 1 of this five-part series, we will walk through the development of a simple JSF application using the supplied plug-in set that communicates to a service per the specified XML schema. The application scenario in this article makes one service invocation that sends one XML request and receives one XML response. This application illustrates the master-detail view of data objects along with pagination and sorting capabilities. The design-time and runtime architecture of the application are also depicted in this article.

Rational® Application Developer V6 and Websphere® Application Server V6 are required to take advantage of this transformation feature. This article also assumes familiarity with Rational Application Developer's JSF page designer.


Installing the XSD SDO Transform feature

  1. Unzip the xsdsdotransform-feature.zip download file into your Rational Application Developer installation's rad\eclipse directory (for example, D:\IBM\RSDP\6.0\rad\eclipse).
  2. Start Rational Application Developer (hereafter referred to as Application Developer).
  3. Select Help => Software Updates => Manage Configuration (Figure 1).
    Figure 1. Feature install
    Figure 1. Feature install
  4. Enable the XSD SDO Transform Feature as shown in Figure 2, then restart Application Developer.
    Figure 2. Feature install
    Figure 2. Feature install
    You may ensure the configuration updates for the feature by starting Application Developer with -clean command line argument.

XSD SDO Transform feature contents

The XSD SDO Transform feature contains artifacts for generating the SDO package from an XSD schema, and framework components to transform an SDO package instance to/from an XML instance document:

  1. Create SDO Package Action
    This action on the XSD resources generates the SDO package from an XSD schema (Figure 3).
    Figure 3. Create SDO Package
    Figure 3. Create SDO Package
  2. dw.ibm.etools.xsd.sdo.xmltransformservice.XMLTransformServiceFactory class
    This class provides the APIs to transform an SDO package instance to/from an XML instance document. (XMLTransformServiceFactory.java code is available in the xsd_sdo_soa_part1_listings.zip download file.)

Scenario

We will develop a simple insurance application scenario that illustrates the master-detail view, sorting, and paging functionality. In this scenario:

  • We assume that XYZ Insurance Comany has many brokers registered to it.
  • Each broker has many clients, and each client has many policies registered with that broker.
  • The insurance company exposes broker services via a standard BrokerService schema.
  • Any communication from the broker is an XML request/response that complies to the schema definition in Listing 1. (BrokerService.xsd code is also available in the xsd_sdo_soa_part1_listings.zip download file.)

Listing 1. BrokerService.xsd

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns="http:///xyz.brokerservice.ecore"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
	targetNamespace="http:///xyz.brokerservice.ecore">
	<xsd:annotation>
		<xsd:documentation xml:lang="en">
   			Broker Service Schema for xyz.com.
   			Copyright 2004 ibm.com. All rights reserved.
  		</xsd:documentation>
	</xsd:annotation>
	<xsd:element name="brokerService" type="brokerServiceType"/>
	<xsd:complexType name="brokerServiceType">
		<xsd:sequence>
			<xsd:element minOccurs="0" name="broker" type="brokerType"/>
			<xsd:element minOccurs="0" name="error" type="errorType"/>
		</xsd:sequence>
	</xsd:complexType>
	<xsd:complexType name="brokerType">
		<xsd:sequence>
			<xsd:element minOccurs="0" ref="firstName"/>
			<xsd:element minOccurs="0" ref="lastName"/>
			<xsd:element minOccurs="0" name="loginName" type="xsd:string"/>
			<xsd:element minOccurs="0" name="loginPassword" type="xsd:string"/>
			<xsd:element maxOccurs="unbounded" minOccurs="0" name="client" 
				type="clientType"/>
		</xsd:sequence>
		<xsd:attribute name="brokerId" type="xsd:string" use="required"/>
	</xsd:complexType>
	<xsd:complexType name="clientType">
		<xsd:sequence>
			<xsd:element minOccurs="0" ref="firstName"/>
			<xsd:element minOccurs="0" ref="lastName"/>
			<xsd:element minOccurs="0" name="dateOfBirth" 
				type="xsd:date"/>
			<xsd:element minOccurs="0" name="currentAddress" 
				type="addressType"/>
			<xsd:element minOccurs="0" name="permanentAddress" 
				type="addressType"/>
			<xsd:element maxOccurs="unbounded" minOccurs="0" name="policy" 
				type="policyType"/>
		</xsd:sequence>
		<xsd:attribute name="clientId" type="xsd:string" use="required"/>
	</xsd:complexType>
	<xsd:complexType name="addressType">
		<xsd:sequence>
			<xsd:element name="street" type="xsd:string"/>
			<xsd:element name="city" type="xsd:string"/>
			<xsd:element name="state" type="xsd:string"/>
			<xsd:element name="zip" type="xsd:string"/>
			<xsd:element name="country" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>
	<xsd:complexType name="policyType">
		<xsd:sequence>
			<xsd:element name="policyName" type="xsd:string"/>
			<xsd:element name="policyStartDate" type="xsd:date"/>
			<xsd:element name="policyEndDate" type="xsd:date"/>
			<xsd:element name="policyAmount" type="xsd:string"/>
			<xsd:element name="policyDescription" type="xsd:string"/>
		</xsd:sequence>
		<xsd:attribute name="policyId" type="xsd:string" use="required"/>
	</xsd:complexType>
	<xsd:complexType name="errorType">
		<xsd:sequence>
			<xsd:element name="errorCode" type="xsd:string"/>
			<xsd:element name="errorDescription" type="xsd:string"/>
		</xsd:sequence>
	</xsd:complexType>
	<xsd:element name="firstName" type="xsd:string"/>
	<xsd:element name="lastName" type="xsd:string"/>
</xsd:schema>
Figure 4. BrokerService Schema Model
Figure 4. BrokerService Schema Model

In this scenario, we develop a brokerdetail.jsp JavaServer Faces JSP page. This page sends the broker detail request (brokerDetailRequest.xml, Listing 2) and receives a response containing all the broker's clients and their policies (brokerDetailResponse.xml, Listing 3). One client's details are displayed per page and policies can be sorted by name.

Figure 5. BrokerDetail Request/Response Message Flow
Figure 5. BrokerDetail Request/Response Message Flow

(The code shown in Listings 2 and 3 are also available in the xsd_sdo_soa_part1_listings.zip download file.)

Listing 2. brokerDetailRequest.xml

<brokerService xmlns="http:///xyz.brokerservice.ecore" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<broker  brokerId="099-99-9999">
<loginName>narinder</loginName>
<loginPassword>makin</loginPassword>
</broker>
</brokerService>

Listing 3. brokerDetailResponse.xml

<brokerService xmlns="http:///xyz.brokerservice.ecore" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
<broker brokerId="000-00-9999">
	<firstName>Narinder</firstName>
	<lastName>Makin</lastName>
	<client clientId="001-00-9999">
		<firstName>Dan</firstName>
		<lastName>Moore</lastName>
		<dateOfBirth>1967-08-13</dateOfBirth>
		<currentAddress>
			<street>113 Oak Pine St.</street>
			<city>Santa Clara</city>
			<state>LA</state>
			<zip>91929</zip>
			<country>US</country>
		</currentAddress>
		<permanentAddress>
			<street>123 Demi Lane</street>
			<city>Cary</city>
			<state>NC</state>
			<zip>22999</zip>
			<country>US</country>
		</permanentAddress>
		<policy policyId="L000000000">
			<policyName>Life</policyName>
			<policyStartDate>2004-01-01</policyStartDate>
			<policyEndDate>2005-01-01</policyEndDate>
			<policyAmount>100000.00</policyAmount>
			<policyDescription>Life Insurance policy includes any 
				accidental damages.</policyDescription>
		</policy>
		<policy policyId="H000000000">
			<policyName>House</policyName>
			<policyStartDate>2004-01-01</policyStartDate>
			<policyEndDate>2005-01-01</policyEndDate>
			<policyAmount>50000.00</policyAmount>
			<policyDescription>Home Insurance</policyDescription>
		</policy>
		<policy policyId="C000000001">
			<policyName>Car 1</policyName>
			<policyStartDate>2004-01-01</policyStartDate>
			<policyEndDate>2005-01-01</policyEndDate>
			<policyAmount>15000.00</policyAmount>
			<policyDescription>Car Insurance - Ferrari 2004 - Primary 
				Car </policyDescription>
		</policy>
		<policy policyId="C000000002">
			<policyName>Car 2</policyName>
			<policyStartDate>2004-01-01</policyStartDate>
			<policyEndDate>2005-01-01</policyEndDate>
			<policyAmount>5000.00</policyAmount>
			<policyDescription>Car Insurance - Lexus 2003 - Secondary 
				Car </policyDescription>
		</policy>
		<policy policyId="B000000002">
			<policyName>Restaurant</policyName>
			<policyStartDate>2004-01-01</policyStartDate>
			<policyEndDate>2005-01-01</policyEndDate>
			<policyAmount>25000.00</policyAmount>
			<policyDescription>Business Insurance - Restaurant
				</policyDescription>
		</policy>
	</client>
	<client clientId="002-00-9999">
		<firstName>Tom</firstName>
		<lastName>Cross</lastName>
		<dateOfBirth>1970-11-11</dateOfBirth>
		<currentAddress>
			<street>113 Duke St.</street>
			<city>Shelton</city>
			<state>CT</state>
			<zip>08989</zip>
			<country>US</country>
		</currentAddress>
		<permanentAddress>
			<street>123 Lex Lane</street>
			<city>Fairfield</city>
			<state>NY</state>
			<zip>09833</zip>
			<country>US</country>
		</permanentAddress>
		<policy policyId="H100000000">
			<policyName>House</policyName>
			<policyStartDate>2004-01-01</policyStartDate>
			<policyEndDate>2005-01-01</policyEndDate>
			<policyAmount>2000.00</policyAmount>
			<policyDescription>Home Insurance</policyDescription>
		</policy>
		<policy policyId="L100000000">
			<policyName>Life</policyName>
			<policyStartDate>2004-01-01</policyStartDate>
			<policyEndDate>2005-01-01</policyEndDate>
			<policyAmount>100000.00</policyAmount>
			<policyDescription>Life Insurance</policyDescription>
		</policy>
		<policy policyId="C100000001">
			<policyName>Car 1</policyName>
			<policyStartDate>2004-01-01</policyStartDate>
			<policyEndDate>2005-01-01</policyEndDate>
			<policyAmount>2000.00</policyAmount>
			<policyDescription>Car Insurance - Camry 2004 - Primary 
				Car </policyDescription>
		</policy>
	</client>
</broker>
</brokerService>

Application design flow

Figure 6 depicts the application design flow for this scenario.

Figure 6. Application design flow
Figure 6. Application design flow

Runtime architecture

Upon page request, the following occurs (Figure 7):

  1. The JSF runtime invokes the BrokerDetailRoot bean.
  2. BrokerDetailRoot preloads the data by sending brokerDetailRequest.xml to the BrokerService.
  3. BrokerService sends the response as brokerDetailResponse.xml.
  4. The response received from the broker service invocation, as brokerDetailResponse.xml, is passed to XMLTransformServiceFactory.
  5. The XML is transformed to SDOs wrapped in the BrokerDetailRoot bean.
  6. The bean is processed by the JSF runtime.
  7. The JSF runtime renders the controls with populated data.
Figure 7. Runtime architecture
Figure 7. Runtime architecture

Implementing the solution

The steps to implement the solution are described in detail in the next sections:

  1. Import project interchange
  2. Create SDO package from XSD schema
  3. Create a base root Java bean
  4. Create a broker service root Java bean
  5. Create a JSF JSP
  6. Add the page BrokerDetailRoot bean to paga data
  7. Add command method to page code
  8. Create and Bind controls on the page to the SDO types in the page data
  9. Run brokerdetail.jsp.
  1. Import project interchange

    Import the project interchange xsd_sdo_soa_xml_tutorial.zip download file into the Application Developer workspace. As a result, the following projects will be imported (Figure 8):

    • XYZInsuranceEAR: The enterprise application project that contains all the other projects as modules or utilities.
    • XYZInsuranceWeb: The dynamic Web project for the application where all the JSF JSP pages will be created. The WebContent folder of this project contains the BrokerService.xsd schema and sample data files in a Schema folder. For the sake of simplicity, in this example the schema and the SDO packages are part of the WebProject. If sharing the same SDOs across multiple Web projects is desired, you can create a separate Java project for the SDO packages. The SDO packages are constructed in the same project where the XML Schema resides.
    • XYZInsuranceService: Contains the Java class implementation for the broker service. The service loads and sends the appropriate XML response based on the service method request. This basic implementation is provided to simulate the service behavior; its implementation is beyond the scope of this article.
    • XYZInsuranceServiceProxy: Contains a basic implementation of ServiceProxy for invoking the broker service.

    The next sections describe the additions to the XYZInsuranceWeb project.

    Figure 8. Imported tutorial project interchange
    Figure 8. Imported tutorial project interchange
  2. Create SDO package from XSD schema

    In Application Developer, right-click on BrokerService.xsd, then select Create SDO Package (Figure 9).

    Figure 9. Create SDO Package
    Figure 3. Create SDO Package

    As a result, the following artifacts will be generated (Figure 10):

    • The xyz.brokerservice, xyz.brokerservice.impl, and xyz.brokerservice.util Java packages that contain the SDOs and related utilities that are constructed for the types defined in the XSD schema.
    • A framework JAR file, xsdsdotransform.jar, is added to the EAR project and the Web project's JAR dependencies are updated accordingly for the build and runtime classpath.
    Figure 10. Generated SDO Packages
    Figure 10. Generated SDO Packages

    The name of the package is derived from the targetNamespace defined in the schema declaration in the XSD (Figure 11).

    Figure 11. TargetNamespace declaration
    Figure 11. TargetNamespace declaration
  3. Create a base root Java bean

    Create a BaseBrokerServiceRoot.java (available in the xsd_sdo_soa_part1_listings.zip download file) Java class in the brokerservice.root package to be used as the base class for all the page root bean wrappers. The schema namespace to the SDO package registration is done in the static block. At run time, the namespace of the XML instance document is examined to locate the related SDO package from this registry:

    static{
    	EPackage.Registry.INSTANCE.put(
    		BrokerservicePackage.eINSTANCE.getNsURI()
    		, BrokerservicePackage.eINSTANCE);
    }
  4. Create a broker service root Java bean

    Create a BrokerDetailRoot.java (available in the xsd_sdo_soa_part1_listings.zip download file) Java class to be used as a bean wrapper for the BrokerDetail.jsp page. This bean wraps the SDO packages and enables the SDO package usage as a Java bean in the page data. It also contains methods for preLoading the bean via the response received from the service invocation on request:

    1. create method
      In this example, this method simply returns an XML request string, but could be coded to invoke a request creator service (for example, one that adds appropriate header information to the XML request as required by the service for the purpose of auditing, and so on).

      protected String createBrokerDetailRequest(){
      	String request = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>
      		<brokerService mlns=\"http:///xyz.brokerservice.ecore\"
      		xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\">
      		<broker brokerId=\"099-99-9999\"><loginName
      			>narinder</loginName>
      		<loginPassword>makin</loginPassword></broker>
      			</brokerService>";
      	//you may also use the create/convert API to create a new request string
      	/*DocumentRoot docRoot = (DocumentRoot)
      		XMLTransformServiceFactory.INSTANCE.create(BrokerservicePackage.
      			eINSTANCE.getNsURI());
      	BrokerServiceType bs = docRoot.createBrokerService();
      	xyz.brokerservice.BrokerType b = bs.createBroker();
      	b.setBrokerId("099-99-9999");
      	b.setLoginName("narinder");
      	b.setLoginPassword("makin");
      	request = XMLTransformServiceFactory.INSTANCE.convert((DataObject)b);
      	*/
      	return request;
      }
    2. load method
      Invokes the XMLTransformServiceFactory methods to transform the broker detail response XML into the SDOs.

      protected void loadBrokerDetailResponse(String response){
      
      	DocumentRoot docRoot=
      	  (DocumentRoot) XMLTransformServiceFactory.INSTANCE.load(response);
      	brokerServiceRoot =  docRoot.getBrokerService();
      }
    3. preload method
      Invokes the service with the request and processes the response.

      protected void preLoadBrokerDetail(){
          String xmlData = createBrokerDetailRequest();
          String response =
          	BrokerServiceFactory.invoke(xmlData,
      		BrokerServiceFactory.BROKERDETAIL_REQUEST);
          loadBrokerDetailResponse(response);
      }
    4. sortByPolicyName method
      Sorts the policies by name in the policies collection.

      public void sortByPolicyName(List listPolicies){
      	ObjectUtil.INSTANCE.sort(listPolicies,
      		BrokerserviceFactory.eINSTANCE,
      		BrokerservicePackage.eINSTANCE.getPolicyType_PolicyName(),
      		true);
      }
    5. dw.ibm.etools.xsd.sdo.xmltransform.util.ObjectUtil helper class
      Provided with the framework code to sort the list.

      /**
       * Sorts the Objects in the list
       * @param list the instance of the EList containing EObjects
       * @param eFactory the instance of the SDO factory
       * @param sortBy the EAttribute to be used for sorting
       * @param desc true for descending sort, false for ascending
       * @return true if the order of objects in list is changed
       */
      public  boolean sort(List list, EFactory eFactory
      	, EAttribute sortBy, boolean desc);
  5. Create a JSF JSP

    Create a JavaServer Faces JSP file as brokerdetail.jsp

    1. In Application Developer, open the Web site Navigation, drop a new page from the palette, and rename it as brokerdetail.jsp.
      Figure 12. Web site Navigation
      Figure 12. Web Site Navigation
    2. Double-click on the page and realize it as a Faces JSP.
      Figure 13 brokerdetail.jsp
      Figure 13 brokerdetail.jsp
  6. Add the page BrokerDetailRoot bean to paga data

    The BrokerDetailRoot bean wraps the SDO classes that were generated from the XSD. The Java bean is introspected, and the page data shows the SDO types and the attributes and references as a tree. To add the root bean to the page data:

    1. Right-click in the Page Data view and add a new Java Bean by selecting New => JavaBean (Figure 14).
      Figure 14. New java bean menu in page data view
      Figure 14. New java bean menu in page data view
    2. In the Add JavaBean dialog (Figure 15), enter the name of the JavaBean instance to be used as a variable, varBrokerDetailRootBean.
      Figure 15. Java bean properties
      Figure 15. Java bean properties
    3. Select Finish. The new bean will display in the Page Data view (Figure 16).
      Figure 16. BrokerServiceRoot java bean
      Figure 16. BrokerServiceRoot java bean
  7. Add command method to page code

    Edit the BrokerDetail.java page code file and add the method below to be used as the command action's method. This action invokes the sortByPolicyName method on the page root bean to sort the displayed data for the policy by name. (The table2 control being accessed is added in the next section.) You can create a param scope variable for the policy list and use that rather than accessing the list from the table control.

    public String doSortByPolicyNameAction(){
    	//table2 is the policy data table
    	//you may choose to add a param scope variable
    	//for policy list, instead of using the table control
    	getVarBrokerDetailRootBean().sortByPolicyName
    		((java.util.List)getTable2().getValue());
    	// returning empty string re-displays the same page with same data binding
    	return "";
    }
  8. Create and bind controls on the page to the SDO types in the page data

    You can project the root data to the page and let the page editor create the controls for you based on the type of the data being projected, or you can drop the individual controls and bind the data elements yourself. For the sake of simplicity, we will use the page editor to create the controls. A data table is created and binded for each of the SDO types, and output text fields are created and binded for each of the attributes and single valued reference in these types. For each of the multi values referenced, a nested data table is created and binded.

    1. Drag the broker SDO from the page data view and drop it onto the page editor (Figures 17 and 18).
      Figure 17. Broker SDO
      Figure 17. Broker SDO
      Figure 18. Page Designer
      Figure 18. Page Designer
    2. The Depth property determines the depth for the creation of nested table controls. Customize the table properties by setting the depth to 5 (Figure 19).
      Figure 19. Data table properties
      Figure 19. Data table properties
    3. Specify the data type for the "client" list (Figure 20). You will need to provide the data type for each of the list attributes if you will be binding them to any control on a page.
      Figure 20. Object type for client collection
      Figure 20. Object type for client collection
    4. Customize the broker's projected attributes by deselecting the clientAsArray attribute (Figure 21).
      Figure 21. Customize broker projections
      Figure 21. Customize broker projections
    5. Click on the ellipses ... that display after the the client attribute (Figure 21) and specify the data type for the "policy" list (Figure 22).
      Figure 22. Object type for policy collection
      Figure 22. Object type for policy collection
    6. Customize "client" projected attributes and deselect the policyAsArray attribute (Figure 23).
      Figure 23. Customize client projections
      Figure 23. Customize client projections
    7. Select Finish. The page controls are created and binded to the elements of the root bean (Figure 24).
      Figure 24. Created controls
      Figure 24. Created controls
    8. Add a paging control of your choice to the client data table and set the rows per page to be displayed at 1 (Figures 25 and 26).
      Figure 25. Display options
      Figure 25. Display options
      Figure 26. Paging control addition
      Figure 26. Paging control addition
    9. Add a command button to the Policy data table and change the label of the button to be SortByPolicyName (Figure 27). Enable the showing of the footer area for the policy data table so that you can place the command button (Figure 28).
      Figure 27. Command button
      Figure 27. Command button
      Figure 28. Command button addition
      Figure 28. Command button addition
    10. Bind this command button to doSortByPolicyNameAction (Figure 29). If the "action" property is not being displayed, then show all the properties for the data table.
      Figure 29. Bind command to action
      Figure 29. Bind command to action
      The sorting mechanism demonstrated here does a server side sort by invoking a command action. Based on your requirements, you can choose to do a client side implementation for the sort.
  9. Run brokerdetail.jsp
    1. In Application Developer, right-click on brokerdetail.jsp and select Run On Server. (If you are not prompted to start the server, start the server and then add the XYZInsuranceEAR project to the server before running the page.)
    2. The URL for the page in the test container is (or will be similar to): http://localhost:9080/XYZInsuranceWeb/faces/brokerdetail.jsp.
      Figure 30. brokerdetail.jsp
      Figure 30. brokerdetail.jsp
    3. Use the paging control to page for clients.
    4. Select the SortByPolicyName command to sort the policies by name.

Conclusion

In Part 1 of this article series, we presented an accelerated JSF development solution for a XML-based SOA application. The solution provided an Eclipse feature and framework utilities for use at design time to transform the XML Schema to a Java package containing static service data objects, and, at runtime, to transform XML instance documents to and from these SDOs. SDOs wrapped as JavaBeans were used with JavaServer Faces for presentation development. This article also provided the general steps for developing a JSF presentation for a basic scenario of an insurance application, including master-detail view, sorting, and pagination capabilities.

Part 2 of this series enhances the solution developed in Part 1 to include the create, update, and delete functions, and includes customizations to the generated SDOs with local variable addition and basic transformations. The article will illustrate a scenario of multiple schema models, multiple requests/responses for a single page, and will show the JSF dropdown control binding for XML data.

Also upcoming in this series:

  • Part 3 will describe the advanced techniques for manipulating the generated SDOs and customizing the XML-SDO transformer. It also provides utilities for the aggregate methods (sum, mean, average, and so on) that operate generically on the SDO objects and collections.
  • Part 4 will focus on portlet development for the XML-based SOA that uses the XSDO SDO transform feature, addressing JSR 168 portlet creation, parameter passing across portlets, and setting the target portlet view dynamically on a portlet action in any other portlet.
  • Part 5 will discuss localizing JSF and portlet applications for the XML-based SOA that uses the XSDO SDO transform feature, and will address the localizing static and dynamic content that is displayed based on the preferred locale.

Downloads

DescriptionNameSize
Download file 1xsd_sdo_soa_xml_sample.zip  ( HTTP | FTP )727 KB
Download file 2xsd_sdo_soa_xml_tutorial.zip  ( HTTP | FTP )685 KB
Download file 3xsdsdotransform-feature.zip  ( HTTP | FTP )727 KB
Download file 4XYZInsuranceEAR.zip  ( HTTP | FTP )725 KB
Download file 5xsd_sdo_soa_part1_listings.zip  ( HTTP | FTP )8 KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Rational
ArticleID=99384
ArticleTitle=IBM WebSphere Developer Technical Journal: Accelerated JSF development for XML-based SOA using Rational Application Developer and WebSphere Application Server -- Part 1
publish-date=12012004