RE: Approaches to Web Services Choreography [was Same model for both Public and Private process ??]

Assaf:

See my comments below.


>>
>>> >>Without a doubt the probability of two things defined in isolation
to
>>> work
>>> >>is very low (but if you put enough monkeys on the problem ...) For
>>> >>example,
>>> >>stitching together two BPSS business transactions and presuming
the
>>> >>process
>>> >would be correct.
>>> >>
>>> [JJ] What are you talking about? What process would be correct?
Unlike
>>> some specification (BPEL) BPSS offers a model of composition of
>>> collaboration if this is what you are talking about.
>>
>>If I take a cancel order transaction and put it in a sequence
following a
>>create order transction such that the BPSS collaboration reads: cancel
>>order -> create order, clear this will not work right?
>>
>>That's what monkey's do when they randomly stitch things together. If
you
>>have enough combinations then obviously one will work, which is why an
>>infinite number of monkeys will work. But neither of us are thinking
about
>>that possibility. We think of users working from a visual model to
create
>>a
>>precise definition of what they want to produce.
>>
[JJ] Sorry, I still don't get your argument. If you are looking at a
specification language that prevents "bugs" in collaboration definition,
I think there is still a lot of work to be done to achieve that.

>>As the user creates a definition they end up with any number of
documents.
>>Whether they end up with a BPSS document or a WSCI document or an
BPEL4WS
>>document (or set of documents) the process is identical: if you define
>>what
>>you want to accomplish you end up with a definition that makes it
>>possible.
>>
[JJ] So your argument is, since I can do it with WSCI, why do we even
have a group to discuss ws-c12y? You could all vote immediately to adopt
WSCI and be done with it? I am not sure everyone would agree with that.

>>At this level I see all three approaches as equivalent.
>>
>>
>>> >>What you claim is a limitation of WSCI is actually made worse in
the
>>> BPSS
>>> >>model. As we've already established in your approach you need to
do n
>>> x m
>>> >>stitchings of CPP/CPAs for n suppliers and m buyers (contrast to
>>> WSCI's
>>> >>n+m)
>>> >>and that's quite a lot of monkeys ;-)
>>> [JJ] Assaf, we already had this discussion and I'd be happy to
publish
>>> you comments and conclusion of this discussion which as I recall
were
>>> different from the numbers you are giving above. Here is my side of
the
>>> math. When n suppliers work with m buyers via p collaborations, BPSS
>>> only requires p collaboration definitions (WSCI would allow and
require
>>> at least 2p choreography specifications (mirror of each other at
best),
>>
>>When two parties talk to each other in a choreography there is one
>>choreography. 
[JJ] Yes but in WSCI you need to express two API choreographies + a
global model to achieve a collaboration choreography definition. So yes
they all fit logically in a document, but that sounds like a lot more
work compared to a BPSS specification.

There could be multiple processes in that choreography (just
>>like there are multiple transactions in BPSS), and they are broken
across
>>interfaces with one interface per "actor" and they can be further
broken
>>into namespaces, documents, etc.
>>
>>But we're not talking about XML elements or documents here, we are
talking
>>about definitions. What you call a collaboration is what WSCI captures
in
>>its choreography. For one collaboration there is exactly one
choreography.
>>For p collaborations there are p choreographies.
[JJ] Sorry, I count (2 API choreographies + 1 global model)xp


>>
>>I need to see an example where 2 choreographies are required to make a
>>single collaboration to buy into any other argument.
[JJ] You can take a look at figure 5-3 of the WSCI specification
(section 5-3) this is very enlightening in case you missed it (you know
the airline example). It clearly shows the API choreographies and the
global model. Oh, sorry, I forgot, you are a WSCI author, what was I
thinking? For the rest of us, this pictures reveals exactly and
precisely how WSCI works. 

>>
>>
>>> if you allow divergence between the two sides then the number of
>>> choreography would be anywhere between 2p and nxm). Then you have to
>>> consider the technical binding (CPP/CPA for BPSS, and WSDL for
WSCI).
>>> Again (n+m)p CPPs and yes nxmxp CPAs (to do business you have to
agree).
>>> If the design is not too bad one can reduce the number of CPPs to
(n+m)
>>> (at least each part has to have a URL right?) and the number of CPAs
to
>>> nxm (we agree to implement all these collaborations via this URL). A
>>> think that at this point only telepathy can bit these numbers.
>>
>>The lower bound for WSCI is as follows:
>>
>>- You can describe any number of choreographies in a single WSCI
document,
[JJ] Let's not play with words. I can fit the whole universe in a single
XML document.

