You can build enterprise-class web services with WebLogic Workshop. Web services built with WebLogic Workshop employ standard web service technologies: XML, SOAP, and WSDL. WebLogic Workshop simplifies web service development by allowing you to focus on application logic, rather than the complex implementation details traditionally required by these technologies.
The following sections explain the basic concepts that you need to know about to begin building web services with WebLogic Workshop, and point you to more in-depth information about each.
You build web services within a Web Service project. A Web Service project corresponds to a J2EE web application. You may build multiple web services within a single project.
Your Web Service project, and other projects you’re working on, are contained in an application. An application is a set of projects, libraries, and resources that are related in some way. At deployment time, a WebLogic Workshop application is compiled into an J2EE enterprise application (an EAR file).
For more information on applications and projects, see Applications and Projects.
The Java Web Service (JWS) file is the core of your web service. It contains the Java code that determines how your web service behaves, typically through the use of one or more custom Java controls that contain the web service's business logic. A JWS file is actually an ordinary Java class file that’s treated specially by the WebLogic Workshop runtime. You can think of a web service built on WebLogic Workshop as a Java class which communicates with the outside world through XML messages. If you are unfamiliar with programming in Java, see Introduction to Java.
You design a JWS file in the WebLogic Workshop integrated development environment. You can use Design View to design your service visually, and Source View to modify your Java code directly. Changes you make in Design View are reflected in your code, and vice versa.
Your web service has a public interface that clients may call. This interface is made up of methods (also called operations) 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.
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.
The controls that your web service uses also expose methods and callbacks. Your web service functions as a client of the control, calling its methods and implementing its callback handlers.
You can use custom Java controls in your web service to implement the business logic of your web service. Custom Java controls in turn use built-in Java controls to access enterprise resources such as databases, legacy applications, and other web services. In other words, your web service interacts with a custom Java control by calling its control methods and implementing callback handlers for control callbacks, and the custom Java control calls control methods and implements callback handlers for any built-in controls it uses.
WebLogic Workshop provides built-in Java controls for connecting to common resources. Some of the built-in controls provided with WebLogic Workshop include:
For more information about built-in controls, see Using WebLogic Built-In Controls. For information on building custom Java controls, see Building Your Own Java Control.
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 in the Property Editor in the WebLogic 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 Property Editor. Properties are stored in your code as special Javadoc tags (annotations beginning with @). Once you are familiar with the annotations, you can edit them directly in Source View if you wish.
Many business processes take time to complete. When a client makes a request from 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 WebLogic Workshop can address this problem by relying on asynchronous communication. In WebLogic Workshop, you implement asynchronous communication for your web service by specifying that methods and callbacks exposed by the web service participate in a conversation.
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. When the web service completes its operations, it can return results to the client via a callback or a polling interface. All of this work happens within the context of a conversation.
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. The conversation also keeps track of state-related data for this exchange between client and service.
For more information on conversations, see Designing Conversational Web Services. For more information on building asynchronous web services, see Designing Asynchronous Interfaces.
A web service communicates with clients and with many resources via XML messages. In many cases it is necessary to translate back and forth between XML and the Java method or callback arguments inside your web service. Outgoing method calls need their Java parameters translated into the appropriate XML data types; likewise incoming XML messages need their data translated into the appropriate Java method parameter types. WebLogic Workshop provides a range of facilities to assist you in creating these translations. Simple mappings happen automatically. For more complex translations, you can modify the XML map—the XML schema that WebLogic Workshop uses to translate method parameters and return values. XML Maps support the XQuery language for SQL-like traversal of XML data. If you need procedural control over the translation, you can write XScript to manipulate XML messages. Finally, XMLBeans, a technology used throughout WebLogic Workshop, provide powerful, natural and very easy translation between XML data and Java types.
For more information about XML maps see Handling and Shaping XML Messages with XML Maps.
For more information about XQuery in XML Maps, see Introduction to XQuery Maps.
FOr more information about XMLBeans, see Handling XML with XMLBeans.