You can build enterprise-class web services with Workshop. Web services built with Workshop employ standard web service technologies: XML, SOAP, and WSDL. Workshop simplifies web service development by allowing you to focus on application logic, rather than the complex implementation details traditionally required by these technologies.
Workshop also offers the web service Design View, a graphical tool for designing, creating, and editing web services.
The following sections explain the basic concepts that you need to know about to begin building web services with Workshop, and point you to more in-depth information about each.
The web service Design View gives a graphical, intuitive view of a web service and its operations. It also makes it easy to perform complex coding and design tasks. For more information on the Design View see Using Design View to Create Web Services.
You build web services within a web service project. A web service project corresponds to a J2EE web application with the addition of facets to support web services. You may build multiple web services within a single project.
For more information on applications and projects, see Applications and Projects.
The web service class is the core of your web service. It is an ordinary Java class (decorated with the @WebService annotation) that determines how your web service behaves, often through the use of one or more controls that contain the web service's application logic. You can think of a web service built on Workshop as a Java class which communicates with the outside world through XML messages. This documentation assumes you are familiar with Java programming.
You design a web service in the Workshop integrated development environment.
Your web service has a public interface that clients may call over the internet. This interface is made up of methods and callbacks. The methods that your web service exposes are called by clients; the callbacks are methods on the client that your web service calls to send information back to the client. These methods and callbacks are available over the internet because they are decorated with the @WebMethod annotation.
Within your web service code, you may also have non-public methods that are not exposed to clients. These methods perform internal functions in your web service. These methods are not decorated with @WebMethod.
The controls that your web service uses also expose methods and events. Your web service functions as a client of the control, calling its methods and implementing its event handlers.
You can use custom controls in your web service to implement the application logic of your web service. Custom controls in turn use system controls to access enterprise resources such as databases, legacy applications, and other web services. In other words, your web service interacts with a custom control by calling its control methods and implementing event handlers for its control events, and the custom control calls control methods and implements event handlers for any system controls it uses.
Workshop provides system controls for connecting to common resources. The system controls provided with Workshop are:
For more information about system controls, see Using System Controls. For information on building custom controls, see Custom Controls.
Most of the elements that make up your web service-methods, callbacks, controls, and the web service itself-have properties that you can set to specify their characteristics. You can set properties in the Properties view in the Workshop IDE. Each element of your web service has one or more annotations, each with a set of attributes, corresponding to the element's properties in the Properties view. Properties are stored in your code as Java 5 annotations (beginning with @). You can also edit annotations directly in the code editor if you wish.
Many processes take time to complete. When a client sends a request to a web service, if the web service doesn't return a response right away, the client may be left waiting for it, unable to continue other operations. Web services that you build with Workshop can address this problem by relying on asynchronous communication.
When a client and web service communicate asynchronously, the web service immediately acknowledges the client's request, then continues processing the request. The client is free to continue performing other work. For more information on building asynchronous web services, see Designing Asynchronous Interfaces.
A web service and its client may also participate in a conversation. The conversation keeps track of state-related data for this exchange between client and service.The conversation correlates the client's requests and the service's response by means of a conversation ID, a unique identifier that is generated when the client initiates a conversation with the service.
For more information on conversations, see Creating Conversational Web Services in the WebLogic Sever documentation and Tutorial: Create a Timer Control.
Developers often design web services around preexisting data structures and contracts. Common starting points are WSDL files, XSD files, or Java files.
When building a web service, it is often easier to build the web service implementation around an already existing web service contract (a WSDL file). This method for creating a web service is sometimes called "WSDL first", "contract first" or "top down" web service design.
Another common approach to design web services is to start with an XML schema file (an XSD file), compile XMLBeans from the schema, and then build a web service implementation centered on those XMLBean classes.
In this approach, you develop a web service as a Java class. Methods become web service operations and method parameters and return types can be simple Java Beans. The Java class is annotated to indicate what methods should be exposed and to set other properties for the service.
For more information on how Workshop supports both these approaches to web service design, see Web Service Development Starting Points.
The Web Service stack in WebLogic Server 9.x/10.x does not support nested types as parameters and/or return values. However, Beehive Controls often use inner classes as the pattern for data values (e.g., The JDBC Control contains a commented out example of an inner class to hold the return values from the database queries). Therefore the use of Beehive Control nested values in a JWS is not supported
Any Beehive Control containing inner classes that
will be used by a JWS will need to convert the inner class to a standalone
class.