[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]