>>so in practice you can have one document describing p collaborations.
But
>>that doesn't change anything, the lower bound is that for p
collaborations
>>you need p choreographies (as for BPSS).
[JJ] Again, I count the lower bound as 3p rather than p. If you want to
negotiate, I'd say looking at the simplicity of the global model, I'll
live it at 2.5p




>>
>>- For modularity reasons you may further break the choreography into
>>reusable units (interfaces, processes) that can be pulled into
multiple
>>choreographies, so you may end up with more than p documents for
>>reusability
>>purposes. But that's documents, you still have p choreographies for p
>>collaborations so p is also the upper bound (as for BPSS).
>>
>>- You can describe all the end-points of n suppliers and m buyers in a
>>single WSDL document. But each supplier/buyer is a different service,
so
>>you
>>still have n+m service definitions. Practically you will describe each
>>service in its own documents (best practice). The lower bound is n+m
>>service
>>definitions for n+m services in each choreography (or p(n+m) in
total).
>>
>>In BPSS the lower bound is p distinct collaborations (just like WSCI)
and
>>p(n+m) CPP (just like WSDL). 
[JJ] Sorry, I think your math is wrong again, since a WSDL document
imposes the both sides binding (inbound and outbound) while CPP requires
only the specification of inbound binding, WSDL requires p(nxm) WSDL
specifications. See WDSL couples the CPP and CPA in one single
definition, that's the problem. Let me know if I miss something.


But to that you add p(n*m) CPAs. This is
>>where
>>BPSS increases the complexity. 
[JJ] Have you ever looked at what an ebXML CPA look like? Complexity? My
5 year old daughter can write a CPA any day.

As I said, by applying reasonable simplications you only really need n+m
CPPs and nxm CPAs which are the minimum one can ever reach. ebXML
architecture has completely optimized this aspect.

I am not discussing documents, only lower
>>bound on distinct definitions. The lower bound for BPSS is the lower
bound
>>for WSCI + p(n*m).
[JJ] I know that this what you would like people to believe, but this is
simply wrong. My best estimate is that WSCI requires at the minimum the
specification of 2.5p "choreographies", p(nxm) WSDL specifications
compared to p collaboration, n+m CPPs and nxm very simple CPAs (compared
to a WSDL document).


>>
>>There's another complexity there. For X to talk to Y, X and Y need to
>>first
>>agree on common CPAs. So if I want to buy a book from Amazon I need to
>>coordinate with Amazon and get a CPA we both agree on, where in the
WSDL
>>approach I only need their service definition. That's the easy case.
[JJ] You should really ask CycloneCommerce, Ariba and CommerceOne what
they think about the complexity of connecting business partners together
and if the "buy a book at Amazon" works. How often is UDDI used today?
Of course there is a class of problem that I call the "getQuote" class
that needs to be addressed, but does that require choreography? We are
talking establishing a standard to do choreography not to get a quote or
buy a book.


>>
>>But what if I want Amazon, B&N and Borders to sell my books? Assuming
they
>>all use the same choreography they need to know about my service, but
I
>>need
>>only one service definition which I can make available to all of them.
And
>>the manner by which I provide them with my end-point (aka callback in
this
>>context) is by talking to one of their services (passing process by
name),
>>so I can even automate that step using Web services.
>>
[JJ] I do not deny that there is a class of problem that fit this model,
I am the first one to say that ebXML could be improved. The point again,
is a question of scope. If bringing business partners together was as
simple as you say why would we need to be here in the first place, Ariba
and CommerceOne would have solve that problem a long time ago and
deliver tremendous business value to their customers.

Note also that you are mixing technical binding of a choreography
(CPP/CPA) with the choreography specification (BPSS). The choreography
specification is and must be independent of how an agreement (or lack
thereof) is established.

>>This is where Web services shine. 
[JJ] They shine so much that their core specification WSDL cannot bind
outbound messages.

Reducing complexity and by buying into
>>process mobility allowing you to eliminate the pre-negotiation as a
>>separate
>>state that is not covered by the choreography.
[JJ] In my opinion, the mobility of Pi-calculus translates in the B2B
world into the capability of a given business partner to conduct
business with the same choreography specification regardless of the
business partners it is physically working with. Something that BPSS can
do without problem.

