[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
-----Original Message-----
From: Steve Graham [mailto:sggraham@us.ibm.com]
Sent: 11 July 2004 15:43
To: Susan Malaika
Cc: wsrf@lists.oasis-open.org
Subject: Re: [wsrf] Singleton Resource Pattern
Susan:
I am not aware of a formal definition. Maybe we should have some sort
of note on this.
Here are my thoughts on the "singleton resource pattern".
Definition:
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.
Example:
Discussion:
In this example, there is a Web service whose address is an HTTP URL at
www.sgg.com/services
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.
There are a couple of approaches to using the singleton resource pattern
in this case:
a) use a param on the url
so the endpoint reference to A would look like:
<wsa:EndpointReference>
<wsa:Address>
http://www.sgg.com/services?res=a
</wsa:Address>
</wsa:EndpointReference>
or
b) use a path node on the url itself
<wsa:EndpointReference>
<wsa:Address>
http://www.sgg.com/services/a
</wsa:Address>
</wsa:EndpointReference>
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.
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
------=_NextPart_001_000E_01C46AF0.CD30A8B0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>
<META content=3D"MSHTML 6.00.2800.1400" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>wow -=20
you turn your back for a couple of days and look at the mail=20
storm.</FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>I've=20
read the thread in this with interest, but thought it better to reply to =
the=20
original item</FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>Steve=20
outlines two valid techniques using ws-addressing to identify endpoints =
(aka=20
resources).</FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>When=20
one uses any of the end point references below, an operation =
(or=20
message deepening on your preferred parlance) gets delivered=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>to the=20
endpoint.</FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>From a=20
client's perspective it cannot tell, and should not be able to tell, =
whether two=20
different endpoint references are going to the same </FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>or=20
different web services.</FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>In=20
fact, how a server encodes its endpoint information is entirely up to it =
(whether as a munged url or a url + ref props).</FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>Given=20
that, I don't even see why we formalise any of this model: a ws-address =
(with or=20
without ref props) is used to deliver messages </FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>to=20
endpoints. Isn't this just the ws-addressing model, with some=20
non-normative footnotes to server side =
vendors?</FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2>Martin.</FONT></SPAN></DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D999553803-16072004><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Steve Graham=20
[mailto:sggraham@us.ibm.com] <BR><B>Sent:</B> 11 July 2004 =
15:43<BR><B>To:</B>=20
Susan Malaika<BR><B>Cc:</B> =
wsrf@lists.oasis-open.org<BR><B>Subject:</B> Re:=20
[wsrf] Singleton Resource Pattern<BR><BR></FONT></DIV><BR><FONT=20
face=3Dsans-serif size=3D2>Susan:</FONT> <BR><FONT face=3Dsans-serif =
size=3D2>I am not=20
aware of a formal definition. Maybe we should have some sort of =
note on=20
this.</FONT> <BR><FONT face=3Dsans-serif size=3D2>Here are my thoughts =
on the=20
"singleton resource pattern".</FONT> <BR><BR><FONT face=3Dsans-serif=20
size=3D4><B>Definition:</B></FONT> <BR><FONT face=3Dsans-serif =
size=3D2>The=20
singleton resource pattern is a "special case" of the implied resource =
pattern, wherein the address of the Web service and the disambiguator =
of the=20
stateful resource are not distinguished. This can be done by URL =
encoding some=20
sort of "identity" of the stateful resource in the wsa:address element =
information item of the endpoint reference.</FONT> <BR><BR><BR><FONT=20
face=3Dsans-serif size=3D4><B>Example:</B></FONT> <BR><IMG=20
src=3D"cid:999553803@16072004-0D84";> <BR><BR><FONT face=3Dsans-serif=20
size=3D4><B>Discussion:</B></FONT> <BR><FONT face=3Dsans-serif =
size=3D2>In this=20
example, there is a Web service whose address is an HTTP URL at=20
www.sgg.com/services</FONT> <BR><FONT face=3Dsans-serif size=3D2>There =
are two=20
stateful resources, that can be disambiguated by two strings "A" and =
"B".=20
Note, these are simple types, which is not always the case for=20
disambiguators.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>There =
are a couple=20
of approaches to using the singleton resource pattern in this =
case:</FONT>=20
<BR><FONT face=3Dsans-serif size=3D2>a) use a param on the url</FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2>so the endpoint reference to A would look =
like:</FONT>=20
<BR><FONT face=3Dsans-serif =
size=3D2><wsa:EndpointReference></FONT>=20
<BR><FONT face=3Dsans-serif size=3D2> <wsa:Address></FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2> =
http://www.sgg.com/services?res=3Da</FONT>=20
<BR><FONT face=3Dsans-serif size=3D2> =
</wsa:Address></FONT> <BR><FONT=20
face=3Dsans-serif size=3D2></wsa:EndpointReference></FONT> =
<BR><BR><FONT=20
face=3Dsans-serif size=3D2>or</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D2>b) use a=20
path node on the url itself</FONT> <BR><FONT face=3Dsans-serif=20
size=3D2><wsa:EndpointReference></FONT> <BR><FONT =
face=3Dsans-serif=20
size=3D2> <wsa:Address></FONT> <BR><FONT face=3Dsans-serif =
size=3D2> http://www.sgg.com/services/a</FONT> <BR><FONT=20
face=3Dsans-serif size=3D2> </wsa:Address></FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2></wsa:EndpointReference></FONT> =
<BR><BR><FONT=20
face=3Dsans-serif size=3D2>With the "singleton" pattern, the illusion =
to the=20
client is that the Web service and the stateful resource are=20
indistinguishable. This does not, however imply a constraint on =
the=20
server side, that is that there MUST be a 1 to 1 correspondence =
between the=20
Web service and the stateful resource. From the picture, it is clear =
that the=20
single Web service at www.sgg.com/services is associated with two =
resources.=20
But from the client's point of view, it has an endpoint =
reference and=20
that is all it cares about. Further note, that if the =
implementation=20
CHOOSES to enforce a 1-1 restriction, it can clearly do so.</FONT>=20
<BR><BR><FONT face=3Dsans-serif size=3D2>Contrast this with the =
reference=20
properties approach to this situation. The EPR to A looks =
slightly=20
different:</FONT> <BR><FONT face=3Dsans-serif=20
size=3D2><wsa:EndpointReference></FONT> <BR><FONT =
face=3Dsans-serif=20
size=3D2> <wsa:Address></FONT> <BR><FONT face=3Dsans-serif =
size=3D2> http://www.sgg.com/services</FONT> <BR><FONT=20
face=3Dsans-serif size=3D2> </wsa:address></FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2> =
<wsa:ReferenceProperties></FONT> <BR><FONT=20
face=3Dsans-serif size=3D2> =20
<tns:disambiguator>A</tns:disambiguator></FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2> =
</wsa:ReferenceProperties></FONT>=20
<BR><FONT face=3Dsans-serif =
size=3D2></wsa:EndpointReference></FONT>=20
<BR><BR><FONT face=3Dsans-serif size=3D2>The difference is where the =
additional=20
information about how to 'locate' the stateful resource is included.=20
With the singleton resource pattern, it is smashed into the =
address of=20
the Web service. With the more "traditional" Web service, it is=20
separated into reference properties. Both approaches are valid uses of =
WS-Addressing, both approaches are valid applications "implied =
resource=20
pattern". In most of the WSRF normative and non-normative text, =
we have=20
been over emphasizing the use of reference properties and not =
legitimatizing=20
the use of the singleton resource pattern.</FONT> <BR><BR><FONT=20
face=3Dsans-serif size=3D4><B>Several points on this:</B></FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2>a) Whether the singleton resource pattern =
or=20
"traditional" reference-properties approach to the implied resource =
pattern is=20
used makes no difference to the client. The client's runtime =
needs to=20
receive an EPR, and be compliant with WS-Addressing, including =
handling=20
reference properties for those EPRs that may contain them. Using =
singleton resource pattern does not make the client any "lighter" or =
"less=20
coupled" with respect to the Web service.</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
size=3D2>b) The client doesn't need to know which implementation of =
the "implied=20
resource pattern" (singleton or traditional) is chosen by the server.=20
The interaction is the same. Client gets EPR to a service, =
client=20
uses EPR to make a proxy to the service, client sends messages through =
that=20
proxy to the service, client's WSA middleware makes sure the WSA rules =
are=20
conformed to.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>c) The =
singleton=20
resource pattern does not change the coupling on the server side. =
By=20
this I mean the collaboration between the component that produces the =
EPR (eg=20
a factory or a registry lookup) and the Web service pointed to by that =
EPR.=20
These two components always needed some form of coordination. In =
the=20
"traditional" reference-properties approach, the choice of reference =
property=20
(both element and value) made by the "factory" or "registry" in =
forming the=20
EPR must be coordinated with the Web service targeted by that EPR. =
If=20
the factory chooses to use <tns:foo> with value "bar" as the =
reference=20
property, then the Web service targeted by the wsa:address component =
of the=20
EPR better darn well know what <tns:foo> semantics are, and how =
to use=20
the value 'bar' to locate/lookup/constitute/activate etc. the stateful =
resource that the factory/registry imagined was associated with 'bar'. =
</FONT> <BR><FONT face=3Dsans-serif size=3D2>A similar point =
holds for the=20
singleton resource pattern. If the factory produces an EPR =
containing=20
the address http://www.sgg.com/services?res=3Da, then the web service =
at=20
www.sgg.com/services darn well better know what the res parameter =
semantic is,=20
and what the value "a" means.</FONT> <BR><BR><FONT face=3Dsans-serif =
size=3D2>So,=20
to the question, doesn't the choice of singleton resource pattern =
complicate=20
the coupling between components? The answer is no. It doesn't =
help or=20
hurt the existing loose coupling between requestor and service =
provider (point=20
a and b). It doesn't complicate nor simplify the coupling =
between the=20
components on the service provider side that produce the EPR and =
consume=20
messages targeted by that EPR (point c).</FONT> <BR><BR><FONT =
face=3Dsans-serif=20
size=3D4><B>Reference Properties are still important:</B></FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2>a) The singleton resource pattern can only =
be used when=20
the disambiguator is simple types and when the addressing scheme, eg =
HTTP can=20
conveniently encode the disambiguator in the address. Otherwise, =
reference=20
properties offer a much more flexible means of communicating the=20
disambiguator.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>b) By =
using=20
reference properties, the disambiguator can be any arbitrary XML =
structure.=20
Furthermore, the implementation need not rely on the addressing =
scheme=20
to provide the right hooks for the disambiguator (sure this can work =
for=20
certain circumstances) in HTTP, but what about other =
transports?</FONT>=20
<BR><BR><FONT face=3Dsans-serif size=3D2>c) By using reference =
properties, the=20
disambiguator is in the header (not buried in the address). This =
allows all=20
the sorts of cool things one can do with soap headers, including =
intermediary=20
processing for security, validation, routing, etc.</FONT> =
<BR><BR><FONT=20
face=3Dsans-serif size=3D2>Therefore the singleton resource pattern =
does not lead=20
us to the conclusion to abandon reference properties. We still =
need=20
them.</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>Is this useful =
discussion of=20
singleton resource pattern? Is this enough detail to be illustrative?=20
Are there other areas that we need to describe with this detail? =
</FONT> <BR><BR><FONT face=3Dsans-serif size=3D2>sgg</FONT> =
<BR><FONT=20
face=3Dsans-serif size=3D2><BR>++++++++<BR>Steve =
Graham<BR>(919)254-0615 (T/L=20
444)<BR>STSM, On Demand Architecture<BR>Member, IBM Academy of=20
Technology<BR><Soli Deo =
Gloria/><BR>++++++++<BR></FONT><BR><BR><BR>
<TABLE width=3D"100%">
<TBODY>
<TR vAlign=3Dtop>
<TD>
<TD><FONT face=3Dsans-serif size=3D1><B>Susan Malaika/Santa=20
Teresa/IBM@IBMUS</B></FONT>=20
<P><FONT face=3Dsans-serif size=3D1>07/10/2004 05:13 PM</FONT> =
</P>
<TD><FONT face=3DArial size=3D1> =
</FONT><BR><FONT=20
face=3Dsans-serif size=3D1> To: =
=20
wsrf@lists.oasis-open.org</FONT> <BR><FONT =
face=3Dsans-serif=20
size=3D1> cc: =20
</FONT> <BR><FONT face=3Dsans-serif size=3D1> =
=20
Subject: [wsrf] Singleton =
Resource=20
Pattern</FONT></TR></TBODY></TABLE><BR><BR><BR><FONT =
size=3D3>I've heard the=20
term "singleton resource pattern" in conversations relating to WSRF. =
Is there=20
a definition?<BR><BR>Susan Malaika</FONT> =
<BR></BLOCKQUOTE></BODY></HTML>
------=_NextPart_001_000E_01C46AF0.CD30A8B0--
------=_NextPart_000_000D_01C46AF0.CD2F2210
Content-Type: image/gif;
name="ATT00044.gif"
Content-Transfer-Encoding: base64
Content-ID: <999553803@16072004-0D84>
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==
------=_NextPart_000_000D_01C46AF0.CD2F2210--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]