synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mukund Balasubramanian" <muk...@infravio.com>
Subject RE: SynapseObject - Reminder...
Date Thu, 02 Mar 2006 08:55:50 GMT
Paul:

 

I don't believe this proposal is in any way in conflict with usage of
true XML. It is merely to provide structure to an otherwise flat list of
name value pairs. 

 

If you look at an average WSDD document (which supports only name value
pairs) for the X-Broker, it looks phenomenally complex just because of
the need to nest objects into one another. 

 

Also, the name-value pair concept has its uses - most importantly that
as a simple meta-model, it is supported by a wide variety of platforms
such as registries (tModels) and also property files.

 

Please see my comments below in response to your specific queries:

 

  _____  

From: Paul Fremantle [mailto:pzfreo@gmail.com] 
Sent: Thursday, March 02, 2006 5:27 AM
To: synapse-dev@ws.apache.org
Subject: Re: SynapseObject - Reminder...

 

I still have problems with the SynapseObject proposal.

1) I think it is much simpler for administrators to use what I call
"real" XML. In other words, if there is a ClientIdentification mediator,
then we either use simpler type properties to configure it, or we create
a new schema that defines the configuration of the ClientIdentification
metadata. This has the benefit that you can use Schema validators to
validate the XML as well as Schema aware editors to generate a GUI for
editing the data. 

ClientIdentification can still be a structured object and not
necessarily a flat list. Just analyze the use case for a multi-object
array of Clients with more than one identification scheme. I agree with
the schema validation argument but the onus of creating XML Schema's for
property formats, configuring the namespace and schemaLocation to
validate and taking on the responsibility of Object Marshalling and
Mapping is just too high.



2) To make it easier for Mediator developers the schema can be converted
into a Java object using ADB and XSD2Java. We can probably do this
automatically using reflection if the bean is not a simple type but
implements the ADB interface. 

Of course they can. It just might not be worth the effort. 



3) If this model is not appropriate, you can easily write a
MediatorFactory (aka ProcessorConfigurator) that parses the XML and
populates the mediators data.

Again, the onus of reading and manipulating the DOM lying on the
developer is not something I think is necessary.



4) I personally haven't yet understood the use case for global data, but
if there is one, then we should simply have a single model for
referencing XML fragments. That way if two mediators want to use the
same configuration data, then they can both refer to the same element.
In fact, we could do this using the Resource model we already have. 

I know that what we have here is two different views on how to use XML.
The SO proposal uses a generic XML format to store specific data, and
therefore loses out on all the useful stuff that XML provides natively -
schema validation, readability, tool support, etc. 

The truth is that this is useful only as an EXTENSION to the NV model
and NOT as a replacement for XML :-) 

 



Paul



On 3/1/06, Vikas <vikas@infravio.com> wrote:

Hi...

 

1) If main processor comes across an xml fragment of type SynapseObject
in synapse.xml it needs to call a processor           

    (SynapseObjectProcessor maybe) to convert the xml fragment into a
SynapseObject instance.

 

2) But we need a place holder for this instance, now the question is
where to put it for further reference.

>From a scoping perspective, we can scope it at two levels 

a) specific to a mediator

If it is specific to a mediator then we should extend the current
mediator to have a member variable of type hashtable and appropriate
getters and setters. We can  push the SynapseObject in the hashtable,
this also allows the user to use any kind of object if in case they
choose not to you SynapseObject.

b) global.

For global usages we can put synapseObject instances in the
SynapseEnvironment which can be used by any part of synapse.   

 

The getters and setters might look up the hierarchy... Mediator's
hashtable, then environment...

 

~Vikas.

	----- Original Message ----- 

	From: Saminda Abeyruwan <mailto:samindaa@gmail.com>  

	To: synapse-dev@ws.apache.org 

	Sent: Tuesday, February 28, 2006 11:20 AM

	Subject: Re: SynapseObject - Reminder...

	 

	Hi,
	
	Please be kind enough clarify the following small questions.
	
	1. As every element <foo/> in the synapse.xml maps to a