>>
>>
>>> >>I wrote quite a lengthy e-mail explaining how people actually
model
>>> >>choreographies and why they work, basically just repeating what is
>>> already
>>> >>well expressed in the WSCI spec in text, example and diagrams.
Would
>>> it
>>> >>really hurt to quote me in full?
>>> >>
>>> [JJ] If you think that I can keep track of the hundreds of emails
that
>>> you send.
>>
>>I don't.
>>
>>But I made a very clear point in that e-mail and I wish that point was
>>conveyed in its entirety. If someone decides to write multiple APIs -
Java
>>interfaces, WSCI processes, TCP protocols - and just assume they will
work
>>together then that's a fallacy. We are in violent agreement about this
>>point, and I definitely support your position on the value of a
>>collaboration definition.
>>
>>Which is why a choreography language is interesting. It lets the user
>>define
>>a choreography describing precisely how two (or more) services
interact
>>with
>>each other rather than assuming it would work. So my text supported
your
>>position that a choreography language is indeed essential, it just
>>appeared
>>as if I was contradicting myself.
[JJ] Sorry, I never meant to show that, I just noticed that even though
WSCI relies on the modeling of n APIs, these API models need to be
designed together rather than in complete isolation. I don't think that
this is clearly stated in the WSCI spec (and I grant you that this is
mode a documentation point, rather than a specification attribute). 

>>
>>
>>> Is this idea of using WSDL as an end point rather than a starting
point
>>> really bothering you? What is your opinion? I am more interested to
hear
>>> it rather than your attempts to tells things about BPSS which are
simply
>>> incorrect.
>>
>>I support a model in which the lower bound on service definitions is
>>p(n+m)
>>and would like to stick with it rather than switch to a model where
the
>>lower bound on service definition is p(n*m), since it reduces
complexity.
>>
[JJ] So I trust that you are now supporting BPSS? 


>>You reduce the complexity by allowing the service of one supplier to
be
>>used
>>with n buyers and vice versa. It's not possible if you build a net for
>>each
>>combination of buyer/supplier. 
[JJ] Note that you can use Ariba and CommerceOne again to reduce
complexity (nxm to n-1-m). This is déjà vu. Without such intermediary, I
content that one cannot reduce below nxm.

This is where mobility comes into play.
>>Whether you prefer to work with a mobile Petri net, pi-calculus,
>>ss-calculus, extensions to CSP, bigraphs, etc you end up doing the
same
>>thing. You use mobility to reduce complexity.
>>
>>The notion of mobility of processes has been widely researched and
>>supported
>>by a variety of formal models. So this is where I see the value of the
>>WSCI
>>approach: leverage existing research to propose better solutions.
>>
[JJ] I am surprised, as it appears that BPSS seems to be simpler? I
guess not, or could it be that BPSS is more aligned with the concepts of
Pi-calculus.

