Hi...
I am using SynapseObject to handle mediator data,
it works as an extension.
Is there a problem in
adding extensions??
Extensions are not compulsary or imposed on others,
just for convenience...
But to make things clear and sum up the
points:
The problem is not with using DOM / OM..
Its the
XML structure that gives the meaning, the JAVA/in-memory
representation is
just an enabler for that..
I did try writing the 'utility' methods for
OM...
But based on a generic XML structure, it just doesn't work
out...
The XML representation along with the Utility classes gives
SynapseObject
the actual strength and the users the
ease..
SynapseObject is not just about ObjectModel [AXIOM/DOM] or about
XML [the
structure]
or the data-binding [XMLBeans/ ADB]...
Its a
variation in-between, a blend to be more precise...
The very problem with
XPath is that they are based on the XML structure,
change the structure
=>change the X-Path...
But SynapseObject has only 2 structural
constraints..
Every object has
* Attributes as child objects
* Has
other SynapseObjects
In case I move an attribute from a parent to its child
SynapseObject, the
search utility takes care of it, In case of an X-Path
that mplies another
level of ../.. [hope you are not planning to use x-paths
which always search
throughout i.e
[//someName]
~Vikas..
----- Original Message -----
Sent: Monday, March 20, 2006 2:51
PM
Subject: Re: SynapseObject -
Reminder...
Hi Devs,
My comments are in line,
On 3/19/06, Soumadeep <[EMAIL PROTECTED]> wrote:
Hi,
One thing I completely
agree with Sanjiva is that this has been dragged unnecessarily for this
long. Let me emphasize here one thing, that the intension is not to
replace the concepts of data binding as used by XMLBeans which is again an
Apache project or trying to re-invent what has been written. To this effect
enough reasons have been provided as to why this approach was taken.
For convenience let me give one of the use cases and
reasons for which SynapseObject was
proposed:
Following reasons is addressed by Axis2 's codegen
concepts.
Reasons:
1) Java Properties class
lets you handle name-value pairs in a very good way but when it comes to
representing complex objects it becomes very difficult.
2) Using the concept
of data binding introduces a very rigid and tight coupling
of data and schema. So if the schema changes the underlying data handling
mechanism needs to be changed (which includes the beans/classes to hold the
complex data structure)
This is why there are two entities exists in Axis2. If the xml
is schema compliant i will use XSD2Java, if not i will write my
beans and use BeanUtil.
3) Intelligent search
features are either driven by xpath/xqueries for pure XML or embedded logic
if beans are used, SynapseObject has inbuilt search features by which you
can perform complex searches
4) The reason people use
Java Properties class is because name-value pairs can be shared by other
class without any dependency. SynapseObject is more like a Properties Class
with added features to handle Complex Objects and also allow search
features.
Synapse is a user of Axis2, so let it be a user of Axis2's
XSD2Java, BeanUtil and Jaxen compliant Xpath.
Uses
Cases:
A) Data-Sharing between
mediators: Consumers need to be identified, once it's
identified the information could be shared by the SLA mediator which
depending on a consumer will set the priority. Below is the pseudo
code of how this can be achieved using SynapseObject and how
datasharing would become easy.
Background
Info:
-----------------------
ConsumerIdentification
mediator needs to identify a client by the following ways:
1) IP {eg. 192.168.5.*}
3) WS-SEC auth token
4) HTTP auth token
5)
certificate
(Other factors that need to
be considered whether the incoming message was first encrypted and then
signed or was it signed and then encrypted).
Let's consider 1)
IP
Using
SynapseObject:
ConsumerIdentification
--------------------------------
xml
frag:
<?xml version='1.0'
encoding='windows-1252'?>
<SynapseObject
name="ci">
<SynapseObject name="consumer0">
<Attribute name="CONSUMER_TYPE"
type="String">GOLD</Attribute>
<Attribute name="IP_ADDRESS_FROM" type="String">192.168.6.0</Attribute>
<Attribute name="IP_ADDRESS_TO"
type="String">192.168.6.255</Attribute>
<Attribute name="HTTP_AUTH_USERNAME"
type="String">john</Attribute>
<Attribute
name="WS_SEC_USERNAME"
type="String">john</Attribute>
<SynapseObject
name="assignedService">
<Attribute
name="serviceid1"
type="String">stockQuote1</Attribute>
</SynapseObject>
</SynapseObject>
<SynapseObject
name="consumer1">
<Attribute name="CONSUMER_TYPE"
type="String">SILVER</Attribute>
<Attribute
name="IP_ADDRESS_FROM" type="String">192.168.6.255</Attribute>
<Attribute name="IP_ADDRESS_TO" type="String">192.167.6.255</Attribute>
<Attribute name="HTTP_AUTH_USERNAME"
type="String">mary</Attribute>
<Attribute
name="WS_SEC_USERNAME"
type="String">mary</Attribute>
<SynapseObject
name="assignedService">
<Attribute
name="serviceid1"
type="String">stockQuote</Attribute>
<Attribute name="ip"
type="String">192</Attribute>
</SynapseObject>
</SynapseObject>
</SynapseObject>
Back to square one, Above can be written
as, <ci> <consumer
name="consumer0">
<type>GOLD</type>
<ip_address_from> 192.168.6.0
</ip_address_from>
<ip_address_to> 192.167.6.255
</ip_address_to>
<http_auth_username>Mary</http_auth_username>
<ws_sec_username>Mary</ws_sec_username>
</consumer> <service
name="assingedservice">
<!-- other stuff -->
</service> <consumer
name="consumer1">
<!-- related suff -->
</consumer> <!-- other
services or consumers or related stuff --> </ci> which is
much more readable, If i want intelligent search i use xpath. A lot of
users know how to use xpath, so it's Zero training. If i write simple
beans, i can populate the bean objects using BeanUtil. Now in production the
above xml should be schema aware. That's the whole point of inventing schema.
So i will use XSD2Java. Now these technologies are not going to hook into
Synapse core.
in the ci mediator
code fragment
// the the requester
ip
ip = {get the remote
ip from the messageContext/SynapseContext }
//Identify if the consumer
is there and get appropriate details and store the consumer related
details in the messageContext, one more things to note is that storing
shared data is by the mediator name itself eg.
ci
SynapseObject obj =
consumerIdentification.findSynapseObjectByAttributeValueStartingWith(ip);
messageContext.setProperty(consumerIdentification.getName(),obj);
obj will contain all the
required values if identified!
SLA
------
xml
Fragment:
<SynapseObject
name="SLA">
<SynapseObject name="consumer0">
<SynapseObject
name="Service0">
<Attribute name="priority"
type="Integer">0</Attribute>
</SynapseObject>
<SynapseObject
name="Service1">
<Attribute name="priority"
type="Integer">1</Attribute>
</SynapseObject>
</SynapseObject>
</SynapseObject>
IMHO above xml fragment would treat as the prior.
in the SLA Mediator code
fragment
//As there is a dependency between the SLA mediator and
CI the SLA mediator will pick information for its dependency
(Note: we also proposed a
concept
//of MediatorContext which will
have dependency and other information for a particular
mediator)
Excuse me btw :)
//Get the identified
consumer from the messagecontext
SynapseObject
consumerIdentification =
(SynapseObject)messageContext.getProperty("ci");
// get the consumer name
and consumer type
String consumerName =
consumerIdentification.getName();
String consumerType =
consumerIdentification.getString("CONSUMER_TYPE");
//find the sla details for
the identified consumer
SynapseObject consumer =
sla.findSynapseObjectByAttributeValue(consumerName);
String fromAddress =
(String)synapseMessageContext.getTo();
SynapseObject service =
consumer.findSynapseObjectByAttributeValue(fromAddress
);
// The priority value would
be used by the SLA mediator to forward the request to the provider depending
on the priority.
String priority =
service.getString("priority");
Now as i can understand from the above code fragments, SynaspeObject
has to have a hook to Synapse core. As we agreed, SO should be an
extension. Besides, as technology exists for manipulating the required xml,
(xpath, XSD2Java, BeanUtil) for mediators without having a hook to Synapse
core, why on earth we make SO a core feature?
Thank you
Saminda
-----Original
Message-----
From: Saminda Abeyruwan [mailto:[EMAIL PROTECTED]]
Sent: Saturday, March 18,
2006 6:59 PM
To: [email protected]
Subject: Re:
SynapseObject - Reminder...
Hi
Devs,
These are my concern regarding SynapseObject,
If the
following XML is considered wrt SynapseObject semantics,
<SynapseObject name="sla">
<attribute name="service" type="STRING">http://myhost:myport/Service</attribute>
<SynapseObject name="consumer">
<attribute name="ip" type="STRING">192.9.2.11</attribute>
</SynapseObject>
</SynapseObject>
which is similar to,
<sla>
<service> http://myhost:myport/Service
</service>
<consumer>
<ip>192.9.2.11</ip>
</consumer>
</sla>
Now if
we have Java beans as follows,
public class sla
{
private String service;
private Consumer consumer;
//getter and
setters
}
public class Consumer {
private String ip;
//getter and setters
}
and
using the Axis2's
org.apache.axis2.databinding.utils.BeanUtil.getPullParser(Object beanObject,
QName beanName);
i can get a XMLStreamReader and build the OMElement
i need. And if i have prior XML, using
Object []
org.apache.axis2.databinding.utils.BeanUtil.deserialize(OMElement response,
Object [] javaTypes); i can fill the bean object.
So if I'm a
Mediator author, using BeanUtil i can manipulate XML with Zero
training.
Now if my XML is schema complaint, using XSD2Java i
can generate Beans and using XX.parse() method i can fill the beans.
So what is done by SynapseObject is already done by Axis2's BeanUtil
and XSD2Java and they can do much more. So IMHO we do not need to
reinvent the wheel with SynapseObject.
Those are my concerns.
Thank you
Saminda
On 3/17/06, Sanjiva
Weerawarana <[EMAIL PROTECTED]> wrote:
On
Mon, 2006-03-27 at 18:44 +0530, Vikas 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/%
> [EMAIL PROTECTED]
%3e>
> and the source code has been available in the
Scratch
> <
http://svn.apache.org/repos/asf/incubator/synapse/trunk/scratch/infravio/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??
I do .. I will write an
explanatory reply tomrrow my time .. sorry for
keeping quiet; I've been
reading much of this thread but just haven't
had the time to jump
in.
I *will* dive in tomorrow (later today my time really). I'm
afraid its
going to have lots of -1s against SynapseObject features :(
.. just to
give you a warning of where its going.
Sanjiva.
---------------------------------------------------------------------
To
unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
commands, e-mail: [EMAIL PROTECTED]
|
