The section describes a project generated from the Eclipse Wizard:
Generating a Communication Service project creates the directory structure illustrated in Listing 4-1.
The base directory is the directory given in the Eclipse Wizard input field Identifier. It contains the following files:
build.properties:
, properties file for the build files:build.xml
: the main file for the project, that is the build file for the Communication Service and references to any other plug-in specific build files in the project. See Main Build File. common.xml:
properties, ant task and targets used by all build files in the project.The directories and files in bold in Listing 4-1 are generated when building the common parts of the Communication Service; the others are generated by the Eclipse Wizard.
<Eclipse Project Name>
+- build.properties
+- common.xml
+- build.xml
+- <Identifier given in Ecplise Wizard>
| +-
dist
//Generated by target dist in <Eclipse Project Name>/build.xml
| | +-
<Package name>.store_<version.jar
// Example store configuration
| | +-
wlng_at_<Identifier>.ear
//Deployable in access tier
| | +-
wlng_nt_<Identifier>.ear
//Deployable in network tier
| +- common
| | +- build.xml //Build file for the common parts of the communication service
| | +-
dist
//Generated by target dist on
//<Eclipse Project Name>/common/build.xml
| | | +- request_factory_skel //Skeletons for the RequestFactory,
//one class for each service WSDL
| | | +-
tmp//Used during build. Contains classes, source,
//definitions, WSDLs, templates, and more.
| | | +-
<Identifier>.war
// Web Service implementation
| | | +-
<Identifier>_callback.jar
// Service callback EJB for
//the communication service
| | | +-
<Identifier>_callback_client.jar
//Service call-back EJB used by
// the plug-in.
| | | +-
<Identifier>_service.jar
// Service EJB
// for the communication service
| | +- resources // Contains application.xml and weblogic-application.xml
// for the access and network tier EAR files respectively.
// The files are packaged in the EAR files META-INF directory
| | | +- handlerconfig.xml //SOAP Message Handler
| | +- src // Source directory for communication service common
| | | +- <Package name>/plugin
| | | | +- <Web Services interface>PluginFactory // One per interface
// defined in the
// Service WSDL files.
The SOAP Message Handler definition file, handlerconfig.xml
, can be edited in order to change, add, or remove SOAP Message Handlers. If modified, it will be taken into account the next time the Communication Service or plug-in is rebuilt.
The following exception definitions are added:
The exceptions are added only to the service facade, not to the plug-in to network interface.
If the exceptions listed above are present in the original WSDL they are reused; if not they are added.
A RESTful Service Facade can be generated using the Eclipse wizard. The sections below describe the default generation of the RESTful Service Facade and how to modify the default implementation.
When a RESTful Service Facade is generated, the following is generated in addition to the directory structure described in Listing 4-1:
The RESTful Service Facade Web Application rest_<Identifier>.war
is packaged in the Access Tier EAR file. The context root is rest/<Identifier>
.
An API description is generated in the directory common/dist/tmp/wars/rest_<Identifier>
. It describes each operation, including URI, HTTP-method, request- and response content-type, request- and response, and errors.
The generated RESTful API has a default implementation, which can be changed by editing rest-config.xml
and re-building the Service Facade. The API description is updated so it reflects any changes done in the configuration file.
The default implementation of the generated RESTful Service Facade has the following attributes for application-initiated requests.
The URL to a default RESTful resource is:
http://<host>:<port>/rest/<context-root>/<interface>/<operation>/<path-info>?<name[1]>=<value[1]&><name[2]>=<value[2]&...<name[n]>=<value[n]>
The HTTP content-type for the request is application/json. The HTTP request body contains a JSON formatted object that corresponds to the input message of the operation as defined in the Service WSDL.
The HTTP content-type for the response is application/json. The HTTP response body contains a JSON formatted object that corresponds to the output message of the operation as defined in the Service WSDL. The HTTP response body for an error contains a JSON formatted object that corresponds to the error message of the operation as defined in the Service WSDL.
For example the Parlay X 2.1 Short Messaging Service defines the operation startSmsNotification. Using the WSDLs for this service, the corresponding RESTful resource is according to Table 4-1. This information is provided in the generated API documentation.
The Bayeux protocol is used to deliver network-triggered messages, or notifications, to an application. For more information on the Bayeux protocol, see the “Bayeux Protocol 1.0draft1” document at http://svn.xantus.org/shortbus/trunk/bayeux/bayeux.html.
The RESTful Service Facades rely on the publish-subscribe model supported by the Publish-Subscribe Server functionality of Oracle WebLogic Server. The communication service delivers the network-triggered traffic to the publish-subscribe server channel, from which the application Bayeux client fetches it. For more information on this model, please see section “Using the HTTP Publish-Subscribe Server” in Developing Web Applications, Servlets, and JSPs For Oracle WebLogic Server at http://download.oracle.com/docs/cd/E12840_01/wls/docs103/webapp/.
An application needs to subscribe for notifications. The application provides an endpoint URI to receive notifications on. In Parlay X, the operations are normally named according to start<Service name>Notification, for example startSmsNotification. In a RESTful environment, the endpoint URI is the name of the Bayeux channel, must start with the string /bayeux/
in order to be recognized as a RESTful endpoint. Immediately following this keyword, the application must provide the application instance ID that uniquely identifies the application. An example of an endpoint is /bayeux/myApplicationID/myInterface
. The application’s Bayeux client must perform a hand-shake, connect to the publish-subscribe server and subscribe to the channel that is being created for the notification.
The publish-subscribe server URI to use for the Bayeux connect is:
<http:>//<host>:<port>/rest/<context-root>/notifications
Notifications are sent via Bayeux Deliver Event messages, see http://svn.cometd.org/trunk/bayeux/bayeux.html. The HTTP response body contains a JSON formatted object that corresponds to the output message of the operation as defined in the Service Callback WSDL.
Typically, the publish-subscribe server URI to use for the Bayeux connect should be returned to the application in the in the header of the response to start a notification. Do do this, rest-config.xml should be updated with a <response-header> element, see Customize the RESTful Service Facade.
The following can be customized for the RESTFul Service Facade:
The mappings are defined in rest-config.xml, according to the XSDs rest-config.xsd
and error-mappings.xsd
, located in $OCSG_HOME/applications/rest.jar
. Table 4-2 contains a description of the mappings.
|
|
Useful for sending a JSON object via HTTP GET, in which case the value should be an encoded JSON string representing the input object. Only one JSON object is supported.
|
|
Defines a a part of the URI for a RESTful resource. This element is optional. When present, the value will be taken from the <pathInfo> component of request URI, and used to populate the field of the target operation input parameter. The attribute name specifies the name of the field to be populated.
|
|
The attribute class defines the generated class that implements the interface defined in the WSDL. The pattern is:
|
|
When defined under <operation>, it refers to provided handler chain names or custom handler chains. If it is a custom handler chain it also needs to be defined under <resources>. If it is a provided handler chain, it is only necessary to refer to the name.
When defined under <resources>, it defines a named handler chain to be invoked prior to the request being handed off to the generated RESFul Service Facade implementation and prior to a response being handed off to the calling application.
There are a set of available handler chains available. New ones can be added. The available handler chains include:
SessionIdHandler ServiceCorrelationIdHandler ExtendingParametersHandler SessionIdHandlerAttachmentHandler ServiceCorrelationIdHandler ExtendingParametersHandler
For default behavior use default or default-with-attachment. See Using a Custom Handler Chain for information on how to create a custom handler chain.
|
|
If it is a variable, the format is ${field name of return value}, where the variable is replaced with the runtime value of the field. Nested fields are not supported. The variable tokens for each operation is found in the generated API docs.
|
|
The attribute id defines the id of the notification. This is the same as the operation defined in the Service Callback WSDL.
|
|
http://host:port/<context-root/<servlet-path>/<pathinfo>?<name1>=<value1>&<name2>=<value2>
servlet-path
must match the attribute uri
of the resource element
.pathinfo
must match the attribute name
of the element path-info-param
. It identifies a unique resource, such as a correlator. Note that this element is optional. If not present in the XML configuration file, it should not be present in the URL.For application-initiated operations, each resource URI is mapped to an HTTP method and an implementing class, for example:
<resource uri="/SendSms/sendSms">
<operation>
<httpMethod>POST</httpMethod>
<target method="sendSms" class="com.acompany.arestservice.rest.SendSmsRestImpl" service="SendSms"/>
</operation>
</resource>
The names of the generated classes are derived from the package name given in the Eclipse wizard and the interface name derived from the WSDL:
<package name from wizard>.<service name from wizard>.rest.<Interface name from WSDL>RestImpl
The method name is derived from the WSDL. The resource URI is derived from the namespace definition in the WSDL. The element <httpMethod> defines the HTTP method to use, either POST, GET, PUT or DELETE.
For network-triggered operations, each notification service is mapped to one or more classes that contain the data and the method used to deliver the data, for example:
<notification>
<service>SmsNotification</service>
<data class=
"org.csapi.schema.parlayx.sms.notification.v2_2.local.NotifySmsReception"
id="notifySmsReception"/>
<data class=
"org.csapi.schema.parlayx.sms.notification.v2_2.local.NotifySmsDeliveryReceipt"
id="notifySmsDeliveryReceipt"/>
</notification>
The classes and the method name are derived from the WSDL.
A custom handler chain can be defined if additional processing of the request needs to be done before a request is passed on to the Service Enabler or back to an application.
A handler chain is defined as a set of handlers. A handler chain is named and referred to in rest-config.xml.
A custom handler must implement the interface.
public interface com.bea.wlcp.wlng.rest.handler.Handler
The method handleRequest is invoked before a request is passed on to the Service Enabler.
The method handleResponse is invoked before a response is returned to an application.
The chain is defined in rest-config.xml and all classes in the chain must be packaged in the WAR file for the restful service facade.
When creating a plug-in for a given Communication Service, the directory structure illustrated in Listing 4-2 is created under the top-level directory. The base directory depends on the type of Communication Service the plug-in belongs to, such as, for example, px21_multimedia_messaging,
or px21_sms
. It also depends on whether the plug-in is for an existing Communication Service or for a new one.
If the plug-in is for an existing Communication Service, it is generated under one of the following directories:
px30_audio_call
for plug-ins for Parlay X 30 Audio Call px21_call_notification
for Parlay X 2.1 Call Notificationpx30_call_notification
for Parlay X 3.0 Call Notificationpx21_multimedia_messaging
for Parlay X 2.1 Multimedia Messagingpx21_presence
for Parlay X 2.1 Presenceews_push_message
for Extended Web Services WAP Pushpx21_sms
for Parlay X 2.1 Short Messagingews_susbcriber_profile
for Extended Web Services Subscriber Profilepx21_terminal_location
for Parlay X 2.1 Terminal Locationpx21_third_party_call
for Parlay X 2.1 Third Party Callpx30_third_party_call
for Parlay X 3.0 Thrid Party CallIf it is for a new Communication Service, the base directory is given in the Identifier entry field in the Eclipse Wizard.
The base directory contains the directory plugins
, which contains subdirectories for each protocol that is being added. The names of the directories are the same as the name chosen for the Protocol field in the Eclipse Wizard.
Each of the sub-directories for a plug-in contains the following files:
build.xml
: The build file for the plug-in, see Plug-in Build File.Each plug-in sub-directory also contains the directories:
config:
The directory that includes an instancemap that will be used by the InstanceFactory to create instances for the plug-in interface implementations.dist
: The directory where the final deployable plug-in jar will end up. If a new plug-in skeleton is generated from the build file it will be generated here.resources
: The directory that contains deployment descriptors for the plug-in.src
: The directory that contains the generated plug-in code. storage
: The directory that contains the configuration file for the Storage service.The directories and files in bold in Listing 4-2 are generated when building the plug-in, the others are generated by the Eclipse Wizard.
| +- plugins // Container directory for all plug-ins for
// the communication service
| | +- <Protocol> // One specific plug-in
| | | +- build.xml // Build file for the plug-in
| | | +-
build
// Used during the build process
| | | +- config //
| | | | +- instance_factory
| | | | | +- instancemap //Instance map
| | | +-
dist
// Generated by target dist in build.xml for the plug-in
| | | | +-
<Identifier>_<Protocol>_plugin.jar
| | | | +-
<Package name>.store_<version>.jar
| | | +- resources // Contains parts of weblogic-extension.xml
// for the network tier EAR file.
// the file is packaged in the EAR file’s META-INF directory
| | | +- src
| | | | +- <Package name> // Directory structure reflecting
// plug-in package name
| | | | | +- management // Example MBean
| | | | | | +- MyTypeMBean.java
| | | | | | +- MyTypeMBeanImpl.java
| | | | | +- <Web Services interface> // One per Service WSDL
| | | | | | +- north
| | | | | | | +- <Web Services interface>PluginImpl.java
// Implmentation of the interface
| | | | | +- <Type>PluginInstance.java
| | | | | +- <Type>PluginService.java
// PluginService implementation
| | | +- storage //Example of a store configuration.
| | | | +- wlng-cachestore-config-extensions.xml
When creating a SOAP2SOAP plug-in, the directory structure described in Plug-in is created under the top-level directory. In addition, the directories and files in Listing 4-3 are generated. The directories and files in bold are created when building the plug-in; the others are generated by the Eclipse Wizard.
Note: | Only the deployable artifacts are relevant. The generated code for the SOAP2SOAP type of plug-ins should not be modified. |
| +- plugins // Container directory for all plug-ins for
// the communication service
| | +- <Protocol> // One specific plug-in
| | | +- build.xml // Build file for the plug-in
| | | +-
build
// Used during the build process
| | | +- config //
| | | | +- instance_factory
| | | | | +- instancemap //Instance map
| | | +-
dist
// Generated by target dist in build.xml for the plug-in
| | | | +-
<Identifier>_<Protocol>_plugin.jar
| | | | +-
<Package name>.store_<version>.jar
//unused, empty
| | | +- resources // Contains parts of weblogic-extension.xml
// for the network tier EAR file.
// the file is packaged in the EAR file’s META-INF directory
| | | | +-
client_handlerconfig.xml // SOAP Message Handler
| | | +- src
| | | | +- <Package name> // Directory structure reflecting
// plug-in package name
| | | | | +- client // Implementation of Web Service client
| | | | | | +- <Web Services interface>_Stub.java
| | | | | | +- <Web Services interface>.java
| | | | | | +- <Web Services interface>Service_Impl.java
| | | | | | +- <Web Services interface>Service.java
| | | | | +- <Web Services call-back interface> // One per Call-back WSDL
| | | | | | +- south
| | | | | | | +- <Web Services interface>PluginSouth.java
// Interface for network-triggered requests
| | | | | | | +- <Web Services interface>PluginSouthImpl.java
// Implementation of the interface
| | | | | +- <Web Services interface> // One per Service WSDL
| | | | | | +- north
| | | | | | | +- <Web Services interface>PluginImpl.java
// Implementation of the interface
| | | | | +- <Type>PluginInstance.java
| | | | | +- <Type>PluginService.java
// PluginService implementation
| | | +- storage //Example of a store configuration. Empty.
| | | +- wsdl // WSDLS and XML-to-Java mappings.
| +-
<Identifier>_callback.war
// Web Service implementation
// for the SOAP2SOAP plug-in
As illustrated in Listing 4-3, a WAR file for the plug-in is generated. This WAR file contains the Web Service for network-triggered requests. It is only generated if there is a notification WSDL defined at generation-time. It will be packaged in the EAR for the Service Enabler.
The SOAP Message Handler definition file, client_handlerconfig.xml, can be edited in order to change, add, or remove SOAP Message Handlers. If modified, the ant target rebuild.ws in the plug-in build file needs to be invoked
When creating a SIP plug-in, the directory structure described in Plug-in is created under the top-level directory. In addition, the directories and files in Listing 4-4 are generated. The directories and files in bold are created when building the plug-in; the others are generated by the Eclipse Wizard.
| +- plugins // Container directory for all plug-ins for
// the communication service
| | +- <Protocol> // One specific plug-in
| | | +- build.xml // Build file for the plug-in
| | | +-
build
// Used during the build process
| | | +- config //
| | | | +- instance_factory
| | | | | +- instancemap //Instance map
| | | | +- sip
| | | | | +- WEB-INF
| | | | | | +- sip.xml
| | | | | | +- web.xml
| | | +-
dist
// Generated by target dist in build.xml for the plug-in
| | | | +-
<Identifier>_<Protocol>_plugin.jar
| | | | +-
<Identifier>_<Protocol>_sip.war
| | | | +-
<Package name>.store_<version>.jar
| | | +- resources
| | | | +- META-INF
| | | | | +-weblogic-extension.xml
| | | | | +-application.xml
| | | +- src
| | | | +- <Package name> // Directory structure reflecting
// plug-in package name
| | | | | +- servlet // Implementation of the SIP Servlet
| | | | | | +- <Identifier>Servlet.java
| | | | | +- <Identifier>SipHelper.java
| | | +- storage //Example of a store configuration. Empty.
As illustrated in Listing 4-3, a set of additional classes and configuration files for the SIP type plug-in is generated compared to the standard plug-in.
Table 4-1Contains a summary of the added items.
See the document Developing SIP Applications, a part of the documentation for Oracle Converged Application Server at
http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/programming/index.html
|
|
See the document Developing SIP Applications, a part of the documentation for Oracle Converged Application Server at
http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/programming/index.html
|
|
Network protocol plug-ins can benefit from the Diameter support provided by Oracle Communications Converged Application Server.
Diameter is a peer-to-peer protocol that involves delivering attribute-value pairs (AVPs). A Diameter message includes a header and one or more AVPs. The collection of AVPs in each message is determined by the type of Diameter application, and the Diameter protocol also allows for extension by adding new commands and AVPs. Diameter enables multiple peers to negotiate their capabilities with one another, and defines rules for session handling and accounting functions.
Oracle Communications Converged Application Server includes an implementation of the base Diameter protocol that supports the core functionality and accounting features described in RFC 3588. Oracle Communications Converged Application Server uses the base Diameter functionality to implement multiple Diameter applications, including the Sh, Rf, and Ro applications.
You can also use the base Diameter protocol to implement additional client and server-side Diameter applications. The base Diameter API provides a simple, Servlet-like programming model that enables you to combine Diameter functionality with SIP, HTTP, or other functionality in a Service Enabler.
Oracle Communications Services Gatekeeper uses the Diameter support provided by Oracle Communications Converged Application Server in the Parlay X 3.0 Payment Communication Service (Ro), CDR to Diameter service (Rf), and the Credit Control interceptor (Ro).
For an overview of the capabilities of the Diameter API provided with Oracle Communications Converged Application Server, see Developing Diameter Applications at http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/diameter/. For information about the Diameter API, refer to the JavaDoc at http://download.oracle.com/docs/cd/E13153_01/wlcp/wlss40/javadoc/index.html. This is part of the documentation set for Oracle Communications Converged Application Server.
To create a plug-in that uses this the Diameter API, generate a network protocol plug-in using the Eclipse Wizard and include the JAR to the build path of the project.
The Diameter API is packaged in $OCCAS_HOME/server/lib/wlss/wlssdiameter.jar
.
The JAR file needs to be added to the build class path. It is already included in the run-time class path.
The generated classes are listed below.
The interface a plug-in service needs to implement.
It extends the interfaces PluginService, PluginInstanceFactory and PluginServiceLifecycle.
The interface that defines the plug-in service when it is registered in the Plug-in Manager.
The factory that allows a plug-in service to create plug-in instances.
The interface that defines the lifecycle for a plug-in service. See States.
Implements com.bea.wlcp.wlng.api.plugin.ManagedPluginService.
Defines the life-cycle for a plug-in service, see States.
Also holds the data that is specific for the plug-in instance.
The actual class name is <Communication Service Type>PluginService
. This class manages the life-cycle for the plug-in service, including implementing the necessary interfaces that make the plug-in deployable in Oracle Communications Services Gatekeeper. It is also responsible for registering the north interfaces with the Plug-in Manager. At startup time it uses the InstanceFactory to create one instance of each plug-in service and at activation time it registers these with the Plug-in Manager. The InstanceFactory uses an instancemap to find out which class it should instantiate for each plug-in interface implementation. The instance map is found under the resource
directory.
The ManagedPlugin
skeleton implements the following methods related to life-cycle management and should be adjusted for the plug-in:
In addition, this class defines which address schemes the plug-in can handle, in private static final String[] SUPPORTED_SCHEMES
.
Implements com.bea.wlcp.wlng.api.plugin.ManagedPluginInstance.
Defines the life-cycle for a plug-in instance, see States.
The actual class name is <Communication service Type>PluginInstance
. This class manages the life-cycle for the plug-in instance including implementing the necessary interfaces that make the plug-in an instance in Oracle Communications Services Gatekeeper.
It is also responsible for instantiating the classes that implement the traffic interfaces, and initializing stores to use and relevant MBeans.
See Interface: ManagedPluginInstance.
This is an empty implementation of the Plug-in North interface. This interface is generated based on the WSDL files that define the application-facing interface. This is the starting point for the plug-in implementation.
The following files will be generated in the directory under src/...../<service name>/north
:
Below outlines what needs to be implemented in the plug-in skeleton.
The class contains a Java mapping of the methods defined in the Web Service. The methods are mapped one-to-one. The name of each method is the same as the name of the operation defined in the WSDL. The parameter is a class that mirrors the parameters in the input message in the Web Service request. The return type is a class that represents the output message in the Web Service Request.
The actual class name is <Communication service identifier>PluginFactory
, such as, for example, NotificationManagerPluginFactory
. This is a helper class used by the Service EJB. It serves two purposes:
The following files will be generated in the dist
directory under request_factory_skel/src
:
In addition to the generated classes for a regular plug-in, a SOAP2SOAP plug-in adds a few extra classes, because the network protocol is known.
Note: | Only the deployable artifacts are relevant. The generated code for SOAP2SOAP type of plug-ins should not be modified. |
Note: | See Managing and Configuring SOAP2SOAP Communication Services in the System Administrator’s Guide for information on how to configure and manage a SOAP2SOAP plug-in |
The following generated code is similar to the code generated for the non-SOAP2SOAP plug-ins:
These classes and interfaces are generated for each interface, based on the Service WSDLs:
Extends weblogic.wsee.jaxrpc.StubImp
Implements <Web Services Interface>
Used by the corresponding PluginNorth class.
Implemented by <Web Services Interface>_Stub.
Extends weblogic.wsee.jaxrpc.ServiceImpl.
Extends javax.xml.rpc.Service.
Defines the traffic interfaces.
In addition to the functionality in described in PluginInstance, in the PluginInstance generated for SOAP2SOAP plug-ins, the following occurs:
HTTPProxyManagement is described in Managing and Configuring SOAP2SOAP Communication Services in Oracle Communications Services Gatekeeper System Administrator’s Guide.
HeartbeatManagement is described in Configuring Heartbeats in Oracle Communications Services Gatekeeper System Administrator’s Guide.
In addition to the functionality described in PluginNorth, this class:
This class implements a Java representation of the Web Service implementation. It implements PluginSouth: see Interface: PluginSouth. When a network-triggered method is invoked, it:
The RequestFactory for a SOAP2SOAP plug-in has the same functionality as described in RequestFactory Skeleton, but instead of serving as a skeleton, it is an implementation. It contains an implementation of createRequestInfo(...) which means that the Plug-in Manager does no routing based on destination address.
The main build file for the Communication Service contains the following targets:
build_csc
, builds the common parts of the Communication Service .build_plugins
, builds the plug-ins for the Communicaiton Service .stage
, copies the JARs for the plug-ins to the directory stage
.make-facade
, creates a deployable EAR for the access tier in the directory dist
.make-enabler
, creates a deployable EAR for the network tier in the directory dist
.deploy-facade
, deploys the service facade EAR to the access tier. undeploy-facade
, undeploys the service facade EAR from the access tier.deploy-enabler
, deploys the service enabler EAR from the network tier.undeploy-enabler
, undeploys the service enabler EAR from the network tierclean
, clears the directory dist.
dist
, calls the prepare,build_csc,build_plugins,stage,make-facade,make-enabler
targets.Note: | When using the deploy and undeploy targets, make sure to adapt the settings for user, password, adminurl, targets, and appversion in the parameters to wldeploy. By default Web Services Security is not enabled for new Communication Services. See section Setting up WS-Policy and JMX Policy in System Administrator’s Guide for instructions on how to configure this. |
The build file for the common parts of the Communication Service contains the following targets:
The build file for the plug-in contains the following targets:
compile,
compiles the source code under the src
directory and puts the class files under the build
directory.jar
, calls the compile
target and then creates a plug-in jar file under the dist
directory.instrument,
weaves the aspects that should apply into the plug-in.build.schema
, builds the schema file and the classes used by the storage service.dist
, calls the clean
, compile
, jar
and instrument
, and build.schema
targets.clean
, deletes the build
and dist
directories.The build files use a set of ant tasks and macros, described below:
The ant tasks are defined in $PDS_HOME/lib/wlng/ant-tasks.jar
This ant task builds the common parts of the Communication Service. Below is a description of the attributes.
<cs_gen destDir="${dist.dir}"
packageName="com.bea.wlcp.wlng.example"
name="say_hello"
serviceType="example"
company="BEA"
version="4.1"
contextPath="sayHello"
soapAttachmentSupport="false"
wlngHome="${wlng.home}"
pdsHome="${pds.home}">
<classpath refid="wls.classpath"/>
<classpath refid="wlng.classpath"/>
<servicewsdl file="${wsdl}/example_hello_say_service.wsdl"/>
</cs_gen>
This ant task builds a plug-in for a Communication Service. Below is a description of the attributes.
<plugin_gen destDir="${dist.dir}"
packageName="com.bea.wlcp.wlng.example.bla"
name="say_hello"
serviceType="example"
esPackageName="com.bea.wlcp.wlng.example"
protocol="bla"
schemes=""
company="BEA"
version="4.1"
pluginifjar="${dist.dir}/say_hello/common/dist/say_hello_service.jar">
<classpath refid="wls.classpath"/>
<classpath refid="wlng.classpath"/>
<servicewsdl file="${wsdl}/example_hello_say_service.wsdl"/>
</plugin_gen>
This ant task packages a Communication Service. Below is a description of the attributes.
<cs_package destfile="${cs.dist}/${enabler.ear.name}.ear"
duplicate ="fail"
displayname="${enabler.ear.name}">
<descriptorfileset dir="${csc.dir}/resources/enabler/META-INF"
includes="*.xml"/>
<descriptorfileset dir="${cs.name}/plugins"
includes="*/resources/META-INF/*.xml"/>
<manifest>
<attribute name="Bundle-Name"
value="${enabler.ear.name}"/>
<attribute name="Bundle-Version"
value="${manifest.bundle.version}"/>
<attribute name="Bundle-Vendor"
value="${manifest.bundle.vendor}"/>
<attribute name="Weblogic-Application-Version"
value="${manifest.bundle.version}"/>
</manifest>
<fileset dir="${csc.dist}">
<include name="*_service.jar"/>
</fileset>
<zipfileset dir="${cs.stage}">
<include name="*plugin.jar"/>
</zipfileset>
</cs_package>
This ant macro annotates an MBean interface based on the JavaDoc. The macro is defined in the common.xml build file for the
The annotations are rendered as descriptive information by the Gatekeeper Administration console. Below is a description of the attributes.
<javadoc2annotation
tempDir="${plugin.generated.dir}/mbean_gen_tmpdir"
destDir="${plugin.classes.dir}"
sourceDir="${plugin.src.dir}"
classpath="javadoc.classpath">
</javadoc2annotation>