FooMediator, how does <foo/> gets the info out of <synapseobject/>. ex:
does it as follows?
	<foo>
	    <synapseobject name="xx">
	            <synapseobject xx="xx"/> [1..n]
	     </synapseobject>
	</foo>
	
	2. Does every mediator get a reference to <synapseobject/> or a
selected few such as <servicemediator/> or <classmediator/> get the
reference to <synapseobject/>. 
	3. Synapse now has a <define name="some_name"/> mediator and
this mediator can reference this by <refdefine ref="some_name"/>
	Is it possible to have a scenario as follows
	
	<synapse xmlns="http://ws.apache.org/ns/synapse">
	
	   <servicemediator service="service1"> 
	        <refdefine ref="customer_properties"/>
	   </service>
	
	   <classmeditator class="com.service.Service2> 
	         <refdefine ref="customer_properties"/>
	   </classmediator> 
	
	   <servicemediator service="service3">
	        <synapseobject>
	              <attribute name="url"
type="STRING">http://%3c</attribute>
	              <synapseobject name="consumern">
	                  <attribute name="identifier"
type="STRING">someID</attribute>
	                  <attribute name="priority"
type="INTEGER">2</attribute>
	            </synapseobject>
	        </synapseobject>
	   </servicemediator>
	
	    <define name="customer_properties">
	         <!-- attribute to service 1-->
	         <synapseobject name="service1">
	              <attribute name="url"
type="STRING">http://%3c</attribute>
	              <synapseobject name="consumer0">
	                  <attribute name="identifier"
type="STRING">someID</attribute>
	                  <attribute name="priority"
type="INTEGER">2</attribute>
	            </synapseobject>
	           <synapseobject name="consumer1">
	                <attribute name="identifier"
type="STRING">someID</attribute>
	                <attribute name="priority"
type="INTEGER">6</attribute>
	            </synapseobject>
	       </synapseobject>
	       <!-- attribute to service 2--> 
	      <synapseobject name="service2">
	              <attribute name="url"
type="STRING">http://%3c</attribute>
	              <synapseobject name="consumer0">
	                  <attribute name="identifier"
type="STRING">someID</attribute>
	                  <attribute name="priority"
type="INTEGER">2</attribute>
	            </synapseobject>
	           <synapseobject name="consumer1">
	                <attribute name="identifier"
type="STRING">someID</attribute>
	                <attribute name="priority"
type="INTEGER">6</attribute>
	            </synapseobject>
	       </synapseobject>
	    </define>
	</synapse>
	
	4. As we agreed on, <synapseobject/> will be an extension, and
what would be the way of integrating this in to Synapse at run time. 
	
	Thank you
	
	Saminda 

	On 3/27/06, Vikas <vikas@infravio.com> wrote: 

	Hi,

	 

	This is regarding the Synapse object proposed by me and
Soumadeep...

	 

	For convenience I am putting below the links for reference:

	<
http://mail-archives.apache.org/mod_mbox/ws-synapse-dev/200602.mbox/%3cP
OEHIPNLJGDMKMMBHILOAECICBAA.soumadeep@infravio.com%3e
<http://mail-archives.apache.org/mod_mbox/ws-synapse-dev/200602.mbox/%3c
POEHIPNLJGDMKMMBHILOAECICBAA.soumadeep@infravio.com%3e> >

	and the source code has been available in the Scratch

	
<http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/infravi
o/synapse-SO >

	 

	I feel that it an effective utility and have made use of it in a
all the mediators that I would like to commit . It sure has made
handling mediator's config data easier..

	Would be checking in the cleaned up code for SynapseObject as an
extension...Which I guess is OK.

	 

	Please let me know if anyone has any concerns about it??

	 

	~Vikas

	 




-- 
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle 
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com


Mime
View raw message