You are viewing a plain text version of this content. The canonical link for it is here.
Posted to muse-commits@ws.apache.org by sc...@apache.org on 2006/06/06 18:22:10 UTC
svn commit: r412161 - in
/webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide:
muws_topics.xml relationships.xml wsdl.xml
Author: scamp
Date: Tue Jun 6 09:22:08 2006
New Revision: 412161
URL: http://svn.apache.org/viewvc?rev=412161&view=rev
Log: (empty)
Modified:
webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/muws_topics.xml
webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/relationships.xml
webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/wsdl.xml
Modified: webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/muws_topics.xml
URL: http://svn.apache.org/viewvc/webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/muws_topics.xml?rev=412161&r1=412160&r2=412161&view=diff
==============================================================================
--- webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/muws_topics.xml (original)
+++ webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/muws_topics.xml Tue Jun 6 09:22:08 2006
@@ -2,87 +2,87 @@
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
"http://forrest.apache.org/dtd/document-v20.dtd">
<document>
- <header>
- <title>MUWS-Specific Topics</title>
- </header>
- <body>
- <section id="intro">
- <title>Introduction</title>
- <p>Each resource that is configured to be a notification producer (implements the WSN <code>NotificationProducer</code> portType) is associated with a
- topic set. The resource publishes notifications to a topic in the topic set. Notification consumers can then subscribe to a topic and receive notifications
- from the resource. As the service developer of the notification producer resource, you are responsible for adding the topics you want to support to the topic set.
- </p>
- <p>
- This section provides instructions for adding support to your managed resource for the various topics that are defined by MUWS.
- The topics can be organized into three types:
- </p>
- <ul>
- <li>Capability topics: Topics for each of the MUWS defined resource properties that indicate changed property events</li>
- <li>Advertiser topics: Topics for resource creation and destruction events</li>
- <li>Relationship topics: Topics for relationship created and deleted events</li>
- </ul>
- <note>For information on adding custom topics for your resource, see the <a href="site:p_producer">Notification Producer</a> section in the Apache Pubscribe
- documentation.</note>
- <p>Notification topics are added to the <code>init()</code> method of your service's resource class. If you used the Wsdl2Java tool, the resource class
- (<em>
- <code>service_name</code>
- </em>
- <code>Resource.java</code>) is automatically generated, but will need to modified. Initially, you should model your resource off of the included FileSystemResource
- example to ensure that you write a valid resource class.
- </p>
- <p>The resource class is the stateful instance-representation of your Web service. In addition to notification topics, the resource class maintains the resource
- <code>id</code> and the <code>ResourcePropertySet</code>. The <code>ResourcePropertySet</code> is the Java representation of the Resource Properties document
- defined in the types section of your WSDL file.
- </p>
- <note>This section does not include complete instructions for initializing resource properties and adding them to the <code>ResourcePropertySet</code>. See the
- <a href="site:w_resource">Resource Class</a> documentation included with Apache WSRF.
- </note>
- <section>
- <title>ManagementEvent notifications</title>
- <p> WSDM defines a specific event format that is different than a standard WSN notification. Whenever you subscribe to a MUWS related topic, the notifications
- are always returned in the WSDM event format. The term ManagementEvent notification is used since <code>ManagementEvent</code> is the root element of the
- notification.
- </p>
- <p>A ManagementEvent notification provides a set of standard fields that provide metadata about the event as well as the actual notification element (e.g, a resource
- property changed event for a resource property). The Metadata includes: report time, event ID, source component, reporter component, as well as an "any" wild card.
- It is suggested that your custom topics also use this event format. Although, it is not required. Apache Muse provides some helper classes that can be used to create
- ManagementEvent-based notifications. The instructions are discussed below.
- </p>
- </section>
- </section>
- <section id="act">
- <title>Adding Capability Topics</title>
- <p>A capability topic is created for each MUWS property that is defined in your WSDL. To add MUWS capability topics for these properties, implement the
- <code>init()</code> of your resource class using the following instructions. The example is taken from
- the filesystem example. For simplicity, only the <code>OperationalStatus</code> topic is shown.</p>
- <ol>
- <li>Create a MUWS topic space.
- <source>
+ <header>
+ <title>MUWS-Specific Topics</title>
+ </header>
+ <body>
+ <section id="intro">
+ <title>Introduction</title>
+ <p>Each resource that is configured to be a notification producer (implements the WSN <code>NotificationProducer</code> portType) is associated with a
+ topic set. The resource publishes notifications to a topic in the topic set. Notification consumers can then subscribe to a topic and receive notifications
+ from the resource. As the service developer of the notification producer resource, you are responsible for adding the topics you want to support to the topic set.
+ </p>
+ <p>
+ This section provides instructions for adding support to your managed resource for the various topics that are defined by MUWS.
+ The topics can be organized into three types:
+ </p>
+ <ul>
+ <li>Capability topics: Topics for each of the MUWS defined resource properties that indicate changed property events</li>
+ <li>Advertiser topics: Topics for resource creation and destruction events</li>
+ <li>Relationship topics: Topics for relationship created and deleted events</li>
+ </ul>
+ <note>For information on adding custom topics for your resource, see the <a href="site:producer">Notification Producer</a> section in the Apache Pubscribe
+ documentation.</note>
+ <p>Notification topics are added to the <code>init()</code> method of your service's resource class. If you used the Wsdl2Java tool, the resource class
+ (<em>
+ <code>service_name</code>
+ </em>
+ <code>Resource.java</code>) is automatically generated, but will need to modified. Initially, you should model your resource off of the included FileSystemResource
+ example to ensure that you write a valid resource class.
+ </p>
+ <p>The resource class is the stateful instance-representation of your Web service. In addition to notification topics, the resource class maintains the resource
+ <code>id</code> and the <code>ResourcePropertySet</code>. The <code>ResourcePropertySet</code> is the Java representation of the Resource Properties document
+ defined in the types section of your WSDL file.
+ </p>
+ <note>This section does not include complete instructions for initializing resource properties and adding them to the <code>ResourcePropertySet</code>. See the
+ <a href="site:resource">Resource Class</a> documentation included with Apache WSRF.
+ </note>
+ <section>
+ <title>ManagementEvent notifications</title>
+ <p> WSDM defines a specific event format that is different than a standard WSN notification. Whenever you subscribe to a MUWS related topic, the notifications
+ are always returned in the WSDM event format. The term ManagementEvent notification is used since <code>ManagementEvent</code> is the root element of the
+ notification.
+ </p>
+ <p>A ManagementEvent notification provides a set of standard fields that provide metadata about the event as well as the actual notification element (e.g, a resource
+ property changed event for a resource property). The Metadata includes: report time, event ID, source component, reporter component, as well as an "any" wild card.
+ It is suggested that your custom topics also use this event format. Although, it is not required. Apache Muse provides some helper classes that can be used to create
+ ManagementEvent-based notifications. The instructions are discussed below.
+ </p>
+ </section>
+ </section>
+ <section id="act">
+ <title>Adding Capability Topics</title>
+ <p>A capability topic is created for each MUWS property that is defined in your WSDL. To add MUWS capability topics for these properties, implement the
+ <code>init()</code> of your resource class using the following instructions. The example is taken from
+ the filesystem example. For simplicity, only the <code>OperationalStatus</code> topic is shown.</p>
+ <ol>
+ <li>Create a MUWS topic space.
+ <source>
org.apache.ws.notification.topics.TopicSpace muwsTopicSpace = new org.apache.ws.notification.topics.impl.TopicSpaceImpl(
org.apache.ws.muws.v1_0.MuwsConstants.NSURI_MUWS_PART2_TOPICS );
getTopicSpaceSet().addTopicSpace( muwsTopicSpace );
- </source>
- </li>
- <li>For each MUWS capability that your resource supports, add a topic to the resource's topic set in the MUWS topic space. The topic should be of the type
- <code>org.apache.ws.muws.v1_0.topics.ManagementEventTopic</code>.
- <source>
+ </source>
+ </li>
+ <li>For each MUWS capability that your resource supports, add a topic to the resource's topic set in the MUWS topic space. The topic should be of the type
+ <code>org.apache.ws.muws.v1_0.topics.ManagementEventTopic</code>.
+ <source>
org.apache.ws.muws.v1_0.topics.ManagementEventTopic operationalStatusCapabilityTopic;
operationalStatusCapabilityTopic = new org.apache.ws.muws.v1_0.topics.impl.XmlBeansManagementEventTopicImpl(
org.apache.ws.muws.v1_0.capability.OperationalStatusCapability.TOPIC_NAME );
muwsTopicSpace.addTopic( operationalStatusCapabilityTopic );
- </source>
- </li>
- <li>Initialize the resource property to be associated with the topic
- <source>
+ </source>
+ </li>
+ <li>Initialize the resource property to be associated with the topic
+ <source>
org.oasisOpen.docs.wsdm.x2004.x12.muws.wsdmMuwsPart1.ManageabilityCapabilityDocument operationalStatusCapabilityPropElem =
org.oasisOpen.docs.wsdm.x2004.x12.muws.wsdmMuwsPart1.ManageabilityCapabilityDocument.Factory.newInstance();
operationalStatusCapabilityPropElem.setManageabilityCapability( org.apache.ws.muws.v1_0.capability.OperationalStatusCapability.URI );
resourceProperty.add( operationalStatusCapabilityPropElem );
- </source>
- </li>
- <li>Add the topic as a resource property change listener for the resource property. This will automatically emit ManagementEvent-wrapped resource property change events as they occur.
- <source>
+ </source>
+ </li>
+ <li>Add the topic as a resource property change listener for the resource property. This will automatically emit ManagementEvent-wrapped resource property change events as they occur.
+ <source>
resourceProperty = resourcePropertySet.get( FilesystemPropertyQNames.OPERATIONALSTATUS );
org.oasisOpen.docs.wsdm.x2004.x12.muws.wsdmMuwsPart2.OperationalStatusDocument statusDoc =
org.oasisOpen.docs.wsdm.x2004.x12.muws.wsdmMuwsPart2.OperationalStatusDocument.Factory.newInstance();
@@ -90,72 +90,72 @@
resourceProperty.add(statusDoc);
resourceProperty.setCallback( new example.filesystem.callback.OperationalStatusCallback( m_filesystem ) );
resourceProperty.addChangeListener( operationalStatusCapabilityTopic );
- </source>
- <note>A change listener is not required but can be used if you want management events containing changed property events. The <code>ResourceId</code>
- property does not require a change listener since the property is read only.</note>
- </li>
- </ol>
- </section>
- <section>
- <title>Adding Advertiser Topics</title>
- <p>The MUWS specification defines an Advertisement capability that provides a notification whenever a manageable resource is created or destroyed. The
- capability includes four topics, two of which are implemented in Muse:</p>
- <ul>
- <li>
- <code>ManageableResourceCreation</code>
- </li>
- <li>
- <code>ManageableResourceDestruction</code>
- </li>
- </ul>
- <p>Muse implements these topics as part of the <code>ResourceAdvertiser</code> service that is deployed by default in Muse. Therefore, it does not have to be
- defined in a MUWS WSDL or directly implemented by your WS Resource. See the <a href="site:adv">Using the Resource Advertiser Service</a> section for more
- information on subscribing to the Advertiser Topics.
- </p>
- </section>
- <section>
- <title>Adding the Relationship Topics</title>
- <p>This section discusses five topics that are defined in the MUWS specification to support relationships:</p>
- <ul>
- <li>
- <code>Relationship</code>: A topic for a resource property that notifies a consumer about the relationships that a resource knows about.</li>
- <li>
- <code>RelationshipCreated</code>: A topic that notifies a consumer when a new relationship is added.</li>
- <li>
- <code>RelationshipDeleted</code>: A topic that notifies a consumer when a relationship is deleted.</li>
- <li>
- <code>RelationshipAccessCapability</code>: A topic that notifies a consumer that an interaction with a relationship or its participants has occurred.</li>
- <li>
- <code>RelationshipResourceCapability</code>: A topic that notifies a consumer when the identity of a relationship changes. This includes the name, type, and
- participant properties of a relationship.</li>
- </ul>
- <p>The <code>Relationship</code> and <code>RelationshipResourceCapability</code> topics are created in the same manner as discussed in the
- <a href="#act">Adding Capability Topics</a> above. The <code>Relationship</code> topic represents a property changed event that occurs whenever the list of
- relationships changes. The <code>RelationshipResourceCapability</code> topic represents property changed events whenever either the name, type, or participants for a
- relationship changes.
- </p>
- <p>The <code>RelationshipCreated</code>, <code>RelationshipDeleted</code>, and <code>RelationshipResourceCapability</code> topics are implemented in Muse by
- default. Therefore, you only need to add these topics to the topic set in your resource class. For example:</p>
- <source>
- try {
+ </source>
+ <note>A change listener is not required but can be used if you want management events containing changed property events. The <code>ResourceId</code>
+ property does not require a change listener since the property is read only.</note>
+ </li>
+ </ol>
+ </section>
+ <section>
+ <title>Adding Advertiser Topics</title>
+ <p>The MUWS specification defines an Advertisement capability that provides a notification whenever a manageable resource is created or destroyed. The
+ capability includes four topics, two of which are implemented in Muse:</p>
+ <ul>
+ <li>
+ <code>ManageableResourceCreation</code>
+ </li>
+ <li>
+ <code>ManageableResourceDestruction</code>
+ </li>
+ </ul>
+ <p>Muse implements these topics as part of the <code>ResourceAdvertiser</code> service that is deployed by default in Muse. Therefore, it does not have to be
+ defined in a MUWS WSDL or directly implemented by your WS Resource. See the <a href="site:adv">Using the Resource Advertiser Service</a> section for more
+ information on subscribing to the Advertiser Topics.
+ </p>
+ </section>
+ <section>
+ <title>Adding the Relationship Topics</title>
+ <p>This section discusses five topics that are defined in the MUWS specification to support relationships:</p>
+ <ul>
+ <li>
+ <code>Relationship</code>: A topic for a resource property that notifies a consumer about the relationships that a resource knows about.</li>
+ <li>
+ <code>RelationshipCreated</code>: A topic that notifies a consumer when a new relationship is added.</li>
+ <li>
+ <code>RelationshipDeleted</code>: A topic that notifies a consumer when a relationship is deleted.</li>
+ <li>
+ <code>RelationshipAccessCapability</code>: A topic that notifies a consumer that an interaction with a relationship or its participants has occurred.</li>
+ <li>
+ <code>RelationshipResourceCapability</code>: A topic that notifies a consumer when the identity of a relationship changes. This includes the name, type, and
+ participant properties of a relationship.</li>
+ </ul>
+ <p>The <code>Relationship</code> and <code>RelationshipResourceCapability</code> topics are created in the same manner as discussed in the
+ <a href="#act">Adding Capability Topics</a> above. The <code>Relationship</code> topic represents a property changed event that occurs whenever the list of
+ relationships changes. The <code>RelationshipResourceCapability</code> topic represents property changed events whenever either the name, type, or participants for a
+ relationship changes.
+ </p>
+ <p>The <code>RelationshipCreated</code>, <code>RelationshipDeleted</code>, and <code>RelationshipResourceCapability</code> topics are implemented in Muse by
+ default. Therefore, you only need to add these topics to the topic set in your resource class. For example:</p>
+ <source>
+ try {
org.apache.ws.notification.topics.TopicSpace muws2topics = org.apache.ws.muws.MuwsUtils.addRelationshipTopics( getTopicSpaceSet() );
- } catch ( Exception e ) {
- throw new RuntimeException( "Failed to add the MUWS RelationshipAdded/Removed topics to the topic set.", e );
- }
-
- </source>
- <p>For more information Relationships, see the <a href="site:rel">Creating Relationships</a> section.</p>
- </section>
- <section>
- <title>Adding Custom Management Events</title>
- <p>Notifications for custom topics (e.g. my_foo events) can be wrapped as a ManagementEvent notification. While this is not required by the MUWS
- specification, it may give WSDM notification consumers the ability to process your notification, even if they are unaware of the resource as a managed resource.</p>
- <p>Muse provides several utility classes that can be used to define a ManagementEvent Topic and wrap a notification. </p>
-
- <ol>
- <li>Define a ManagementTopic.
- <p>Utilizing ManagementEventTopic provides the framework for publishing ManagementEvents.</p>
- <source>
+ } catch ( Exception e ) {
+ throw new RuntimeException( "Failed to add the MUWS RelationshipAdded/Removed topics to the topic set.", e );
+ }
+
+ </source>
+ <p>For more information Relationships, see the <a href="site:rel">Creating Relationships</a> section.</p>
+ </section>
+ <section>
+ <title>Adding Custom Management Events</title>
+ <p>Notifications for custom topics (e.g. my_foo events) can be wrapped as a ManagementEvent notification. While this is not required by the MUWS
+ specification, it may give WSDM notification consumers the ability to process your notification, even if they are unaware of the resource as a managed resource.</p>
+ <p>Muse provides several utility classes that can be used to define a ManagementEvent Topic and wrap a notification. </p>
+
+ <ol>
+ <li>Define a ManagementTopic.
+ <p>Utilizing ManagementEventTopic provides the framework for publishing ManagementEvents.</p>
+ <source>
//add/create a TopicSpace for your custom Topics
TopicSpace fooTopicSpace = getTopicSpaceSet().addTopicSpace("http://foo/topicspace");
@@ -167,13 +167,13 @@
//make sure to add the ManagementEventTopic to your defined TopicSpace
fooTopicSpace.addTopic(fooCapabilityTopic);
- </source>
- </li>
-
-
- <li>Building a ManagementEvent to publish.
- <p>In cases where you want to emit an event which is not triggered via a ResourcePropertyValueChangeEvent, you will need to explictly build the ManagementEvent and call publish on the Topic. A custom event is wrapped as a ManagementEvent by adding the custom event XML as a child of the ManagementEventType. Below is an example of adding a custom XmlBean-generated object to a ManagementEventType for a custom notification.</p>
- <source>
+ </source>
+ </li>
+
+
+ <li>Building a ManagementEvent to publish.
+ <p>In cases where you want to emit an event which is not triggered via a ResourcePropertyValueChangeEvent, you will need to explictly build the ManagementEvent and call publish on the Topic. A custom event is wrapped as a ManagementEvent by adding the custom event XML as a child of the ManagementEventType. Below is an example of adding a custom XmlBean-generated object to a ManagementEventType for a custom notification.</p>
+ <source>
//define the situation as per spec
Situation situation =
new SituationImpl(new CategoryImpl(MuwsConstants.SITUATION_OTHER));
@@ -189,13 +189,13 @@
//add your custom XmlBean-generated object (i.e. fooXmlBeanGeneratedObject) to the ManagementEvent
XmlBeanUtils.addChildElement(managementEvent, fooXmlBeanGeneratedObject);
- </source>
- </li>
-
-
- <li>Publishing ManagementNotifications.
- <p>The use of ManagementEventTopic as the Topic for exposing Notifications provides the ability to publish ManagementEvents. Once you have built the ManagementEvent notification you would like to send, you will need to publish the event to the ManagementTopic.</p>
- <source>
+ </source>
+ </li>
+
+
+ <li>Publishing ManagementNotifications.
+ <p>The use of ManagementEventTopic as the Topic for exposing Notifications provides the ability to publish ManagementEvents. Once you have built the ManagementEvent notification you would like to send, you will need to publish the event to the ManagementTopic.</p>
+ <source>
//retrieve the Topic from the Resource
ManagementEventTopic fooTopic = (ManagementEventTopic)getTopicSpaceSet().getTopicSpace("http://foo/topicspace").getTopic("FooCapability");
try
@@ -206,12 +206,12 @@
{
//handle exception
}
- </source>
- </li>
-
- </ol>
-
+ </source>
+ </li>
+
+ </ol>
+
- </section>
- </body>
+ </section>
+ </body>
</document>
Modified: webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/relationships.xml
URL: http://svn.apache.org/viewvc/webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/relationships.xml?rev=412161&r1=412160&r2=412161&view=diff
==============================================================================
--- webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/relationships.xml (original)
+++ webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/relationships.xml Tue Jun 6 09:22:08 2006
@@ -2,52 +2,52 @@
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
"http://forrest.apache.org/dtd/document-v20.dtd">
<document>
- <header>
- <title>Creating Relationships</title>
- </header>
- <body>
- <section id="intro">
- <title>Introduction</title>
- <p>This section provides instructions for creating relationships among resources. The resources involved in a relationship are called participants. Each participant
- has a role in the relationship. Resources are related based on their role definitions. Because relationships are specific to a resource management model, no relationship
- types or roles are defined by MUWS and must be defined by the developer.
- </p>
- <p>The examples in this section are taken from the filesystem example. The example demonstrates a simple relationship where a host resource contains a relationship
- with a filesystem resource. The host resource is considered the <code>container</code> in the relationship and the filesystem resource is considered the
- <code>containee</code>. The code to define and setup the relationship is added to the <code>init()</code> method of FilesystemResource.java since the FilesystemResource exposes the Relationship resource property.
- </p>
- <note>For simplicity, the example relationship is defined within the the filesystem resource. However, relationships do not need to be defined as part of the resource
- definition. For example, a resource can be created that is not a manageable resource, but does provide the implementation of the relationships for a particular management
- model.</note>
- </section>
- <section>
- <title>Defining a Relationship</title>
- <p>To define a relationship, you must create a relationship type and any participant types and then assign each participant a role in the in the relationship:</p>
- <ol>
- <li>Create a relationship type.
- <source>
+ <header>
+ <title>Creating Relationships</title>
+ </header>
+ <body>
+ <section id="intro">
+ <title>Introduction</title>
+ <p>This section provides instructions for creating relationships among resources. The resources involved in a relationship are called participants. Each participant
+ has a role in the relationship. Resources are related based on their role definitions. Because relationships are specific to a resource management model, no relationship
+ types or roles are defined by MUWS and must be defined by the developer.
+ </p>
+ <p>The examples in this section are taken from the filesystem example. The example demonstrates a simple relationship where a host resource contains a relationship
+ with a filesystem resource. The host resource is considered the <code>container</code> in the relationship and the filesystem resource is considered the
+ <code>containee</code>. The code to define and setup the relationship is added to the <code>init()</code> method of FilesystemResource.java since the FilesystemResource exposes the Relationship resource property.
+ </p>
+ <note>For simplicity, the example relationship is defined within the the filesystem resource. However, relationships do not need to be defined as part of the resource
+ definition. For example, a resource can be created that is not a manageable resource, but does provide the implementation of the relationships for a particular management
+ model.</note>
+ </section>
+ <section>
+ <title>Defining a Relationship</title>
+ <p>To define a relationship, you must create a relationship type and any participant types and then assign each participant a role in the in the relationship:</p>
+ <ol>
+ <li>Create a relationship type.
+ <source>
org.oasisOpen.docs.wsdm.x2004.x12.muws.wsdmMuwsPart2.RelationshipType relationshipType = null;
relationshipType = prop_relationship.addNewRelationship();
org.oasisOpen.docs.wsdm.x2004.x12.muws.wsdmMuwsPart2.RelationshipTypeType relationshipTypeType = relationshipType.addNewType();
org.apache.ws.util.XmlBeanUtils.addChildElement( relationshipTypeType, new javax.xml.namespace.QName( "http://myns.com/", "ContainedBy", "myns" ) );
- </source>
- </li>
- <li>Create participant types and assign each participant a role in this relationship. In this case, two participant types are created.
- <p><strong>Filesystem Participant Type</strong></p>
- <source>
+ </source>
+ </li>
+ <li>Create participant types and assign each participant a role in this relationship. In this case, two participant types are created.
+ <p><strong>Filesystem Participant Type</strong></p>
+ <source>
org.oasisOpen.docs.wsdm.x2004.x12.muws.wsdmMuwsPart2.RelationshipParticipantType relationshipParticipantType = relationshipType.addNewParticipant();
org.apache.ws.resource.properties.ResourceProperty resourceIdProp = resourcePropertySet.get( FilesystemPropertyQNames.RESOURCEID );
org.apache.xmlbeans.XmlAnyURI resourceId = (org.apache.xmlbeans.XmlAnyURI) resourceIdProp.get( 0 );
relationshipParticipantType.setResourceId( resourceId.getStringValue() );
-relationshipParticipantType.setRole( "urn:containee" );
+relationshipParticipantType.setRole( "urn:containee" );
// NOTE: the below line assumes that the Filesystem resource's EndpointReference field has been initialized
org.xmlsoap.schemas.ws.x2004.x08.addressing.EndpointReferenceType filesystemReference = (org.xmlsoap.schemas.ws.x2004.x08.addressing.EndpointReferenceType) ((org.apache.ws.addressing.XmlBeansEndpointReference)getEndpointReference()).getXmlObject( org.apache.ws.addressing.v2004_08_10.AddressingConstants.NSURI_ADDRESSING_SCHEMA );
relationshipParticipantType.setManageabilityEndpointReferenceArray( new org.xmlsoap.schemas.ws.x2004.x08.addressing.EndpointReferenceType[] { filesystemReference } );
- </source>
- <p><strong>Host Participant Type</strong></p>
- <source>
+ </source>
+ <p><strong>Host Participant Type</strong></p>
+ <source>
org.oasisOpen.docs.wsdm.x2004.x12.muws.wsdmMuwsPart2.RelationshipParticipantType relationshipParticipantType2 = relationshipType.addNewParticipant();
org.apache.ws.resource.ResourceHome hostHome = (org.apache.ws.resource.ResourceHome) new javax.naming.InitialContext( ).lookup( HOST_HOME_LOCATION );
@@ -65,54 +65,54 @@
((org.apache.ws.addressing.XmlBeansEndpointReference)host.getEndpointReference()).getXmlObject( org.apache.ws.addressing.v2004_08_
10.AddressingConstants.NSURI_ADDRESSING_SCHEMA );
relationshipParticipantType.setManageabilityEndpointReferenceArray( new org.xmlsoap.schemas.ws.x2004.x08.addressing.EndpointReferenceType[] { hostReference } );
- </source>
- </li>
- <li>Add properties for the relationship that allow property changed management events
- <source>
+ </source>
+ </li>
+ <li>Add properties for the relationship that allow property changed management events
+ <source>
resourceProperty.add( prop_relationship );
resourceProperty.addChangeListener( relationshipsCapabilityTopic );
- </source>
- <note>See the <a href="site:topics">MUWS-Specific Topics</a> section for more information on relationship topics.</note>
- </li>
- </ol>
- <section>
- <title>Relationship Fields</title>
- <p>A relationship is represented by a set of fields. The fields describe the relationship and are returned as part of a relationship notification. The above example
- implements all the fields that are required. however, the complete list of fields are provided below if you choose to implement them.
- </p>
- <ul>
- <li><code>muws-p2-xs:Name</code>: (optional) A human readable name for a relationship.</li>
- <li><code>muws-p2-xs:Type</code>: (required) The relationship type to which this relationship belongs.</li>
- <li><code>muws-p2-xs:Participant</code>: (required) The information about a participant in the relationship. There must be at least two participants, but there may
- be more than two participants.</li>
- <li><code>muws-p1-xs:ManageabilityEndpointReference</code>: (optional) A reference to a WSDM manageability endpoint.</li>
- <li><code>muws-p1-xs:ResourceID</code>: (optional) A WSDM manageable resource identifier which may be reported by the provider of relationship
- information.</li>
- <li><code>muws-p2-xs:Role</code>: (required) A URI which identifies the role a participant plays in a relationship. A participant role must be unique within a given
- instance of the relationship. The set of valid roles is defined by a relationship type.</li>
- <li><code>muws-p2-xs:Participant/{any}*</code>: (optional) An XML extensibility content which may contain elements that further or otherwise describe a
- participant.</li>
- <li><code>muws-p2-xs:AccessEndpoint</code>: (optional) A reference to a Web service endpoint which provides access to this relationship (if available).</li>
- </ul>
- </section>
- </section>
- <section>
- <title>Relationship Operations and Properties</title>
- <p>The MUWS specification defines one relationship operation (<code>QueryRelationshipsByType</code>) and a single resource property (<code>Relationship</code>)
- that can be used to retrieve relationship information. Both the operation and the resource property must be defined in your MUWS WSDL. If you use the MUWS WSDL
- template, the operation and property are included, but need to be uncommented.
- </p>
- <note>There are also a set of relationship topics that can be used for relationship notifications, see the
- <a href="site:topics">MUWS-Specific Topics</a> section for more information on relationship topics.</note>
- <p>The <code>Relationship</code> resource property can be retrieved using the wsrf-rp:GetResourceProperty or wsrf-rp:GetMultipleResourceProperties operations.
- These operations may be impractical if your management model contains a large number of relationships. As an alternative, the wsrf-rp:QueryResourceProperties operation
- can be used to retrieve individual relationships by using a query expression. The query expression is a XPath expression. For more information about supporting these
- operations in your WS Resource, see the <a href="site:w_compose">WSRF WSDL</a> documentation.
- </p>
- <p>The <code>QueryRelationshipsByType</code> operation is a quick way to retrieve relationships by a known type. For example, the operation is used in the filesystem
- example for the relationship type <code>ContainedBy</code>:
- </p>
- <source><![CDATA[
+ </source>
+ <note>See the <a href="site:topics">MUWS-Specific Topics</a> section for more information on relationship topics.</note>
+ </li>
+ </ol>
+ <section>
+ <title>Relationship Fields</title>
+ <p>A relationship is represented by a set of fields. The fields describe the relationship and are returned as part of a relationship notification. The above example
+ implements all the fields that are required. however, the complete list of fields are provided below if you choose to implement them.
+ </p>
+ <ul>
+ <li><code>muws-p2-xs:Name</code>: (optional) A human readable name for a relationship.</li>
+ <li><code>muws-p2-xs:Type</code>: (required) The relationship type to which this relationship belongs.</li>
+ <li><code>muws-p2-xs:Participant</code>: (required) The information about a participant in the relationship. There must be at least two participants, but there may
+ be more than two participants.</li>
+ <li><code>muws-p1-xs:ManageabilityEndpointReference</code>: (optional) A reference to a WSDM manageability endpoint.</li>
+ <li><code>muws-p1-xs:ResourceID</code>: (optional) A WSDM manageable resource identifier which may be reported by the provider of relationship
+ information.</li>
+ <li><code>muws-p2-xs:Role</code>: (required) A URI which identifies the role a participant plays in a relationship. A participant role must be unique within a given
+ instance of the relationship. The set of valid roles is defined by a relationship type.</li>
+ <li><code>muws-p2-xs:Participant/{any}*</code>: (optional) An XML extensibility content which may contain elements that further or otherwise describe a
+ participant.</li>
+ <li><code>muws-p2-xs:AccessEndpoint</code>: (optional) A reference to a Web service endpoint which provides access to this relationship (if available).</li>
+ </ul>
+ </section>
+ </section>
+ <section>
+ <title>Relationship Operations and Properties</title>
+ <p>The MUWS specification defines one relationship operation (<code>QueryRelationshipsByType</code>) and a single resource property (<code>Relationship</code>)
+ that can be used to retrieve relationship information. Both the operation and the resource property must be defined in your MUWS WSDL. If you use the MUWS WSDL
+ template, the operation and property are included, but need to be uncommented.
+ </p>
+ <note>There are also a set of relationship topics that can be used for relationship notifications, see the
+ <a href="site:topics">MUWS-Specific Topics</a> section for more information on relationship topics.</note>
+ <p>The <code>Relationship</code> resource property can be retrieved using the wsrf-rp:GetResourceProperty or wsrf-rp:GetMultipleResourceProperties operations.
+ These operations may be impractical if your management model contains a large number of relationships. As an alternative, the wsrf-rp:QueryResourceProperties operation
+ can be used to retrieve individual relationships by using a query expression. The query expression is a XPath expression. For more information about supporting these
+ operations in your WS Resource, see the <a href="site:compose">WSRF WSDL</a> documentation.
+ </p>
+ <p>The <code>QueryRelationshipsByType</code> operation is a quick way to retrieve relationships by a known type. For example, the operation is used in the filesystem
+ example for the relationship type <code>ContainedBy</code>:
+ </p>
+ <source><![CDATA[
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:fs="http://ws.apache.org/resource/example/filesystem"
xmlns:muws-p2-xs="http://docs.oasis-open.org/wsdm/2004/12/muws/wsdm-muws-part2.xsd">
@@ -127,8 +127,8 @@
<muws-p2-xs:QueryRelationshipsByType xmlns:myns="http://myns.com/"><muws-p2-xs:RequestedType>myns:ContainedBy</muws-p2-xs:RequestedType></muws-p2-
xs:QueryRelationshipsByType>
</Body>
-</Envelope>]]>
- </source>
- </section>
- </body>
+</Envelope>]]>
+ </source>
+ </section>
+ </body>
</document>
Modified: webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/wsdl.xml
URL: http://svn.apache.org/viewvc/webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/wsdl.xml?rev=412161&r1=412160&r2=412161&view=diff
==============================================================================
--- webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/wsdl.xml (original)
+++ webservices/muse/branches/1.0/src/site/content/xdocs/muse/dev_guide/wsdl.xml Tue Jun 6 09:22:08 2006
@@ -2,100 +2,100 @@
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN"
"http://forrest.apache.org/dtd/document-v20.dtd">
<document>
- <header>
- <title>Composing a MUWS WSDL</title>
- </header>
- <body>
- <section>
- <title>Using the MUWS Template</title>
- <p>The Web Services Description Language (WSDL) is used to expose resources and notifications as WS-Resources and also includes optional fields, operations, and
- notifications that may be included in the definition of a resource that allow management applications to manage the resource in a standardized fashion. The WSDL must
- conform to the conventions as described in the MUWS specification as well as the conventions described in the <a href="ext:spec">WSRF</a> and <a href="ext:wsn">WSN</a>
- Specifications. To make it easier to write a MUWS WSDL, Muse provides a template WSDL that can be used as a starting point. The template saves a good deal of time
- and is less error-prone than writing a MUWS-compliant WSDL from scratch.
- </p>
- <p>To use the template:</p>
- <ol>
- <li>Using a text or XML editor, open <code>INSTALL_DIR/template/_TEMPLATE_.wsdl</code>.</li>
- <li>Save the file with a new name (e.g., <em>nameOfYourService</em>.wsdl).</li>
- <li>Modify your WSDL based on the instructions in the template and the information below.</li>
- </ol>
- <warning>Do not modify the original template file.</warning>
- </section>
- <section>
- <title>Defining the MUWS PortType</title>
- <p>A MUWS WSDL should contain only one portType. The portType aggregates operations from the WSRF, WSN, and MUWS specification-defined portTypes
- as well as custom resource-specific operations. If you copied the WSDL template file as described above, your WSDL file
- already contains a MUWS-compliant portType. You simply have to rename the portType (<code>MyPortType</code>) and the binding (MySoapHttpBinding) and
- uncomment the blocks corresponding to whichever optional portTypes you want your WS-Resource to support.
- </p>
- <note>The WSRF portTypes - from WS-ResourceProperties (WSRF-RP) and WS-ResourceLifetime (WSRF-RL)- and their associated operations are described in the Apache
- WSRF <a href="site:w_compose">WSDL Documentation</a>. The instructions include defining the resource properties document, custom properties, and custom
- operations. The WSN portTypes - from WS-BaseNotification - and their associated operations are described in the Apache Pubscribe
- <a href="site:p_compose">WSDL Documentation</a>. The instructions include defining notification producers, notification topics, and notification consumers.
- </note>
- <section>
- <title>MUWS PortTypes</title>
- <p>The MUWS specification defines eight portTypes. However, only the <code>Relationships</code> portType contains an operation that can be added to the portType of your
- WSDL. The other portTypes are used to organize and expose resource properties and need to be defined in the <code>type</code> section of a WSDL as you would
- any other resource property. Among these properties, the ResourceID property is required and must be included in a MUWS compliant WSDL.
- </p>
- <table>
- <tr>
- <th>PortType</th>
- <th>Operations</th>
- <th>Properties</th>
- </tr>
- <tr>
- <td>Identity</td>
- <td/>
- <td>ResourceId</td>
- </tr>
- <tr>
- <td>ManageabilityCharacteristics</td>
- <td/>
- <td>ManageabilityCapability</td>
- </tr>
- <tr>
- <td>CorrelatableProperties</td>
- <td/>
- <td>CorrelatableProperties</td>
- </tr>
- <tr>
- <td>Description</td>
- <td/>
- <td>Caption, Description, Version</td>
- </tr>
- <tr>
- <td>OperationalStatus</td>
- <td/>
- <td>OperationalStatus</td>
- </tr>
- <tr>
- <td>Metrics</td>
- <td/>
- <td>CurrentTime</td>
- </tr>
- <tr>
- <td>Relationships</td>
- <td>QueryRelationshipsByType</td>
- <td>Relationship</td>
- </tr>
- <tr>
- <td>RelationshipResource</td>
- <td/>
- <td>Name, Type, Participant</td>
- </tr>
- </table>
- </section>
- <section>
- <title>Metadata Operations</title>
- <p>The template contains two operations that are not defined by the WSRF, WSN or WSDM specification that can be used in your service to retrieve metadata
- about your services. The operations and messages are defined in the
- <a href="http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-metadataexchange.pdf">WS-Metadata Exchange</a> specification defined by Microsoft and other industry
- contributors. For instructions on providing metadata about your service, see the <a href="site:w_metadata">Adding Service Metadata</a> section of the Apache
- WSRF documentation.</p>
- </section>
- </section>
- </body>
+ <header>
+ <title>Composing a MUWS WSDL</title>
+ </header>
+ <body>
+ <section>
+ <title>Using the MUWS Template</title>
+ <p>The Web Services Description Language (WSDL) is used to expose resources and notifications as WS-Resources and also includes optional fields, operations, and
+ notifications that may be included in the definition of a resource that allow management applications to manage the resource in a standardized fashion. The WSDL must
+ conform to the conventions as described in the MUWS specification as well as the conventions described in the <a href="ext:spec">WSRF</a> and <a href="ext:wsn">WSN</a>
+ Specifications. To make it easier to write a MUWS WSDL, Muse provides a template WSDL that can be used as a starting point. The template saves a good deal of time
+ and is less error-prone than writing a MUWS-compliant WSDL from scratch.
+ </p>
+ <p>To use the template:</p>
+ <ol>
+ <li>Using a text or XML editor, open <code>INSTALL_DIR/template/_TEMPLATE_.wsdl</code>.</li>
+ <li>Save the file with a new name (e.g., <em>nameOfYourService</em>.wsdl).</li>
+ <li>Modify your WSDL based on the instructions in the template and the information below.</li>
+ </ol>
+ <warning>Do not modify the original template file.</warning>
+ </section>
+ <section>
+ <title>Defining the MUWS PortType</title>
+ <p>A MUWS WSDL should contain only one portType. The portType aggregates operations from the WSRF, WSN, and MUWS specification-defined portTypes
+ as well as custom resource-specific operations. If you copied the WSDL template file as described above, your WSDL file
+ already contains a MUWS-compliant portType. You simply have to rename the portType (<code>MyPortType</code>) and the binding (MySoapHttpBinding) and
+ uncomment the blocks corresponding to whichever optional portTypes you want your WS-Resource to support.
+ </p>
+ <note>The WSRF portTypes - from WS-ResourceProperties (WSRF-RP) and WS-ResourceLifetime (WSRF-RL)- and their associated operations are described in the Apache
+ WSRF <a href="site:compose">WSDL Documentation</a>. The instructions include defining the resource properties document, custom properties, and custom
+ operations. The WSN portTypes - from WS-BaseNotification - and their associated operations are described in the Apache Pubscribe
+ <a href="site:p_compose">WSDL Documentation</a>. The instructions include defining notification producers, notification topics, and notification consumers.
+ </note>
+ <section>
+ <title>MUWS PortTypes</title>
+ <p>The MUWS specification defines eight portTypes. However, only the <code>Relationships</code> portType contains an operation that can be added to the portType of your
+ WSDL. The other portTypes are used to organize and expose resource properties and need to be defined in the <code>type</code> section of a WSDL as you would
+ any other resource property. Among these properties, the ResourceID property is required and must be included in a MUWS compliant WSDL.
+ </p>
+ <table>
+ <tr>
+ <th>PortType</th>
+ <th>Operations</th>
+ <th>Properties</th>
+ </tr>
+ <tr>
+ <td>Identity</td>
+ <td/>
+ <td>ResourceId</td>
+ </tr>
+ <tr>
+ <td>ManageabilityCharacteristics</td>
+ <td/>
+ <td>ManageabilityCapability</td>
+ </tr>
+ <tr>
+ <td>CorrelatableProperties</td>
+ <td/>
+ <td>CorrelatableProperties</td>
+ </tr>
+ <tr>
+ <td>Description</td>
+ <td/>
+ <td>Caption, Description, Version</td>
+ </tr>
+ <tr>
+ <td>OperationalStatus</td>
+ <td/>
+ <td>OperationalStatus</td>
+ </tr>
+ <tr>
+ <td>Metrics</td>
+ <td/>
+ <td>CurrentTime</td>
+ </tr>
+ <tr>
+ <td>Relationships</td>
+ <td>QueryRelationshipsByType</td>
+ <td>Relationship</td>
+ </tr>
+ <tr>
+ <td>RelationshipResource</td>
+ <td/>
+ <td>Name, Type, Participant</td>
+ </tr>
+ </table>
+ </section>
+ <section>
+ <title>Metadata Operations</title>
+ <p>The template contains two operations that are not defined by the WSRF, WSN or WSDM specification that can be used in your service to retrieve metadata
+ about your services. The operations and messages are defined in the
+ <a href="http://msdn.microsoft.com/library/en-us/dnglobspec/html/ws-metadataexchange.pdf">WS-Metadata Exchange</a> specification defined by Microsoft and other industry
+ contributors. For instructions on providing metadata about your service, see the <a href="site:metadata">Adding Service Metadata</a> section of the Apache
+ WSRF documentation.</p>
+ </section>
+ </section>
+ </body>
</document>
---------------------------------------------------------------------
To unsubscribe, e-mail: muse-commits-unsubscribe@ws.apache.org
For additional commands, e-mail: muse-commits-help@ws.apache.org