JJ-
>>arkin
>>
>>
>>>
>>> JJ-
>>>
>>> >>arkin
>>> >>
>>> >>
>>> >>> Since this email where Assaf was asking me to reconsider my
position
>>> I
>>> >>> exchanged multiple emails with him to try to come to a common
>>> >>> understanding and maybe a consensus.
>>> >>>
>>> >>> In the blitz of messages that we exchanged (though it would be
worth
>>> to
>>> >>> summarize it at some point), one comment from Assaf puzzled me.
My
>>> main
>>> >>> point of contention with WSCI is that it models the choreography
>>> (c12y)
>>> >>> of APIs and then via a global model stiches them together
leaving
>>> little
>>> >>> hope to get an overall view of the collaboration itself. Assaf
>>> admitted
>>> >>> that if the APIs were truly designed in isolation the
probability of
>>> >>> being able to choreograph them together would be close to zero
plus
>>> a
>>> >>> few monkeys.
>>> >>>
>>> >>> If you take a closer look at BPEL and WSCI, they both take the
>>> approach
>>> >>> to use what would be otherwise an "internal business process
>>> definition"
>>> >>> to describe how a collaboration operates. The only reason for
that
>>> is
>>> >>> because they are taking WSDL as a starting point and not as and
end
>>> >>> point. BPEL claims without saying it that the "other" services
are
>>> >>> mirror to the one they choreograph, therefore, no need to really
>>> talk
>>> >>> about the "other" side. Hence the concept of serviceLink which
is
>>> just a
>>> >>> point to the "other" mirror service. WSCI goes a little futher
and
>>> allow
>>> >>> for a little more flexibility by allowing somewhat differently
>>> designed
>>> >>> web services to work together but admitting that these services
>>> cannot
>>> >>> of course widely differ from each other.
>>> >>>
>>> >>> In my opinion, using the concept of an "internal business
process
>>> >>> definition" to choreograph a collaboration is a bad idea because
you
>>> >>> then need to articulate how this special "internal business
process
>>> >>> definition" (often labelled as abstract) works with my
"concrete"
>>> >>> internal business process definition which I especially don't
want
>>> to
>>> >>> share with my partners.
>>> >>>
>>> >>> Now if the ws-chor group would consider an alternative approach
of
>>> using
>>> >>> WSDL as an end point and not a starting point, I think it would
>>> greatly
>>> >>> simplify the "web service choreography" problem. In order to
take it
>>> as
>>> >>> an end point, you need to invent a new concept that I call a
message
>>> >>> exchange and what BPSS calls a business transaction. I mention
>>> message
>>> >>> exchange to show how close this is to the concept of message
>>> exchange
>>> >>> pattern being considered by WSDL. Of course in BPSS, a business
>>> >>> transaction is both a business message exchange (e.g.
>>> Request/Response)
>>> >>> and a series of signals as part of the business collaboration
>>> protocol.
>>> >>>
>>> >>> It is relatively easy to choreograph these MEPs or Business
>>> >>> transactions. BPSS is one example. Can be we do a better job? Of
>>> course.
>>> >>> The patterns of Prof. Van der Aalst could help up close on the
>>> control
>>> >>> flow once and for all for instance. Once this is done, this is
were
>>> WSDL
>>> >>> comes to play (one for each side) and where you bind this
>>> choreographed
>>> >>> messaged exchange with each side's WSDL. A message exchange
would
>>> >>> typically be bound to a port.
>>> >>>
>>> >>> As I mentioned several times on this list and others I believe
that
>>> >>> there are 3 entities that need to be modeled (at least):
>>> >>> - Collaboration (between business partners)
>>> >>> - Internal business processes
>>> >>> - long running behavior of components (such as order entry) when
>>> >>> participating in business processes and collaborations.
>>> >>>
>>> >>> I have shown in a paper that this concept of "choreography of
>>> message
>>> >>> exchange" allows you to efficiently model collaboration and
internal
>>> >>> business processes. Once you do that, specifications such as
BPEL or
>>> >>> BPML can be used to model the long running behavior of
components.
>>> >>>
>>> >>> Respectfully,
>>> >>>
>>> >>> Jean-Jacques Dubray,
>>> >>>
>>> >>>
>>> >>> >>-----Original Message-----
>>> >>> >>From: Assaf Arkin [mailto:arkin@intalio.com]
>>> >>> >>Sent: Tuesday, February 04, 2003 2:07 PM
>>> >>> >>To: Jean-Jacques Dubray; 'Ricky Ho'
>>> >>> >>Cc: public-ws-chor@w3.org
>>> >>> >>Subject: RE: Same model for both Public and Private process ??
>>> >>> >>
>>> >>> >>
>>> >>> >>> -----Original Message-----
>>> >>> >>> From: public-ws-chor-request@w3.org
>>> >>> >>> [mailto:public-ws-chor-request@w3.org]On Behalf Of
Jean-Jacques
>>> >>> Dubray
>>> >>> >>> Sent: Tuesday, February 04, 2003 3:26 AM
>>> >>> >>> To: 'Ricky Ho'
>>> >>> >>> Cc: public-ws-chor@w3.org
>>> >>> >>> Subject: RE: Same model for both Public and Private process
??
>>> >>> >>>
>>> >>> >>> [JJ] I assume you think of states in terms of "getting ready
to
>>> >>> >>> send/receive a given message", otherwise, clearly notions
like
>>> "this
>>> >>> >>> order is the approved state" is not necessarily part of the
>>> state of
>>> >>> >>> public processes as BPEL or BPML think about it, let alone
WSCI
>>> and
>>> >>> >>> WSCL. You may want to read the eBTWG - Business Entity Types
>>> >>> Technical
>>> >>> >>> Specification
>>> >>> (http://www.collaborativedomain.com/standards/index.htm
>>> >>> >>> under the BETL section). These guys are working on modeling
>>> these
>>> >>> kinds
>>> >>> >>> of states. I find the concepts of this specification quite
>>> >>> fascinating
>>> >>> >>> actually.
>>> >>> >>
>>> >>> >>Yet, both BPEL and BPML allow you to model the "this order is
the
>>> >>> approved
>>> >>> >>state", whether it is the distinct context in which you
perform
>>> >>> actions,
>>> >>> >>or
>>> >>> >>a value expressed in that context which you can communicate
>>> >>> >>(send/receive),
>>> >>> >>evaluate, correlate, etc.
>>> >>> >>
>>> >>> >>
>>> >>> >>> [JJ] This is actually incorrect. In BPSS for instance, you
>>> clearly
>>> >>> have
>>> >>> >>> business rules that allow you to specify that if a
particular
>>> >>> document
>>> >>> >>> contains a certain value, then the collaboration ought to
>>> continue
>>> >>> that
>>> >>> >>> way, otherwise, it will continue this way. The key though
(and
>>> of
>>> >>> >>> course) is that the condition expression can only apply to a
>>> >>> document
>>> >>> >>> that both parties already successfully exchanged. You cannot
>>> specify
>>> >>> >>> conditions expressions that only one party can evaluate. One
big
>>> >>> >>> difference between public and private processes is that
public
>>> >>> processes
>>> >>> >>> do not have an underlying engine. It is merely the
interaction
>>> >>> between
>>> >>> >>> the private processes that advances the state of the public
>>> process
>>> >>> (aka
>>> >>> >>> collaboration). However, one can formally demonstrate that a
>>> >>> >>> collaboration is also a finite state machine.
>>> >>> >>
>>> >>> >>In other words, if the buyer and supplier agree that an order
is >
>>> >>> $500 as
>>> >>> >>can be calculated from the message (if the schema was known)
the
>>> buyer
>>> >>> can
>>> >>> >>reject the message and the supplier will accept a reject
message.
>>> But
>>> >>> if
>>> >>> >>the
>>> >>> >>supplier has determined that the buyer does not have
sufficient
>>> credit
>>> >>> to
>>> >>> >>purchase the product, the supplier proceed to accept the order
>>> since
>>> >>> the
>>> >>> >>buyer may have a different opinion on the matter ("what do you
>>> mean
>>> >>> >>rejected? you know I'm good for it! I might not have money
right
>>> now,
>>> >>> but
>>> >>> >>I
>>> >>> >>promise to pay you back!").
>>> >>> >>
>>> >>> >>
>>> >>> >>> Once you have established such a model, one can think of how
to
>>> >>> >>> choreograph message exchange, work being done, user
>>> interactions,
>>> >>> and
>>> >>> >>> what not. Please, note that these will never express
"states"
>>> but
>>> >>> rather
>>> >>> >>> "pseudo-state" since the same public/private definition will
not
>>> >>> refer
>>> >>> >>> to a given state of the company but rather to the way state
>>> advances
>>> >>> >>> within the company. It is only when a process instance is
>>> created
>>> >>> that
>>> >>> >>> in effect a "real" state is bound to the process definition,
>>> which
>>> >>> then
>>> >>> >>> controls how this "state" advances.
>>> >>> >>
>>> >>> >>Very well said!
>>> >>> >>
>>> >>> >>
>>> >>> >>> b) it enables unit of work to be more than
"request/response"
>>> >>> agents. In
>>> >>> >>> the example I provide which is very realistic, the Order
entry
>>> >>> component
>>> >>> >>> manages 4 messages as part of the same business process
>>> definition,
>>> >>> not
>>> >>> >>> just request/response.
>>> >>> >>
>>> >>> >>Not everyone has reached the conclusion that a choreography
>>> language
>>> >>> >>should
>>> >>> >>allow you to manage 4 messages as part of the same business
>>> process
>>> >>> >>definition, but at least the languages we are talking about
allow
>>> you
>>> >>> to
>>> >>> >>do
>>> >>> >>that. I think that's a base requirement for all of these
>>> languages. At
>>> >>> >>least
>>> >>> >>something we all have in common ;-)
>>> >>> >>
>>> >>> >>
>>> >>> >>> c) user interactions are part of the process definition
>>> (BPEL/BPML
>>> >>> >>> completely ignore user interactions).
>>> >>> >>
>>> >>> >>I like to think of Web services as presenting a model for user
>>> >>> >>interaction,
>>> >>> >>I like to think of BPEL/BPML/WSCI as supporting any and all
kinds
>>> of
>>> >>> Web
>>> >>> >>services, in particular those representing user interactions,
I
>>> know
>>> >>> of a
>>> >>> >>few products that actually do that and so far with great
success.
>>> So
>>> >>> my
>>> >>> >>limited experience with the usage of this languages seems to
>>> >>> contradict
>>> >>> >>this
>>> >>> >>statement, but again YMMV.
>>> >>> >>
>>> >>> >>
>>> >>> >>> IMHO, this approach is much closer to Pi-calculus than BPML
or
>>> BPEL
>>> >>> will
>>> >>> >>> ever be as it models the business process as an exchange of
>>> message
>>> >>> >>> between independent components (running in their own system
>>> >>> process).
>>> >>> >>> Other specs like BPEL and BPEL use Pi-calculus in the
>>> inter-process
>>> >>> >>> context not the inter-component context. I am not a
specialist
>>> of
>>> >>> >>> Pi-calculus so I'll leave this statement more as a question
than
>>> a
>>> >>> fact.
>>> >>> >>
>>> >>> >>Very interesting.
>>> >>> >>
>>> >>> >>In a previous e-mail I provided an example showing where
>>> pi-calculus
>>> >>> is
>>> >>> >>used
>>> >>> >>for inter-component context. I think that using pi-calculus in
the
>>> >>> >>inter-process context brings tremendous value, so I
highlighted
>>> that
>>> >>> >>possibility, but clearly the example illustrated two
independent
>>> >>> processes
>>> >>> >>executing at two different systems (trading partners, if you
want
>>> to
>>> >>> call
>>> >>> >>it
>>> >>> >>that).
>>> >>> >>
>>> >>> >>Will you consider revisiting that e-mail and commenting on
that
>>> fact?
>>> >>> >>
>>> >>> >>arkin
>>> >>> >>
>>> >>> >>
>>> >>> >>>
>>> >>> >>> If the approach I suggest is proven correct, it could change
the
>>> >>> scope
>>> >>> >>> of the WS-Chor group since it will result in a specification
>>> that
>>> >>> spans
>>> >>> >>> from (BPEL/WSCI/WSCL/BPSS) to (BPEL/BPML). In my opinion, it
>>> will
>>> >>> also
>>> >>> >>> yield significant simplification to the overall space.
>>> >>> >>>
>>> >>> >>> Best regards,
>>> >>> >>>
>>> >>> >>> Jean-Jacques Dubray,
>>> >>> >>>
>>> >>> >>>
>>> >>> >>>
>>> >>> >>> Correct me if I misunderstand, it
>>> >>> >>> >>seems
>>> >>> >>> >>HP's WS-Conversation-Language is taking this approach.
>>> >>> >>> >>
>>> >>> >>> >>But I also hear that "public process" can be described as
a
>>> subset
>>> >>> of
>>> >>> >>> a
>>> >>> >>> >>"private process".  If you take out the "process
variable",
>>> >>> "assign
>>> >>> >>> >>statements", and the "conditions" in the switch blocks and
>>> loops
>>> >>> ...
>>> >>> >>> etc
>>> >>> >>> >>from the "private process", then you will have the "public
>>> >>> process".
>>> >>> >>> In
>>> >>> >>> >>other words, public process can be just use the same model
of
>>> >>> "private
>>> >>> >>> >>process".  It seems WSCI and BPEL-private process is
taking
>>> this
>>> >>> >>> approach.
>>> >>> >>> >>
>>> >>> >>> >>I also heard that the "flow-chart" is equivalent to "state
>>> >>> diagram".
>>> >>> >>> They
>>> >>> >>> >>are just a dual-representation to each other.
>>> >>> >>> >>
>>> >>> >>> >>Any comments and thoughts ... ?
>>> >>> >>> >>
>>> >>> >>> >>Best regards,
>>> >>> >>> >>Ricky
>>> >>> >>>
>>>

Received on Monday, 10 February 2003 21:26:29 UTC