Small correction on the tag names in proxy.....
On 2/26/07, Ruwan Linton <[EMAIL PROTECTED]> wrote:
+1 for this and have some more improvements........
On 2/26/07, [EMAIL PROTECTED] < [EMAIL PROTECTED]> wrote:
>
> Hi Asankha,
>
> I think this is a very good enhancement so +1 from me!
>
> Tijs
>
> ---- "Asankha C. Perera" <[EMAIL PROTECTED]> schreef:
> > Hi
> >
> > As Paul mentioned, we had some discussions last week on getting ready
> > for Synpase 1.0, and another point we discussed was that the current
> > properties mechanism tied with the registry/dynamic properties, and
> two
> > level indirection seems to be a bit too complicated for some to
> > understand. So let me try to explain the proposed enhancements by
> example!
> >
> > At present, one could define static or dynamic properties as follows:
> > <definitions>
> > <set-property name="string" [value="string"] [src="url"]
> > [key="string"]>
> > string? | <inline-xml/>?
> > <set-property/>
> > </definitions>
> >
> > And the proposal is to support whats shown below, where everything is
> > picked up from a registry - either local or remote.
> > <definitions>
> > <!-- any local keys ALWAYS override remote keys with the same name
> -->
> > <registry-entry key="string" [src="url"]>
> > string? | <inline-xml/>?
> > <registry-entry/>
> > </definitions>
> >
In the same way we define these registry entries, it is possible to define
all our defined (named) sequences, endpoints as local in line registry
entries. If we go in to this approach we can drop the definitions tag
because now all of the definitions are registry entries. Also the proxies
tag which encapsulates the proxy service definitions can be removed from the
configuration so that the configuration can contain any element without any
ordering. Basically the new configuration that I am proposing will be like
this....
<synapse>
<registry> ..... remote registry definition ........ </registry>?
<registry-entry key="string" [src="url"]>
string? | <inline-xml/>?
<registry-entry/>?
<proxy-service name="string" [transports="(http |https |jms )+|all"]>
<description>..</description>
<target [inSequence="name"] [outSequence="name"]
[faultSequence="name"] [endpoint="name"]/>?
<endpoint>...</endpoint>
<inSequence>...</inSequence>
<outSequence>...</outSequence>
<faultSequence>...</faultSequence>
</target>
<publish-wsdl uri=".." key="string">
<wsdl:definition>...</wsdl:definition>?
<wsdl20:description>...</wsdl20:description>?
</publish-wsdl>?
<policy key="string">
// optional service parameters
<parameter name="string">
text | xml
</parameter>
</proxy-service>?
<rules [key="string"]>
mediator*
</rules>
</synapse>
I don't have a much understanding of what are the parameters need to
define the remote registry, so it has to be filled. But I think we don't
want the cachableDuration, instead we can check weather the remote registry
entry is modified or not in the remote registry and get the entry if it is
modified as Sanjiva suggested in the discussion.
Thoughts....??
Thanks,
Ruwan.
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
--
Ruwan Linton
http://www.wso2.org - "Oxygenating the Web Services Platform"
