You can develop a Service Component Architecture (SCA) service implementation when starting with an existing Web Services Description Language (WSDL) file.
Locate the WSDL file that defines the SCA service that you want to implement. You can develop a WSDL file or obtain one from an existing SCA service. The WSDL file describes your service interface as a WSDL portType and includes XSD schema definitions of your business data.
The product supports Web Services Description Language (WSDL) Version 1.1 definitions that also conform to the WS-I Basic Profile Version 1.1 and Simple SOAP Binding Profile 1.0 standards, and use the document literal style. All these conditions are required for support.
The top-down development approach takes advantage of the interoperable XML-based WSDL, and XSD interface and data definitions.
This task describes the steps when using the top-down development approach to develop an SCA service implementation in Java when starting from a WSDL interface and XSD data definitions.
Use the wsimport command-line tool to generate the Java representations of your business service interfaces and your business data when an existing WSDL file describes the wanted SCA service interface as a WSDL portType, along with XSD schema definitions of your business data. The wsimport tool generates Java classes that you can use to write a Java implementation that reflects your business logic. The result is a Plain Old Java Object (POJO) implementation of the generated interface using the generated JAXB data types. By adding the @Service annotation to the Java implementation, the annotation defines the Java implementation as an SCA service implementation.
The generated annotated Java classes that correspond to your business data contain all the necessary information that the JAXB runtime environment requires to build and parse the XML for marshaling and unmarshaling. In other words, the data programming model is limited to object instantiation and the use of getter and setter methods, and you do not need to write code to convert the data between the XML wire format and the Java application.
When you develop an SCA service when starting from an existing WSDL file, the interface is considered a remotable interface. The remotable interface uses pass-by-value semantics, which implies your data is copied.
You can use and deploy the resulting Java implementation as an SCA component that is defined in a composite definition. The composite definition defines SCA artifacts, such as service references, imports, and exports. The component is defined in terms of development artifacts such as the WSDL, the Java implementation, and bindings that are defined during deployment.
The JAXB APIs require that you register Java class types that you want to marshal or unmarshall with a JAXBContext class. The product runtime environment registers these Java class types for you by introspecting your Java interface. When this introspection occurs, be careful of possible problems when polymorphism (inheritance) is used. When an interface is defined in terms of a base superclass type, and you want to pass argument instances of a derived subclass type at run time, the subclasses are not known to the JAXBContext class by simply introspecting the interface parameter types.
In JAXB, you can use the javax.xml.bind.annotation.XmlSeeAlso annotation to solve this problem with polymorphism. Place the @XmlSeeAlso annotation on the generated Java interface that is generated with the @WebService annotation, to refer to additional JAXB derived subclass classes that are added to the JAXBContext class along with those classes introspected from the interface parameters.
You have created an SCA implementation by starting with an existing WSDL file.
The following example illustrates using an existing WSDL interface to generate a Java interface that is used to create a Java implementation that is an SCA service.
<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:account="http://www.myaccount.com/account" targetNamespace="http://www.myaccount.com/account" name="AccountService"> <wsdl:types> <schema targetNamespace="http://www.myaccount.com/account" xmlns="http://www.w3.org/2001/XMLSchema" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:account="http://www.myaccount.com/account"> <element name="computeAccountAverage"> <complexType> <sequence> <element name="account" type="account:Account" /> <element name="days" type="xsd:int" /> </sequence> </complexType> </element> <element name="computeAccountAverageResponse"> <complexType> <sequence> <element name="return" type="xsd:float" /> </sequence> </complexType> </element> <complexType name="Account"> <attribute name="accountNumber" type="xsd:int" /> <attribute name="accountID" type="xsd:string" /> <attribute name="accountType" type="xsd:string" /> <attribute name="balance" type="xsd:float" /> </complexType> </schema> </wsdl:types> <wsdl:message name="computeAccountAverageRequest"> <wsdl:part element="account:computeAccountAverage" name="parameters" /> </wsdl:message> <wsdl:message name="computeAccountAverageResponse"> <wsdl:part element="account:computeAccountAverageResponse" name="parameters" /> </wsdl:message> <wsdl:portType name="AccountService"> <wsdl:operation name="computeAccountAverage"> <wsdl:input message="account:computeAccountAverageRequest" name="accountReq"/> <wsdl:output message="account:computeAccountAverageResponse" name="accountResp"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="AccountServiceSOAP" type="account:AccountService"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http" /> <wsdl:operation name="computeAccountAverage"> <soap:operation soapAction="computeAccountAverage" /> <wsdl:input name="accountReq"> <soap:body use="literal" /> </wsdl:input> <wsdl:output name="accountResp"> <soap:body use="literal" /> </wsdl:output> </wsdl:operation> </wsdl:binding> <wsdl:service name="AccountWSDLService"> <wsdl:port binding="account:AccountServiceSOAP" name="AccountServicePort"> <soap:address location=""/> </wsdl:port> </wsdl:service> </wsdl:definitions>
app_server_root\bin\wsimport.bat -keep -verbose account.wsdl
com/myaccount/account/Account.java com/myaccount/account/AccountService.java com/myaccount/account/AccountWSDLService.java com/myaccount/account/ComputeAccountAverage.java com/myaccount/account/ComputeAccountAverageResponse.java com/myaccount/account/ObjectFactory.java com/myaccount/account/package-info.java
// // Generated By:JAX-WS RI IBM 2.1.1 in JDK 6 (JAXB RI IBM JAXB 2.1.3 in JDK 1.6) // package com.myaccount.account; ... @WebService(name = "AccountService", targetNamespace = "http://www.myaccount.com/account") … public interface AccountService { /** * * @param days * @param account * @return * returns float */ @WebMethod(action = "computeAccountAverage") @WebResult(targetNamespace = "") @RequestWrapper(localName = "computeAccountAverage", targetNamespace = "http://www.myaccount.com/account", className = "com.myaccount.account.ComputeAccountAverage") @ResponseWrapper(localName = "computeAccountAverageResponse", targetNamespace = "http://www.myaccount.com/account", className = "com.myaccount.account.ComputeAccountAverageResponse") public float computeAccountAverage( @WebParam(name = "account", targetNamespace = "") Account account, @WebParam(name = "days", targetNamespace = "") int days); }
This code example is a Java interface, not merely a Java class. The @WebService annotation is present in this Java interface. It is important to know that this example is not the same as the generated @WebServiceClient class, com.myaccount.account.AccountWSDLService, which is not an interface and is not needed in your SCA application.
package com.myaccount.account; import org.osoa.sca.annotations.Service; @Service(AccountService.class) public class AccountServiceImpl implements AccountService public float computeAccountAverage( Account account, int days) { // Write your business logic here. Account is a // generated JAXB type and so use the JAXB programming model. // For example, object instantation is performed using // the ObjectFactory.createAccount()) method. } }
By completing this step, you have completed a component implementation. Not only is this component implementation a Java implementation of a Java interface, but the @Service annotation signifies that this is a Java component implementation of an SCA service interface. The implementation class itself does not need all the JAX-WS or JAXB annotations. The runtime environment loads the appropriate annotations from the generated classes that the implementation refers to.
<?xml version="1.0" encoding="UTF-8"?> <composite xmlns="http://www.osoa.org/xmlns/sca/1.0" targetNamespace="http://account.customer" name="accountComposite"> <component name="BankingComponent"> <implementation.java class="com.myaccount.account.AccountServiceImpl"/> <!-- The @name value matches the contents of the @Service which in turn comes from the WSDL portType. --> <service name="AccountService"> <!-- This statement specifies the QName of the WSDL portType, “http://www.myaccount.com/account#AccountService” in the syntax as illustrated in the interface.wsdl statement. --> <interface.wsdl interface="http://www.myaccount.com/account#wsdl.interface(AccountService)" /> <binding.ws/> <!-- This example uses the SCA web services binding. However, it does not matter which SCA binding you choose. --> </service> </component> </composite>
In this information ...Related concepts
Related tasks
| IBM Redbooks, demos, education, and more(Index) |