Dynamically register notification producers

[Jan Torben Heuer-4]

Hi,

I'd like to create an interface to register notification producers at runtime,
similar to subscribers - create, renew, expire and delete are mandatory. Thus
I would ask if I could reuse some of the SubscriptionManager code or if
g.apache.muse.ws.dm.muws.adv.impl.AbstractAdvertisement already did it. I
read the code but didn't understand exactly what it is doing.

Thanks,

Jan
--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...

[Chris.Twiner]

Hi Jan,

It depends on wether they will be instances of the same resource type or are meant to be seperate types.  You can already create multiple producers by just creating a new instance of an existing resource.  If you want a large number of instances it is perhaps better to use the proxying technique (found here http://www.ibm.com/developerworks/autonomic/library/ac-muse.html) but this promotes problems for subscriptions.  If the latter link is an interesting approach for you then I an send some code to publish to the correct NotificationProducer when working with proxies.

If its creating seperate types of resources at runtime then there is no support for it that I know off (although similar support is scheduled for 2.3).

cheers,
Chris

-----Original Message-----
From: Jan Torben Heuer [mailto:jan.heuer@...]
Sent: Wednesday, May 14, 2008 10:51 AM
To: muse-user@...
Subject: Dynamically register notification producers

Hi,

I'd like to create an interface to register notification producers at runtime, similar to subscribers - create, renew, expire and delete are mandatory. Thus I would ask if I could reuse some of the SubscriptionManager code or if g.apache.muse.ws.dm.muws.adv.impl.AbstractAdvertisement already did it. I read the code but didn't understand exactly what it is doing.

Thanks,

Jan
--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...

[Jan Torben Heuer-4]

On Wednesday 14 May 2008 17:11:28 Chris.Twiner@... wrote:

Hi,

> It depends on wether they will be instances of the same resource type or
> are meant to be seperate types.  You can already create multiple producers
They are different Producers with different Topics

> by just creating a new instance of an existing resource.  If you want a
> large number of instances it is perhaps better to use the proxying
> technique (found here
> http://www.ibm.com/developerworks/autonomic/library/ac-muse.html) but this
> promotes problems for subscriptions.  If the latter link is an interesting
> approach for you then I an send some code to publish to the correct
> NotificationProducer when working with proxies.
Hmm, I think it is not really what I need.

I want to create a SOAP interface like the SubscriptionManager has to allow
register, cancel and renew of producers.

> If its creating seperate types of resources at runtime then there is no
> support for it that I know off (although similar support is scheduled for
> 2.3).
Is there already somethink in trunk?

Jan
--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

[Chris.Twiner]

Hi,

If the producers have the same interface for the resource they represent then I believe that is what you want.

A Muse SubscriptionManager simply handles subscriptions for a given producer, it can't create new producers.  Each new producer would require a resource to go against it, hence the proxy link I sent.  Unless I have completely missed want you want (which is always possible) I would suggest:

- create a simple resource type that meets all of your needs for your dynamic producers
- create a simple resource factory, as per the link, which exposes register, cancel and renew of producers (see pullpoint for an example on how this works)
        - register creates a new resource and registers its epr with the resource router
        - cancel removes that resource (and any linked subscriptions) from the resource router

Unfortunately I can't guess what renew means in this context.  (perhaps canceled producers are merely inactive?).

Re the trunk change this is truly only interesting if you are planning on having different interfaces for your resources.

cheers,
Chris

-----Original Message-----
From: Jan Torben Heuer [mailto:jan.heuer@...]
Sent: Thursday, May 15, 2008 3:45 PM
To: muse-user@...
Subject: Re: Dynamically register notification producers

On Wednesday 14 May 2008 17:11:28 Chris.Twiner@... wrote:

Hi,

> It depends on wether they will be instances of the same resource type
> or are meant to be seperate types.  You can already create multiple
> producers
They are different Producers with different Topics

> by just creating a new instance of an existing resource.  If you want
> a large number of instances it is perhaps better to use the proxying
> technique (found here
> http://www.ibm.com/developerworks/autonomic/library/ac-muse.html) but
> this promotes problems for subscriptions.  If the latter link is an
> interesting approach for you then I an send some code to publish to
> the correct NotificationProducer when working with proxies.
Hmm, I think it is not really what I need.

I want to create a SOAP interface like the SubscriptionManager has to allow register, cancel and renew of producers.

> If its creating seperate types of resources at runtime then there is
> no support for it that I know off (although similar support is
> scheduled for 2.3).
Is there already somethink in trunk?

Jan
--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...

[Vinh Nguyen (vinguye2)]

Hi,
Chris is correct.  Jan, I think what you are looking for is a resource which creates other producer resources.  In this case, you need to create a custom resource (i.e. call it FactoryService) which exposes some operation (i.e. createProducer()).  You also need another custom resource that implements wsn:NotificationProducer (i.e. call it ProducerResource).

So when FactoryService.createProducer() is called, it must dynamically create a new instance of ProducerResource and pass the EPR back to the client.  Then the client can Subscribe/Unsubscribe directly on that new ProducerResource instance.

This follows the facade pattern.  Take a look at the "wsrf" sample which does something similar.

Hope this helps...
-Vinh
 

-----Original Message-----
From: Chris.Twiner@... [mailto:Chris.Twiner@...]
Sent: Thursday, May 15, 2008 7:15 AM
To: muse-user@...
Subject: RE: Dynamically register notification producers

Hi,

If the producers have the same interface for the resource they represent then I believe that is what you want.

A Muse SubscriptionManager simply handles subscriptions for a given producer, it can't create new producers.  Each new producer would require a resource to go against it, hence the proxy link I sent.  Unless I have completely missed want you want (which is always possible) I would suggest:

- create a simple resource type that meets all of your needs for your dynamic producers
- create a simple resource factory, as per the link, which exposes register, cancel and renew of producers (see pullpoint for an example on how this works)
        - register creates a new resource and registers its epr with the resource router
        - cancel removes that resource (and any linked subscriptions) from the resource router

Unfortunately I can't guess what renew means in this context.  (perhaps canceled producers are merely inactive?).

Re the trunk change this is truly only interesting if you are planning on having different interfaces for your resources.

cheers,
Chris

-----Original Message-----
From: Jan Torben Heuer [mailto:jan.heuer@...]
Sent: Thursday, May 15, 2008 3:45 PM
To: muse-user@...
Subject: Re: Dynamically register notification producers

On Wednesday 14 May 2008 17:11:28 Chris.Twiner@... wrote:

Hi,

> It depends on wether they will be instances of the same resource type
> or are meant to be seperate types.  You can already create multiple
> producers
They are different Producers with different Topics

> by just creating a new instance of an existing resource.  If you want
> a large number of instances it is perhaps better to use the proxying
> technique (found here
> http://www.ibm.com/developerworks/autonomic/library/ac-muse.html) but
> this promotes problems for subscriptions.  If the latter link is an
> interesting approach for you then I an send some code to publish to
> the correct NotificationProducer when working with proxies.
Hmm, I think it is not really what I need.

I want to create a SOAP interface like the SubscriptionManager has to allow register, cancel and renew of producers.

> If its creating seperate types of resources at runtime then there is
> no support for it that I know off (although similar support is
> scheduled for 2.3).
Is there already somethink in trunk?

Jan
--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...


---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...

[Jan Torben Heuer-4]

On Thursday 15 May 2008 20:06:44 Vinh Nguyen (vinguye2) wrote:

Hallo,

I started to implement the Producer-creator. It will still take some time for
me to understand how muse works, but maybe you can tell me if I got it
correctly:

> Chris is correct.  Jan, I think what you are looking for is a resource
> which creates other producer resources.  In this case, you need to create a
> custom resource (i.e. call it FactoryService) which exposes some operation
> (i.e. createProducer()).  You also need another custom resource that

The code was taken form the pullpoint class you mentioned:

public class MyAdvertisementCapability extends AbstractWsResourceCapability
implements AdvertisementCapability {

// is called to create a new producer
        public EndpointReference addAdvertisement() throws SoapFault {
                ResourceManager manager = getResource().getResourceManager();

                String endpoint = getAdvertiseContextPath();
                WsResource advertise = null;

                advertise = (WsResource) manager.createResource(endpoint);
               
                EndpointReference epr = advertise.getEndpointReference();

        return epr;
        }

        @Override
        public void initialize() throws SoapFault {
                super.initialize();

                //
                // find pullpoint resource type so we can create instances of it
                // in createPullPoint()
                //
                ResourceManager manager = getResource().getResourceManager();
                advertisePath =
manager.getResourceContextPath(AdvertisementCapability.class);
        }
}

Just to make things clear: If I set up the muse.xml so that the wsdl of my
advertise maps to the AdvertisementCapability.class, then this class above is
called?

The next step would be then to create the notificationproducer and put the EPR
into the response?

> implements wsn:NotificationProducer (i.e. call it ProducerResource).
>
> So when FactoryService.createProducer() is called, it must dynamically
> create a new instance of ProducerResource and pass the EPR back to the
> client.  Then the client can Subscribe/Unsubscribe directly on that new
> ProducerResource instance.


Thanks again,


(Chris, I have your link still in mind, but It may be useful for me to start
from scratch at least for a prototype in order to understand how muse works)


Jan
--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

[Chris.Twiner]

Hi Jan,

The approach seems great, just don't forget you must have a different endpoint for each created resource, using reference parameters.  The link I sent covers that but it makes a lot of sense to play with it as a learning tool :-)

cheers,
Chris

-----Original Message-----
From: Jan Torben Heuer [mailto:jan.heuer@...]
Sent: Wednesday, May 21, 2008 1:23 PM
To: muse-user@...
Subject: Re: Dynamically register notification producers

On Thursday 15 May 2008 20:06:44 Vinh Nguyen (vinguye2) wrote:

Hallo,

I started to implement the Producer-creator. It will still take some time for me to understand how muse works, but maybe you can tell me if I got it
correctly:

> Chris is correct.  Jan, I think what you are looking for is a resource
> which creates other producer resources.  In this case, you need to
> create a custom resource (i.e. call it FactoryService) which exposes
> some operation (i.e. createProducer()).  You also need another custom
> resource that

The code was taken form the pullpoint class you mentioned:

public class MyAdvertisementCapability extends AbstractWsResourceCapability implements AdvertisementCapability {

// is called to create a new producer
        public EndpointReference addAdvertisement() throws SoapFault {
                ResourceManager manager = getResource().getResourceManager();

                String endpoint = getAdvertiseContextPath();
                WsResource advertise = null;

                advertise = (WsResource) manager.createResource(endpoint);
               
                EndpointReference epr = advertise.getEndpointReference();

        return epr;
        }

        @Override
        public void initialize() throws SoapFault {
                super.initialize();

                //
                // find pullpoint resource type so we can create instances of it
                // in createPullPoint()
                //
                ResourceManager manager = getResource().getResourceManager();
                advertisePath =
manager.getResourceContextPath(AdvertisementCapability.class);
        }
}

Just to make things clear: If I set up the muse.xml so that the wsdl of my advertise maps to the AdvertisementCapability.class, then this class above is called?

The next step would be then to create the notificationproducer and put the EPR into the response?

> implements wsn:NotificationProducer (i.e. call it ProducerResource).
>
> So when FactoryService.createProducer() is called, it must dynamically
> create a new instance of ProducerResource and pass the EPR back to the
> client.  Then the client can Subscribe/Unsubscribe directly on that
> new ProducerResource instance.


Thanks again,


(Chris, I have your link still in mind, but It may be useful for me to start from scratch at least for a prototype in order to understand how muse works)


Jan
--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...

[Jan Torben Heuer-4]

On Wednesday 21 May 2008 15:26:05 Chris.Twiner@... wrote:

Hallo,


> The approach seems great, just don't forget you must have a different
> endpoint for each created resource, using reference parameters.  The link I
> sent covers that but it makes a lot of sense to play with it as a learning

I had a look at how subscriptions work. But I cannot find a code exampe on how
a ERP is actually created. Can you give me a hint? For example the
SimpleNotificationProducer as a method #subscribe. But that method get the
ERP as parameter, so It was already created before.

What did I miss?

> public class MyAdvertisementCapability extends AbstractWsResourceCapability
> implements AdvertisementCapability {
>
> // is called to create a new producer
> public EndpointReference addAdvertisement() throws SoapFault {
> ResourceManager manager = getResource().getResourceManager();
>
> String endpoint = getAdvertiseContextPath();
> WsResource advertise = null;
>
> advertise = (WsResource) manager.createResource(endpoint);
>
>        EndpointReference epr = advertise.getEndpointReference();
>
>         return epr;
> }
>
> @Override
> public void initialize() throws SoapFault {
> super.initialize();
>
> //
> // find pullpoint resource type so we can create instances of it
> // in createPullPoint()
> //
> ResourceManager manager = getResource().getResourceManager();
> advertisePath =
> manager.getResourceContextPath(AdvertisementCapability.class);
> }
> }

Jan

--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

[Chris.Twiner]

createResource automatically provides an epr thats unique for you but you will have no control over its content (by default).  It is also, by default, not thread safe, so if you have multiple requests using createResource you will have a problem (you can override this for a given resource with by implementing ResourceIdFactory and configuring with java-id-factory-class).

Also it seems that you aren't, in this example, creating the resource based on any criteria.  Will there be something set in the resource later before subscriptions are made?  If not then I'm not sure what benefit there is to creating multiple NotificationProducers when multiple subscriptions would seem to suffice.

Although its very likely I've missed something in your requirements :-)

-----Original Message-----
From: Jan Torben Heuer [mailto:jan.heuer@...]
Sent: Wednesday, May 21, 2008 5:09 PM
To: muse-user@...
Subject: Re: Dynamically register notification producers

On Wednesday 21 May 2008 15:26:05 Chris.Twiner@... wrote:

Hallo,


> The approach seems great, just don't forget you must have a different
> endpoint for each created resource, using reference parameters.  The
> link I sent covers that but it makes a lot of sense to play with it as
> a learning

I had a look at how subscriptions work. But I cannot find a code exampe on how a ERP is actually created. Can you give me a hint? For example the SimpleNotificationProducer as a method #subscribe. But that method get the ERP as parameter, so It was already created before.

What did I miss?

> public class MyAdvertisementCapability extends
> AbstractWsResourceCapability implements AdvertisementCapability {
>
> // is called to create a new producer
> public EndpointReference addAdvertisement() throws SoapFault {
> ResourceManager manager = getResource().getResourceManager();
>
> String endpoint = getAdvertiseContextPath();
> WsResource advertise = null;
>
> advertise = (WsResource) manager.createResource(endpoint);
>
>        EndpointReference epr = advertise.getEndpointReference();
>
>         return epr;
> }
>
> @Override
> public void initialize() throws SoapFault {
> super.initialize();
>
> //
> // find pullpoint resource type so we can create instances of it
> // in createPullPoint()
> //
> ResourceManager manager = getResource().getResourceManager();
> advertisePath =
> manager.getResourceContextPath(AdvertisementCapability.class);
> }
> }

Jan

--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...

[Lenni Madsen]

Hi Jan

While I'm not sure the fits your question entirely, it does give a small
view of the EPR creating and the ability you've at modifying it
programmatically during creation of a resource instance.

public EndpointReference createWithEprOperation(String ResourceID, String
ResourceType) throws Exception    {
    System.out.println("createWithEprOperation::start");
    ResourceManager manager = getResource().getResourceManager();
                EndpointReference epr = null;
                try {
                        Resource next =
manager.createResource(ResourceType);
                        epr = next.getEndpointReference();
                        epr.removeParameter(new
QName("http://ws.apache.org/muse/addressing", "ResourceId", "muse-wsa"));
                        epr.addParameter(new
QName("http://ws.apache.org/muse/addressing", "ResourceId", "muse-wsa"),
ResourceID);
                        next.setEndpointReference(epr);
                        // don't change the EPR after the following
// step
                        next.initialize();
                        manager.addResource(epr, next);
                } catch (Throwable error){
                        error.printStackTrace();
                }
                System.out.println("createWithEprOperation::stop");
                return epr;
    }

Be sure to get it a thorough test as I pulled this from some unused code in
an old project, but it should be functional.

Of course this function comes from a generic factory, where the type of
resource you wish to instantiate is referenced by ResourceType. In my case I
had two different wsdl's in my project, one for the factory and one for the
Resource, but as long as the ResourceType stays unique it should scale.

/Lenni

-----Oprindelig meddelelse-----
Fra: Chris.Twiner@... [mailto:Chris.Twiner@...]
Sendt: 22. maj 2008 08:46
Til: muse-user@...
Emne: RE: Dynamically register notification producers

createResource automatically provides an epr thats unique for you but you
will have no control over its content (by default).  It is also, by default,
not thread safe, so if you have multiple requests using createResource you
will have a problem (you can override this for a given resource with by
implementing ResourceIdFactory and configuring with java-id-factory-class).

Also it seems that you aren't, in this example, creating the resource based
on any criteria.  Will there be something set in the resource later before
subscriptions are made?  If not then I'm not sure what benefit there is to
creating multiple NotificationProducers when multiple subscriptions would
seem to suffice.

Although its very likely I've missed something in your requirements :-)

-----Original Message-----
From: Jan Torben Heuer [mailto:jan.heuer@...]
Sent: Wednesday, May 21, 2008 5:09 PM
To: muse-user@...
Subject: Re: Dynamically register notification producers

On Wednesday 21 May 2008 15:26:05 Chris.Twiner@... wrote:

Hallo,


> The approach seems great, just don't forget you must have a different
> endpoint for each created resource, using reference parameters.  The
> link I sent covers that but it makes a lot of sense to play with it as
> a learning

I had a look at how subscriptions work. But I cannot find a code exampe on
how a ERP is actually created. Can you give me a hint? For example the
SimpleNotificationProducer as a method #subscribe. But that method get the
ERP as parameter, so It was already created before.

What did I miss?


> public class MyAdvertisementCapability extends
> AbstractWsResourceCapability implements AdvertisementCapability {
>
> // is called to create a new producer
> public EndpointReference addAdvertisement() throws SoapFault {
> ResourceManager manager =
getResource().getResourceManager();

>
> String endpoint = getAdvertiseContextPath();
> WsResource advertise = null;
>
> advertise = (WsResource) manager.createResource(endpoint);
>
>        EndpointReference epr = advertise.getEndpointReference();
>
>         return epr;
> }
>
> @Override
> public void initialize() throws SoapFault {
> super.initialize();
>
> //
> // find pullpoint resource type so we can create instances

of it
> // in createPullPoint()
> //
> ResourceManager manager =
getResource().getResourceManager();
> advertisePath =
> manager.getResourceContextPath(AdvertisementCapability.class);
> }
> }

Jan

--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...



---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...

[Jan Torben Heuer-4]

On Thursday 22 May 2008 08:45:33 Chris.Twiner@... wrote:

Hallo,

> Also it seems that you aren't, in this example, creating the resource based
> on any criteria.  Will there be something set in the resource later before
> subscriptions are made?  If not then I'm not sure what benefit there is to
> creating multiple NotificationProducers when multiple subscriptions would
> seem to suffice.
>
> Although its very likely I've missed something in your requirements :-)

Ok, I'm going to provide further details:

I want to use muse as a dispatcher of sensor events. On the one hand, there
will be subscribers. This part is already implemented in muse. On the other
hand, Sensors can advertise themselves:
They provide their topic, name, description, ... which clients use for xpath
filtering, later. It'll look like:

<wsbn:RegisterPublisher>

   <wsbn:Topic dialect
= “http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple”>
     <tsas:Measurements>mytopic</tsas:Measurements>
   </wsbn:Topic>

   <sml:SensorML>
    <member xlink:role="urn:ogc:def:role:OGC:sensorSystem">
        <System gml:id="urn:x-ogc:object:sensor:IFGI:Temp:1">
            <gml:description> ... </gml:description>
            <gml:name> ... </gml:name>
        ...
     </System>
    </member>
 </sml:SensorML>
</wsbn:RegisterPublisher>



Jan
--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

[Chris.Twiner]

Thanks for the clarification Jan :-)  If I'm understanding this correctly each sensor will register itself with Muse somehow.  It seems logical that this is the point where the resource is created (or indeed proxied), and that something in the resource parameters indicates to which sensor you are sending it for example <System gml:id="urn:x-ogc:object:sensor:IFGI:Temp:1">.

Given that it seems a perfect approach and fits closely with the existing pull point code (minus the whole subscribe * thing).

-----Original Message-----
From: Jan Torben Heuer [mailto:jan.heuer@...]
Sent: Friday, May 23, 2008 7:14 PM
To: muse-user@...
Subject: Re: Dynamically register notification producers

On Thursday 22 May 2008 08:45:33 Chris.Twiner@... wrote:

Hallo,

> Also it seems that you aren't, in this example, creating the resource
> based on any criteria.  Will there be something set in the resource
> later before subscriptions are made?  If not then I'm not sure what
> benefit there is to creating multiple NotificationProducers when
> multiple subscriptions would seem to suffice.
>
> Although its very likely I've missed something in your requirements
> :-)

Ok, I'm going to provide further details:

I want to use muse as a dispatcher of sensor events. On the one hand, there will be subscribers. This part is already implemented in muse. On the other hand, Sensors can advertise themselves:
They provide their topic, name, description, ... which clients use for xpath filtering, later. It'll look like:

<wsbn:RegisterPublisher>

   <wsbn:Topic dialect
= "http://docs.oasis-open.org/wsn/t-1/TopicExpression/Simple">
     <tsas:Measurements>mytopic</tsas:Measurements>
   </wsbn:Topic>

   <sml:SensorML>
    <member xlink:role="urn:ogc:def:role:OGC:sensorSystem">
        <System gml:id="urn:x-ogc:object:sensor:IFGI:Temp:1">
            <gml:description> ... </gml:description>
            <gml:name> ... </gml:name>
        ...
     </System>
    </member>
 </sml:SensorML>
</wsbn:RegisterPublisher>



Jan
--
Jan Torben Heuer Institute for Geoinformatics
jan.heuer@... Robert-Koch-Strasse 26-28
[phone] 48151 Münster, Germany

---------------------------------------------------------------------
To unsubscribe, e-mail: muse-user-unsubscribe@...
For additional commands, e-mail: muse-user-help@...