[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
Contrast this with the reference properties approach to this situation.
The EPR to A looks slightly different:
<wsa:EndpointReference>
<wsa:Address>
http://www.sgg.com/services
</wsa:address>
<wsa:ReferenceProperties>
<tns:disambiguator>A</tns:disambiguator>
</wsa:ReferenceProperties>
</wsa:EndpointReference>
The difference is where the additional information about how to 'locate'
the stateful resource is included. With the singleton resource pattern,
it is smashed into the address of the Web service. With the more
"traditional" Web service, it is separated into reference properties. Both
approaches are valid uses of WS-Addressing, both approaches are valid
applications "implied resource pattern". In most of the WSRF normative
and non-normative text, we have been over emphasizing the use of reference
properties and not legitimatizing the use of the singleton resource
pattern.
Several points on this:
a) Whether the singleton resource pattern or "traditional"
reference-properties approach to the implied resource pattern is used
makes no difference to the client. The client's runtime needs to receive
an EPR, and be compliant with WS-Addressing, including handling reference
properties for those EPRs that may contain them. Using singleton resource
pattern does not make the client any "lighter" or "less coupled" with
respect to the Web service.
b) The client doesn't need to know which implementation of the "implied
resource pattern" (singleton or traditional) is chosen by the server. The
interaction is the same. Client gets EPR to a service, client uses EPR to
make a proxy to the service, client sends messages through that proxy to
the service, client's WSA middleware makes sure the WSA rules are
conformed to.
c) The singleton resource pattern does not change the coupling on the
server side. By this I mean the collaboration between the component that
produces the EPR (eg a factory or a registry lookup) and the Web service
pointed to by that EPR. These two components always needed some form of
coordination. In the "traditional" reference-properties approach, the
choice of reference property (both element and value) made by the
"factory" or "registry" in forming the EPR must be coordinated with the
Web service targeted by that EPR. If the factory chooses to use <tns:foo>
with value "bar" as the reference property, then the Web service targeted
by the wsa:address component of the EPR better darn well know what
<tns:foo> semantics are, and how to use the value 'bar' to
locate/lookup/constitute/activate etc. the stateful resource that the
factory/registry imagined was associated with 'bar'.
A similar point holds for the singleton resource pattern. If the factory
produces an EPR containing the address http://www.sgg.com/services?res=a,
then the web service at www.sgg.com/services darn well better know what
the res parameter semantic is, and what the value "a" means.
So, to the question, doesn't the choice of singleton resource pattern
complicate the coupling between components? The answer is no. It doesn't
help or hurt the existing loose coupling between requestor and service
provider (point a and b). It doesn't complicate nor simplify the coupling
between the components on the service provider side that produce the EPR
and consume messages targeted by that EPR (point c).
Reference Properties are still important:
a) The singleton resource pattern can only be used when the disambiguator
is simple types and when the addressing scheme, eg HTTP can conveniently
encode the disambiguator in the address. Otherwise, reference properties
offer a much more flexible means of communicating the disambiguator.
b) By using reference properties, the disambiguator can be any arbitrary
XML structure. Furthermore, the implementation need not rely on the
addressing scheme to provide the right hooks for the disambiguator (sure
this can work for certain circumstances) in HTTP, but what about other
transports?
c) By using reference properties, the disambiguator is in the header (not
buried in the address). This allows all the sorts of cool things one can
do with soap headers, including intermediary processing for security,
validation, routing, etc.
Therefore the singleton resource pattern does not lead us to the
conclusion to abandon reference properties. We still need them.
Is this useful discussion of singleton resource pattern? Is this enough
detail to be illustrative? Are there other areas that we need to describe
with this detail?
sgg
++++++++
Steve Graham
(919)254-0615 (T/L 444)
STSM, On Demand Architecture
Member, IBM Academy of Technology
<Soli Deo Gloria/>
++++++++
Susan Malaika/Santa Teresa/IBM@IBMUS
07/10/2004 05:13 PM
To: wsrf@lists.oasis-open.org
cc:
Subject: [wsrf] Singleton Resource Pattern
I've heard the term "singleton resource pattern" in conversations relating
to WSRF. Is there a definition?
Susan Malaika
--=_alternative 0050CA5385256ECE_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Susan:</font>
<br><font size=2 face="sans-serif">I am not aware of a formal definition.
Maybe we should have some sort of note on this.</font>
<br><font size=2 face="sans-serif">Here are my thoughts on the "singleton
resource pattern".</font>
<br>
<br><font size=4 face="sans-serif"><b>Definition:</b></font>
<br><font size=2 face="sans-serif">The singleton resource pattern is a
"special case" of the implied resource pattern, wherein the address
of the Web service and the disambiguator of the stateful resource are not
distinguished. This can be done by URL encoding some sort of "identity"
of the stateful resource in the wsa:address element information item of
the endpoint reference.</font>
<br>
<br>
<br><font size=4 face="sans-serif"><b>Example:</b></font>
<br><img src=cid:_1_048F631C048F5EE00050CA5185256ECE>
<br>
<br><font size=4 face="sans-serif"><b>Discussion:</b></font>
<br><font size=2 face="sans-serif">In this example, there is a Web service
whose address is an HTTP URL at www.sgg.com/services</font>
<br><font size=2 face="sans-serif">There are two stateful resources, that
can be disambiguated by two strings "A" and "B". Note,
these are simple types, which is not always the case for disambiguators.</font>
<br>
<br><font size=2 face="sans-serif">There are a couple of approaches to
using the singleton resource pattern in this case:</font>
<br><font size=2 face="sans-serif">a) use a param on the url</font>
<br><font size=2 face="sans-serif">so the endpoint reference to A would
look like:</font>
<br><font size=2 face="sans-serif"><wsa:EndpointReference></font>
<br><font size=2 face="sans-serif"> <wsa:Address></font>
<br><font size=2 face="sans-serif"> http://www.sgg.com/services?res=a</font>
<br><font size=2 face="sans-serif"> </wsa:Address></font>
<br><font size=2 face="sans-serif"></wsa:EndpointReference></font>
<br>
<br><font size=2 face="sans-serif">or</font>
<br>
<br><font size=2 face="sans-serif">b) use a path node on the url itself</font>
<br><font size=2 face="sans-serif"><wsa:EndpointReference></font>
<br><font size=2 face="sans-serif"> <wsa:Address></font>
<br><font size=2 face="sans-serif"> http://www.sgg.com/services/a</font>
<br><font size=2 face="sans-serif"> </wsa:Address></font>
<br><font size=2 face="sans-serif"></wsa:EndpointReference></font>
<br>
<br><font size=2 face="sans-serif">With the "singleton" pattern,
the illusion to the client is that the Web service and the stateful resource
are indistinguishable. This does not, however imply a constraint
on the server side, that is that there MUST be a 1 to 1 correspondence
between the Web service and the stateful resource. From the picture, it
is clear that the single Web service at www.sgg.com/services is associated
with two resources. But from the client's point of view, it has an
endpoint reference and that is all it cares about. Further note,
that if the implementation CHOOSES to enforce a 1-1 restriction, it can
clearly do so.</font>
<br>
<br><font size=2 face="sans-serif">Contrast this with the reference properties
approach to this situation. The EPR to A looks slightly different:</font>
<br><font size=2 face="sans-serif"><wsa:EndpointReference></font>
<br><font size=2 face="sans-serif"> <wsa:Address></font>
<br><font size=2 face="sans-serif"> http://www.sgg.com/services</font>
<br><font size=2 face="sans-serif"> </wsa:address></font>
<br><font size=2 face="sans-serif"> <wsa:ReferenceProperties></font>
<br><font size=2 face="sans-serif"> <tns:disambiguator>A</tns:disambiguator></font>
<br><font size=2 face="sans-serif"> </wsa:ReferenceProperties></font>
<br><font size=2 face="sans-serif"></wsa:EndpointReference></font>
<br>
<br><font size=2 face="sans-serif">The difference is where the additional
information about how to 'locate' the stateful resource is included. With
the singleton resource pattern, it is smashed into the address of the Web
service. With the more "traditional" Web service, it is
separated into reference properties. Both approaches are valid uses of
WS-Addressing, both approaches are valid applications "implied resource
pattern". In most of the WSRF normative and non-normative text,
we have been over emphasizing the use of reference properties and not legitimatizing
the use of the singleton resource pattern.</font>
<br>
<br><font size=4 face="sans-serif"><b>Several points on this:</b></font>
<br><font size=2 face="sans-serif">a) Whether the singleton resource pattern
or "traditional" reference-properties approach to the implied
resource pattern is used makes no difference to the client. The client's
runtime needs to receive an EPR, and be compliant with WS-Addressing, including
handling reference properties for those EPRs that may contain them. Using
singleton resource pattern does not make the client any "lighter"
or "less coupled" with respect to the Web service.</font>
<br>
<br><font size=2 face="sans-serif">b) The client doesn't need to know which
implementation of the "implied resource pattern" (singleton or
traditional) is chosen by the server. The interaction is the same.
Client gets EPR to a service, client uses EPR to make a proxy to
the service, client sends messages through that proxy to the service, client's
WSA middleware makes sure the WSA rules are conformed to.</font>
<br>
<br><font size=2 face="sans-serif">c) The singleton resource pattern does
not change the coupling on the server side. By this I mean the collaboration
between the component that produces the EPR (eg a factory or a registry
lookup) and the Web service pointed to by that EPR. These two components
always needed some form of coordination. In the "traditional"
reference-properties approach, the choice of reference property (both element
and value) made by the "factory" or "registry" in forming
the EPR must be coordinated with the Web service targeted by that EPR.
If the factory chooses to use <tns:foo> with value "bar"
as the reference property, then the Web service targeted by the wsa:address
component of the EPR better darn well know what <tns:foo> semantics
are, and how to use the value 'bar' to locate/lookup/constitute/activate
etc. the stateful resource that the factory/registry imagined was associated
with 'bar'. </font>
<br><font size=2 face="sans-serif">A similar point holds for the singleton
resource pattern. If the factory produces an EPR containing the address
http://www.sgg.com/services?res=a, then the web service at www.sgg.com/services
darn well better know what the res parameter semantic is, and what the
value "a" means.</font>
<br>
<br><font size=2 face="sans-serif">So, to the question, doesn't the choice
of singleton resource pattern complicate the coupling between components?
The answer is no. It doesn't help or hurt the existing loose coupling
between requestor and service provider (point a and b). It doesn't
complicate nor simplify the coupling between the components on the service
provider side that produce the EPR and consume messages targeted by that
EPR (point c).</font>
<br>
<br><font size=4 face="sans-serif"><b>Reference Properties are still important:</b></font>
<br><font size=2 face="sans-serif">a) The singleton resource pattern can
only be used when the disambiguator is simple types and when the addressing
scheme, eg HTTP can conveniently encode the disambiguator in the address.
Otherwise, reference properties offer a much more flexible means of communicating
the disambiguator.</font>
<br>
<br><font size=2 face="sans-serif">b) By using reference properties, the
disambiguator can be any arbitrary XML structure. Furthermore, the
implementation need not rely on the addressing scheme to provide the right
hooks for the disambiguator (sure this can work for certain circumstances)
in HTTP, but what about other transports?</font>
<br>
<br><font size=2 face="sans-serif">c) By using reference properties, the
disambiguator is in the header (not buried in the address). This allows
all the sorts of cool things one can do with soap headers, including intermediary
processing for security, validation, routing, etc.</font>
<br>
<br><font size=2 face="sans-serif">Therefore the singleton resource pattern
does not lead us to the conclusion to abandon reference properties. We
still need them.</font>
<br>
<br><font size=2 face="sans-serif">Is this useful discussion of singleton
resource pattern? Is this enough detail to be illustrative? Are there
other areas that we need to describe with this detail? </font>
<br>
<br><font size=2 face="sans-serif">sgg</font>
<br><font size=2 face="sans-serif"><br>
++++++++<br>
Steve Graham<br>
(919)254-0615 (T/L 444)<br>
STSM, On Demand Architecture<br>
Member, IBM Academy of Technology<br>
<Soli Deo Gloria/><br>
++++++++<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Susan Malaika/Santa Teresa/IBM@IBMUS</b></font>
<p><font size=1 face="sans-serif">07/10/2004 05:13 PM</font>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To:
wsrf@lists.oasis-open.org</font>
<br><font size=1 face="sans-serif"> cc:
</font>
<br><font size=1 face="sans-serif"> Subject:
[wsrf] Singleton Resource Pattern</font></table>
<br>
<br>
<br><font size=3>I've heard the term "singleton resource pattern"
in conversations relating to WSRF. Is there a definition?<br>
<br>
Susan Malaika</font>
<br>
--=_alternative 0050CA5385256ECE_=--
--=_related 0050CA5285256ECE_=
Content-Type: image/gif
Content-ID: <_1_048F631C048F5EE00050CA5185256ECE>
Content-Transfer-Encoding: base64
R0lGODlh7AFcAecAAP///wAAAHC4+PjYmEgAAPi4cPj42JhIALj4+Pj4uNj4+HAAAJjY+ABImEiY
2ABwuAAAcAAASNiYSLhwALhwcEgASHAAcJhwmHBwuHC4uJhISJi4+HCY2ABwmEgAcEhImJiYuNiY
mHAASJhIcLj4uNiYcHBwcHCYmHC42Ji4mJjY2Nj42ABIcHBIAHBwAJiYSJjYuNjYmNj4uAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACwAAAAA7AFcAUAI/wABCBxI
sKDBgwgTKlzIsKHDhxAjSpxIsaLFixgzatzIsaPHjyBDihxJsqTJkyhTqlzJsqXLlzBjypxJs6bN
mzhz6tzJs6fPn0CDCh1KtGjOAEYBIE3KtKnTpzWXWhxAQEDFBAusTpQKtavXr2A1ch06NqzZs2jR
lg26Nq3bt06XtiU612dduHjzsuQaoG3fv4D98tV5l2dhvYgTl5R6OCFjuyv7ilVMufLHvwTlKpTg
oEAEBg01DwRMs3FLyY4tnwzMGrNqr6YXxoY52ybj2pVRR8b9enHBsbp/A//duzRvo8dTJi+Ocjjz
r66FLpc5/XnI6taZRj+9kaoDABIyLP/4XkCrAQ2gqQqg+hnABAgIJmefT//m9ozYe+avz7//9eAG
JWfAAfBJ59+BCOo3WmBp7ZfggxBe5KCBEVZoYXOKTXghQxpuaFaHCnpIknMi1gciTiceSKJSdQW3
YomJpRiTjBFiRyOMFD51o4kuCtSWBA0oINCABSokmo/34ZjXjh0xWSFSj221oJL+ORkalddlBuCC
rQkWJZYJbomRmGDa5mOZaKap5poPUhAfm3DGyZEBIAw0gAcI0GknnnL26eefgAYq6KCEFmrooYgm
quiijDbq6KOQRirppJRWaumlmGaq6aacdurpp6CGKuqopJZq6qmopqrqqqyy2uWrsMb/KuussLZq
q0pWNnnrribNVkCQBKknkLC/CmlnVQAIK6yUvDabJXLOEpqrSNNuVG20qr1Y1LX4YavkimQimRlx
O52YJEfcenuWjUClO2VE7qq7bY9KIURVYA9weCaX8e7L1pEehithvwgOxqy/5dKq8MIM12okwdSZ
aehtXraGUHQQZyfwtnRJCnCr50aM0QTtuVdysh8YGywBAWhlrbyahuyRhhMAC57NAAwIbAEOCDtg
vujCXKrMsuGVsdByuiZgnUMSiECxK7vsGQPlDYssAFAPlHW3SDcr16sfdu01ZUeLzWbZvUb6sdkS
6oX2W3xVzNrFBrNtJNwTj2bRl3Y///R2239ut7ZAQBqL1XdF18tv34kn9fdr7DIun2GQlgWcYOTq
LfnMuW7cqbabh16u6KSX3tIAFVCdgQgMlADasKkXsHrrr6OuOuuuH3RvvgOSB2zvWOMs0NbgFXm4
ssgumwAGxwaQL/HLDv9Z1ckiSzzx1Ttv+vbcd+/99+CHL/745Jdv/vnop6/++uy37/778Mcv//z0
12///fjnr//+/Pfv//8ADKAAB0jAAmbLcQasHAIT6KjlYKVlAsGKy0bEwAZGBHgFaJmwHmiV86SH
AOIJwPTaEz14VbBRs/nZsDiwLJ8dYGc9S54MJwiRx52QbAu8YaJseDcdNgVKUOFhav98CC3N/TCH
RJyR5xDGRMcscS9ITOKMDvJELVFxdEWUYmn8VZso2VCIF9PiUcbEltVMCIwERM1dJhAAxOmLRVg8
TXLQiD+BATEhBQDae95UtLtUESRHeyIdBahG3fHpWG4MIxwJ85MtDbKRc/wjo6aDxke+y0JMkmTg
EBYbg30xiuKiT7wsqRYqdnEtpOyKJmHDyEERbVyZk80q1TTLduXoUXUL1SshwzG1KW5VuxRZXMTY
oFoCMiMqzNkLjeUme10taMQ0mjEr4iDPpIADWIsADJg3POEpbzwvi2aGptnDUoqzN8FsnFtSec6R
pPOXE6mZkCQAQYpI0DftVJEjMXL/r3p6sHom6EuBbEc4AXCwaeRp2T9LKBF25vMlGIsNkeKjQp0J
iWclzKDLlpXMAXDAolhL5MEeGiZ+vbOXJC1phlKq0hixtGA4fGmVVupLh/oSMTZtECzRl1MT+imd
lnPISeXVU6EKCpWnvOL2ivrGo3KxoZpjKqCkqlREUbJ8VDXiUQd3MyEN6GRDJCdRoZO0FsGzIPT8
S5H05cesoimnbkUOVwtHOO0lTqxII2VcWQm49dFxr8M0YicF2763AVZHdGsoKuHnrsMGcZFN1erD
HLuoG+H1pk00IGngNVRS3VGmoA2taKm0vI3cc7RQGVAHD6CVZqpWma3NE2thK5Bm/wYrZQAIAQLu
SVfeCk+ZCRUA8HQWA5ZNT4RUO1nVBoBb3S6UAAENQJEICh6DLgCCGFQoeqq3nubyEbU2yWBwCyJe
rNVzeG00Lw2HtQGBTMABCbDAdwEQ3/kSpKMfdVpXkWeVZemWve51AEgx+kz0bhRZ+B1wz9rrHpGC
VzED+gviItwXBz/4whjOsIY3zOEOe/jDIA6xiEdM4hKb+MQoTrGKV8ziFrv4xTCOsYxnTOMa2/jG
OM6xjnfM4x77+MdADrKQh0zkIhv5yEhOspKXzOQmO/nJUI6ylKdM5SrXOJWU9TGWrWzLLHKZcl7+
cistctrT4lPMcawIQyHy2pGiGf9FEqFwvr5pngNUmL4LQIGd8/VA6do3sm+2T0QKsFbuWs0qGQRM
DPubOkO7OdBRGTRYW2i9QvPX0VCFNJwj0ucGyOC6n3lge/r8AFGnwLgMiHChjappQYe51cLsGKwj
/WohF3XLRv7sEWv9Y76BsoxEzuWvuwzjPwbVb2XDdYy/ZtaqmpKrU+Q1iy0XyQCNWdYzXqyWuhRL
yUoMpdneqSD59jhl0/izvHnMJ6Ut4+X81Z3wznHkeOnODmX5fXeZGqtDZEZoFlsy0KavBVzwW0VC
6bK62stVV3wuXRvEg4e70lm5FG2IpnvaYoL2BLSi0Td6qeLUGeyyAZ5Z8CRyj3f/ZVGyj1KYe7uv
LPcqWT8LXvJNJ0yRYNoshzo7ycnx2y7CDthlEb5Jat7yXy4HpIyI/lZ4dnFc6+YY0+HSOQtq1XP0
qvlMzA1ZE4E8b9YWzty6rfWvH92K1iFY0tMcSorsc6prD/u3ndp1Z+80sRP/6drLvdUayj00cUeR
Y8EYeLLcPWZuHWThgZ33TU3dJZZcvC0lr5bHp23YiqI81S1/zF1HmefKsQiFI6ACO/elvywr+Jr3
ZmXQx/silJbaeg+dcC67vvYYkUCBsDJqbirzzlTRM3J9/uXb91UjNVvBBRQgT9smWsJ0Jj6aje9T
jvAeNNfXmqWvRl2uwZr66uTI/wAYnCxsEoTUdb0z7mcN/r+va9bPDqdO4e/EORqN/jufzXLY2Mbx
XyUrZ4Z/+SdxE2Fm/gdmAlhDZLIciSZSFPYdVBFCAiVbLWNmctY06md0CbgVWXcRDWheihY9E8A7
y+dohPZdz5eBj7aBnNWBDWEAI8BHJ3iCUTMQA9IBJWiCYEWD0seCJmQxDkEn6BdB1+U8feYyMPgm
ovY6nSYkQ8h6PqiBKtd+bBeFfjeFDBI2VriCVLeFmeZSXniFYBiG+4ZTZOg3MXWGgHZ/akiAbjMp
mpcmcReHlEOHOUdTuORt5LN3CqSH45N0dtgrInd4siQ6gFh0ROMXk1V2YnNvgf+IIcKxN8dGOo5I
d93mMHr4iDDVhZb4S+N2dd4zeIWCbm6nN5r4IId1ipB3fOEDWKoIRd7Xiu9nVQbRZ38BVkMkPln1
iotBco1HV9VjYeRycLzIH1RVjJyzWHMBjBKAi0r1caHDVMiYjM+IEMyYXikXf4b4WKPoiz+CMyTz
OmGlcuBjU9MIi+dXhIABNOVkPux0jtwRi+cTeXnIiOUEjzVieFbnawQYcOVIbCh0d1iXS/iYj1VY
WXaHhUmibeqzcph1SRzofjzVLwUZjxujiA9jj7oIUZRibBKZkYwVeqkSdADEeZzXcxrJP3h1kgpU
kZmnc2LHkpbikm1YkzZ5kzj/STq2hRFmlpNFQT0+aYN2BgEkAGpUEwANsAJDWZTIlUEs0ALSxZTH
9VtpVSApaJWAsWoX+HtIeVGkt2cRxo70xU1VSVGmB4EgtAAQ8AITGGHWVWd9ATQPmH6rdmSFo0Kl
RThBgpdkuZcHwGe+dyzsSFB3Eh+EeUjah4LTVRWX1n3NRBXsmIL9V2AjmDMlSCyFJpkxJJZMNoJu
MgE4qDLu8QCfGZoD4ZkIAJo5eBAdl2hr5Zr2pW9aU08S1JjcR34GxoO0J5SmaWiyOTx1qV5NVl8C
N1/ESZwDcZzyJZRB0k98po7pZYvpBVJNyJVB0mcnwDIBkJ3IZQA56JxEGJdHbXhfMRieo1aEwIJ+
4OmTzPgd7RmU8Bmf8jmf9Fmf9nmf+Jmf+rmf/Nmf/vmfABqgAjqgBFqgBnqgCJqgCrqgDNqgDvqg
EBqhEjqhFFqhFnqhGJqhGrqhHNqhHvqhIBqiIjqiJFqiJnqiKIojAQEAOw==
--=_related 0050CA5285256ECE_=--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]