Creating a Web service using PowerDesigner 9.5

web| Create
Creating a Web service using PowerDesigner 9.5



PowerDesigner, chief designer of Sybase company, Xiao Wang



WEB services allow you to provide existing or new functionality in a standard format, and allow users and applications to access them from any location.

PowerDesigner 9.5 also introduces a sophisticated WEB service design and generation mechanism for Microsoft. NET and Java. With PowerDesigner 9.5, you can focus on the design of the Web service and hand over all the necessary build, implementation-constructed tasks to PowerDesigner.


WEB Services Overview
A WEB service is an interface that describes the set of operations that can be accessed through a SOAP message on a network.



The interface and deployment location of the WEB service (optional) is described by the WSDL. WSDL is an XML document that declares the data type, message, port type, and port (optional). The WSDL allows the user to know which format SOAP message should be sent to invoke the Web service and to return the format of the message.



To enable users to find the required WEB services, the service provider may publish the WSDL document in the UDDI enrollment service. This allows users to use the UDDI enrollment service to search for WEB services.



To invoke a Web service, a user can send a SOAP message to the access point URL where the Web service is deployed, or use a proxy class that simplifies this calling procedure. SOAP messages are also XML documents.


PowerDesigner Web Services Features
PowerDesigner 9.5 allows you to create a new Web service component, reverse-engineer the WSDL for creating Web service components, browse UDDI, search for WSDL, generate WSDL from the definition of a Web service component, build. NET (C # and VB. NET), server-side code that generates. NET, client-side code that generates Java (JAX-RPC and JAXM), and client proxies that generate Java.



To design a WEB service component, PowerDesigner uses UML class diagrams, component diagrams, and deployment diagrams. A Web service is represented by a component of a component diagram, and the deployed Web service is represented by a component instance of the deployment diagram.


Creating a Web Service component
There are five steps to creating a Web service component. The first is to create an object-oriented model (OOM). You can choose any of the following languages: C #, Visual Basic. NET, or Java. The Extended model definition (Xem) for WSDL is automatically appended to this model. Xem defines the build template and extended properties of the WSDL.



The second step is to create the class. It is best to create a program group (Package) before creating a class under this program group.



The third step is to use the Web Service Wizard to convert the created class into a Web service component. To do this, you can right-click the class and select the Create Web Service component command, or select the Tools > Create Web Service Components command when the class is selected. Figure 1 shows an example of a Web Service wizard. A WEB service type can be an interface or an implementation. If you select interface, you will only want to define this WEB component and generate the corresponding WSDL. For. NET, this component type is standard and its WEB service is implemented through the. asmx file. For Java, this component type may be standard, service program, or stateless session Bean. The implementation methods for these types of Java components are: The standard type uses JAXM with Jax-RPC, the service program type, and the stateless session Bean type uses the Java EE (JSR109) WEB service specification. When the wizard ends, a component and class are created. Figure 2 shows an example of a component symbol in a component diagram.





Figure 1 Web Service Wizard





Figure 2 Component symbols



The fourth step is to add a Web method. You need to create a new action (Operation), open the property page for the action, click the Web methods check box, define parameters and return types, and write the implementation code for the operation. Figure 3 shows an implementation example of the Web method Getstockquote.





Figure 3 Implementation Example for Web method Getstockquote



The final step is to customize the WSDL generation. You can customize the WSDL data type for parameters and return values, the extended properties of the operation, and the properties and extended properties of the component. To verify the generated WSDL, you can open the WSDL tab of the component's property page. The task of generating the WSDL can be delivered to PowerDesigner or defined by you (user-defined). If the Web service component originates from the reverse engineering of the WSDL, the original WSDL is preserved. Figure 4 shows an example of a generated WSDL.





Figure 4 Example of the WSDL generated



You can preview the generated implementation code in the Preview tab of the Class property page.



You can use deployment diagrams, nodes, and component instances to built WEB service components that have already been deployed. In addition, you can define the URL of the server in node and the URL of the service in the component instance.


Reverse-Engineer The WSDL
The WSDL can define only the Web service interface or the URL of the interface and access point. Web Service Interfaces may be used by multiple service providers to provide the same services, and of course, these services will have different implementations and access points. If you have a file path or URL for a WSDL document, you can reverse-engineer it to create a Web service component, and then you can define your own implementation methods or save the created Web service components in a library for later use. When you look for the WSDL you are interested in, you can use a UDDI browser to search in the UDDI registration service.



In order to reverse-engineer WSDL, you need to create a OOM with any language in C #, VB. NET, or Java. Then select the language > Import WSDL command and enter the path or URL of the WSDL file. After reverse engineering, a component is created in the component diagram, and a class is created in the class diagram. The class you create will only contain the operating signal for that Web service, and you need to define the implementation code for those operations if you want to implement the Web service.


Searching for WSDL in the UDDI registration service
If you want to search for the WSDL registered in the UDDI Registration service, open the Import WSDL window, and then click the Browse UDDI button. The Browse UDDI window (see Figure 5) allows you to select a UDDI operator, search criteria, and search type, and you can search by entity name, service name, or WSDL name. In addition, you can preview the WSDL found.





Figure 5 The "Browse UDDI" window


Generate a. NET type of WEB service
For. NET server-side code, PowerDesigner generates an. asmx file. The implementation class for this WEB service can be generated in the above. asmx file, or externally. The language used by this implementation class can be C # or VB. NET. On the preview tab of the Class property page, you can preview the. asmx file and the corresponding implementation class code. Figure 6 shows an example of the. asmx file for the C # language.





Figure 6 Example of the. asmx file in the C # language



PowerDesigner can also generate client proxy classes to simplify the invocation of WEB services. To generate the client proxy class, PowerDesigner uses the Wsdl.exe program that is included with Visual Studio. NET.



To generate WSDL, server-side code, and/or client proxies, select either the language > generate C # code or the language > Generate VB. NET code command. If you are building a client agent, you can select the Generate WEB service client proxy option on the Tasks tab. Figure 7 shows the available build tasks. If this class is not built within the. asmx file, you will be able to compile the C # code or VB. NET code. However, when compiling a C # or VB. NET file, you must define a CSC or VBC variable to indicate the location of the csc.exe or vbc.exe command.



When you deploy a WEB service, you only need to copy the. asmx file and the corresponding class file under the IIS directory:c:\inetpub\wwwroot\< the program group name >. Where the,< program group name > is the name of the program group. To test this WEB service, you can enter the following url:http://< host name >/< program group name >/< service name in the browser >.asmx





Figure 7 Web Service Build task


Generating Java-type WEB Services
If the implementation type of the WEB service is "standard", PowerDesigner will use JAX-RPC to implement it. If the implementation type is "service program", PowerDesigner will use JAXM to implement it. If the implementation type is a stateless session Bean, then PowerDesigner will use the Java EE (JSR109) WEB service specification. JSR109 has not yet been formally promulgated.



JAX-RPC defines a WEB service invocation of RPC type. Although it is easy to develop and use, it can only be limited to simple message formats in order to avoid complex object/xml mappings. The JAXM Web Services component is obviously more advantageous, and it allows you to handle complex message structures flexibly.



To use JAX-RPC or JAXM, you need to install the Java Web Services Developer Pack (JWSDP). This package can be downloaded from Sun Company's website. When you deploy a JAX-RPC or JAXM type of WEB service component, you need a server that supports Jax-RPC or JAXM. Support for Jax-RPC or JAXM Apache Tomcat comes with the JWSDP.



For Jax-RPC based Web service components, you only need to implement the code for their Web methods. To generate WSDL, server-side code, and/or client proxies, select language > Generate Java Code, and then select the Use the XRPCC tool to generate WSDL (server-side) and/or proxy code to generate WEB services using the XRPCC tool (see Figure 8). The XRPCC command is a tool for JWSDP. It can generate either a JAX-RPC type of server-side code or a client proxy. When you deploy a generated WEB service, you need to create a that contains all the build files. WAR file, and put this. The WAR file is deployed on a JAX-RPC-enabled server, such as Apache Tomcat.





Figure 8 JAX-RPC Build task



For JAXM Web service components, you need to implement their onMessage operations. The onMessage operation will receive and process the input SOAP message and build the return message, as indicated in the WSDL, and return the message. To generate a WSDL and JAXM type of Web service, select the language > Generate Java Code Command, and then select the "Build Web Component, create Web Application WAR" command (see Figure 9). This command compiles and creates a WAR file for the JAXM Service program code. To deploy this JAXM service, you can deploy the WAR file above to a server that supports JAXM, such as Apache Tomcat.





Figure 9 JAXM Build task



As for WEB service components based on stateless session beans, the JSR109 specification has not yet been formally promulgated and is not yet available.
Features to be enhanced in the next step
The Java EE (JSR109) WEB Services specification will soon be available for people to use. With it, you can use a stateless session Bean as a tool for WEB service implementations. It allows existing functionality to appear as a new Web service, as well as a new Web service. PowerDesigner 9.5 is shipped with a version based on the early JSR109 specification, which has yet to be further certified. When the specification is formally promulgated, we will provide the maintenance version to achieve full support for it.



The new version of PowerDesigner will also support a comprehensive standard for WEB services.


Conclusion
PowerDesigner 9.5 simplifies the design and generation process of WEB services. As long as you know how to create a class and a method, you can learn how to create a WEB service! You can use PowerDesigner to design, create, and reverse engineer and create a document for a WEB service. If you want to reuse these Web components, you can create a Web Service component library and use a version library (Repository) to manage different versions of the Web Components.