ebxml-tp message


OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Re: service binding - tech comment v0.2 CPP/CPA


Stefano,

This alternative would certainly work. However, in the original
TPA spec, the DeliveryChannel as thought to have "reuse"
semantics. I still think that this is the case (that a delivery
channel can and probably should be "reused" in the context of a
CPP or CPA).

Cheers,

Chris

Stefano POGLIANI wrote:
> 
> Chris,
> 
>         I try to draw a picture of your proposal:
> 
> <CollaborationProtocolProfile>
>    <Party>
>       <PartyDetails>
>       ...
>       </PartyDetails>
>       <Role>
>           <ServiceBinding name="alfa"
>                           collaborationId= --------------+
>                           channelId= ---------+          |
>       </Role>                                 |          |
>       <DeliveryChannel   <--------------------+          |
>                      transport= ---------------------+   |
>                      docExchange= ---------------+   |   |
>           <ServiceBinding href="this_BP"/>       |   |   |
>       </DeliveryChannel>                         |   |   |
>       <DocExchange> <----------------------------+   |   |
>          ...                                         |   |
>       </DocExchange>                                 |   |
>       <Transport> <----------------------------------+   |
>          ...                                             |
>       </Transport>                                       |
>    </Party>                                              |
>    <CollaborationProtocol href="this_BP"> <--------------+
>          This_BP
>    </CollaborationProtocol>
> </CollaborationProtocolProfile>
> 
> Now, I would like to submit an alternative, in order to understand if it
> makes sense:
> 
> <CollaborationProtocolProfile>
>    <Party>
>       <PartyDetails>
>       ...
>       </PartyDetails>
>       <DeliveryChannel
>                      collaborationId= ------------------+
>                      transport= ---------------------+  |
>                      docExchange= ---------------+   |  |
>       </DeliveryChannel>                         |   |  |
>       <DocExchange> <----------------------------+   |  |
>          ...                                         |  |
>       </DocExchange>                                 |  |
>       <Transport> <----------------------------------+  |
>          ...                                            |
>       </Transport>                                      |
>    </Party>                                             |
>    <CollaborationProtocol href="this_BP" <--------------+
>                           name="This_BP">
>        <Role name="the_role_name"
>              href="that_role_in_this_BP">
>        </Role>
>    </CollaborationProtocol>
> </CollaborationProtocolProfile>
> 
> I think that the advantage of this second approach would be:
> 1.      It makes explicit that the DeliveryChannel is the composition
>         of the "role played in a given BP" together with the technical
>         infrastructure made explicit by both the Transport and the
>         DocExchange
> 2.      The <CollaborationProtocol> would immediately mean "the role
>         played by a Party in a given BP". The meaning of such a tag
>         would be more "compact"
> 3.      I think that, in the context of the CPP, the CollaborationProtocol
>         would not need to reference the BP in an abstract way. In the
>         context of the CPP, the BP would always need to be qualified
>         by the role that such Party would be able to play.
> 4.      As I mentioned in one reply to Dale, it would be simpler to make
>         a composition of two CPPs into a CPA. (the reference is in the
>         attached email)
> 
> Perhaps, in order to be more clean, a 3rd approach like the following one
> would be also to evaluate:
> 
> <CollaborationProtocolProfile>
>    <Party>
>       <PartyDetails>
>       ...
>       </PartyDetails>
>       <DocExchange> <-------------------------------+
>          ...                                        |
>       </DocExchange>                                |
>       <Transport> <-----------------------------+   |
>          ...                                    |   |
>       </Transport>                              |   |
>    </Party>                                     |   |
>    <CollaborationProtocol href="this_BP" <---+  |   |
>                           name="This_BP">    |  |   |
>        <Role name="the_role_name"            |  |   |
>              href="that_role_in_this_BP">    |  |   |
>        </Role>                               |  |   |
>    </CollaborationProtocol>                  |  |   |
>    <DeliveryChannel                          |  |   |
>                   collaborationId= ----------+  |   |
>                   transport= -------------------+   |
>                   docExchange= ---------------------+
>    </DeliveryChannel>
> </CollaborationProtocolProfile>
> 
> The difference between this 3rd approach and the 2nd one is that the
> DeliveryChannel has been exported OUTSIDE the Party since it was
> referencing (in the 2nd approach) both elements INSIDE the Party and
> outside it.
> 
> Does this make any sense ?
> 
> /Stefano
> 
> > -----Original Message-----
> > From: christopher ferris [mailto:chris.ferris@east.sun.com]
> > Sent: 22 January 2001 19:14
> > To: ebxml-tp@lists.ebxml.org
> > Subject: service binding - tech comment v0.2 CPP/CPA
> >
> >
> > All,
> >
> > One of the issues that has been discussed both on and
> > off list is the purpose and function of the ServiceBinding
> > element.
> >
> > There has been some confusion and also some concern that
> > the current draft of the CPP will make it difficult
> > at best for automated CPP+CPP->CPA mapping.
> >
> > One of the concerns was that in the current design, it is difficult
> > to determine if all of the messages for a given collaboration
> > protocol are actually "bound" to a DeliveryChannel.
> >
> > Another concern raised is how to map alternate delivery channels
> > to a given collaboration protocol, etc.
> >
> > I would therefore like to propose the attached revision to the
> > Role element that I think will make things a little clearer
> > than they are in v0.2 as well as to provide a little better
> > closure on ensuring that all messages are "bound" to
> > a delivery channel.
> >
> > This proposal also involves removing the ServiceBinding child
> > element from the DeliveryChannel, as this function is now covered
> > with the attached proposed change to the Role and ServiceBinding
> > elements.
> >
> > Comments are encouraged.
> >
> > Cheers,
> >
> > Chris
> >
> 
>   ----------------------------------------------------------------------------------------------------
> 
> Subject: RE: Sanity check needed for struggling TPA participant
> Date: Fri, 19 Jan 2001 11:33:48 +0100
> From: Stefano POGLIANI <stefano.pogliani@sun.com>
> To: Martin W Sachs <mwsachs@us.ibm.com>,
>      christopher ferris <chris.ferris@east.sun.com>,
>      "Moberg, Dale" <Dale_Moberg@stercomm.com>
> CC: ebxml-tp@lists.ebxml.org
> 
> Dear all,
> 
>         in a previous message I proposed to "include" the ROLE definition as part
> of the CollaborationProtocol tag.
> 
> In this view, if a CPP would need to support two roles for the same BP
> ("buyer" and "seller"), then I would end up in having two dinstinct
> CollaborationProtocol tags, each of them referring to the same BP but to a
> different ROLE.
> 
> I try to play using the assumption of ROLE as a qualifier for the
> CollaborationProtocol.
> What happens if I try to compose a CPA from two CPPs structured in such a
> way?
> 
>     CPP_1                            CPP_2
>       CollaborationProtocol_1_1        CollaborationProtocol_2_1
>           The_BP                           The_BP
>           Buyer_Role                       Buyer_Role
>       CollaborationProtocol_1_2        CollaborationProtocol_2_2
>           The_BP                           The_BP
>           Seller_Role                      Seller_Role
>       DeliveryChannel_1_1              DeliveryChannel_2_1
>           CollaborationProtocol_1_1        CollaborationProtocol_2_1
>           Transport_alfa                   Transport_beta
>       DeliveryChannel_1_2              DeliveryChannel_2_2
>           CollaborationProtocol_1_2        CollaborationProtocol_2_2
>           Transport_beta                   Transport_alfa
> 
> (I did not use tabs, so the schema should be readable)
> 
> I think that the match needs to be done against the DeliveryChannel tags for
> composing the CPA.
> In this case, since the Transport characteristics of the DeliveryChannels
> differ (Transport_alfa and Transport_beta), then the match would be
> automatic (more or less) producing TWO DIFFERENT CPAs:
> 
>     CPA_result_1                       CPA_result_2
>       Party_1                            Party_1
>         DeliveryChannel_1_1                DeliveryChannel_1_2
>            CollaborationProtocol_1_1         CollaborationProtocol_1_2
>            Transport_alfa                    Transport_beta
>       Party_2                            Party_2
>         DeliveryChannel_2_2                DeliveryChannel_2_1
>            CollaborationProtocol_2_2         CollaborationProtocol_2_1
>            Transport_alfa                    Transport_beta
> 
> In this case, CPA_result_1 implies Party_1 being the BUYER and Party_2 being
> the SELLER. And CPA_result_2 is the viceversa.
> 
> Now, let's suppose the case where the Transports are identical:
> 
>     CPP_1                            CPP_2
>       CollaborationProtocol_1_1        CollaborationProtocol_2_1
>           The_BP                           The_BP
>           Buyer_Role                       Buyer_Role
>       CollaborationProtocol_1_2        CollaborationProtocol_2_2
>           The_BP                           The_BP
>           Seller_Role                      Seller_Role
>       DeliveryChannel_1_1              DeliveryChannel_2_1
>           CollaborationProtocol_1_1        CollaborationProtocol_2_1
>           Transport_alfa                   Transport_alfa
>       DeliveryChannel_1_2              DeliveryChannel_2_2
>           CollaborationProtocol_1_2        CollaborationProtocol_2_2
>           Transport_alfa                   Transport_alfa
> 
> How the composition could happen? Since the Transport is no more a
> discriminant, the software will be required to go "drilling" into the
> CollaborationProtocol. The software would be instructed to drill down into
> the CollaborationProtocol and:
>         - verify if the BP reference is the same
>         - in case teh BP is the same, then to verify that the ROLEs are DIFFERENT
> 
> Again, follwoing this logic, we would arrive to the same result as before,
> such as :
> 
>     CPA_result_3                       CPA_result_4
>       Party_1                            Party_1
>         DeliveryChannel_1_1                DeliveryChannel_1_2
>            CollaborationProtocol_1_1         CollaborationProtocol_1_2
>            Transport_alfa                    Transport_alfa
>       Party_2                            Party_2
>         DeliveryChannel_2_2                DeliveryChannel_2_1
>            CollaborationProtocol_2_2         CollaborationProtocol_2_1
>            Transport_alfa                    Transport_alfa
> 
> In this case, CPA_result_3 implies Party_1 being the BUYER and Party_2 being
> the SELLER. And CPA_result_4 is the viceversa.
> 
> If I haven't missed some obvious issue, it proves that the idea of having
> the ROLE as a qualifier of the CollaborationProtocol is not only more clear
> but would also have an advantage in the CPA composition process.
> 
> BTW, an additional advantage (referring to another thread) is the having the
> ROLE as a qualifier of the CollaborationProtocol would make the ROLE
> UNAMBIGUOUS.
> 
> Best regards
> 
> /Stefano
> 
>  -----Original Message-----
>  From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
>  Sent: 19 January 2001 03:17
>  To: christopher ferris
>  Cc: Moberg, Dale; Christopher Ferris; ebxml-tp@lists.ebxml.org
>  Subject: Re: Sanity check needed for struggling TPA participant
> 
> 
> 
>  I put this out to the TP list for more input.
> 
>  It may be too late at night to parse this stuff properly but I think I
>  agree with most of it.
> 
>  I'm not quite sure that it does the case that I brought up.  I have a CPP
>  for collaboration protocol A with, say, buyer and seller roles.  Using the
>  same CPP, I want to express that I can act as "buyer" with some partners
>  and as "seller" with others.  Based on Chris' proposal below, I would
>  define two role tags under my Party tag.  One would be for "buyer" and the
>  other for "seller".  The associated service binding tags would both point
>  to the same collaboration protocol tag.  This seems OK.
> 
>  However I think there is a problem both with this one and with
>  the one that
>  I originally suggested (below).  If I try to compose a CPA from similar
>  CPPs for two parties, I don't see any way for the composition software to
>  figure out which party will be "buyer" and which will be "seller".  I can
>  think of two ways out of this ambiguity:
> 
>     1. Admit that this case requires negotation after composition.
> 
>     2. Say that this CPP is invalid and if a party wants to
>  represent itself
>     as capable of being either "buyer" or "seller" in different
>  CPAs for the
>     same process, that it should have two CPPs, one for each role.
> 
>  I think that the above is equivalent to the ambiguity that Chris noted at
>  the bottom of his posting below. I would note that the validation process
>  he mentions also to has to be sure that all the three roles are filled.
> 
>  Regards,
>  Marty
> 
>  ******************************************************************
>  *******************
> 
>  Martin W. Sachs
>  IBM T. J. Watson Research Center
>  P. O. B. 704
>  Yorktown Hts, NY 10598
>  914-784-7287;  IBM tie line 863-7287
>  Notes address:  Martin W Sachs/Watson/IBM
>  Internet address:  mwsachs @ us.ibm.com
>  ******************************************************************
>  *******************
> 
> 
> 
>  christopher ferris <chris.ferris@east.sun.com>@east.sun.com on 01/18/2001
>  03:23:16 PM
> 
>  Sent by:  Chris.Ferris@east.sun.com
> 
> 
>  To:   Martin W Sachs/Watson/IBM@IBMUS
>  cc:   "Moberg, Dale" <Dale_Moberg@stercomm.com>, Christopher Ferris
>        <chris.ferris@east.sun.com>
>  Subject:  Re: Sanity check needed for struggling TPA participant
> 
> 
> 
>  Dale, Marty,
> 
>  There's another way to look at this issue. I certainly
>  concur with all of Marty's observations and clarifications.
> 
>  However, I also do agree that there exists the potential for
>  some "orphaned" messages that are not associated with given
>  DeliveryChannel.
> 
>  I propose the following change, that may serve to address
>  the concern raised by Dale:
> 
>  A CollaborationProtocol (which is a reference to a business process model)
>  has a "default" DeliveryChannel with which it is associated. It MAY also
>  have alternate DeliveryChannel(s) associated. As Scott has pointed out,
>  we would want to express this manner of optionality/choice in a
>  consistent manner as with other aspects of choice in the model. I would
>  propose that order in a sequence be treated as preference order
>  (1st preference, 2nd preference, etc.)
> 
>  I would also propose that ServiceBinding be dropped from DeliveryChannel
>  and that we augment the ServiceBinding to bind a CP (an IDREF instead of
>  an xlink:locator) to a DeliveryChannel. I would then propose that
>  if certain messages (or transactions) require an alternate
>  DeliveryChannel,
>  that these be called out as children of the ServiceBinding element.
>  Finally, we can capture all of this under Role.
> 
>  <CollaborationProtocolProfile>
>  <Party>
>       ...
>       <Role roleId="" name="" certId="">
>            <!-- primary binding with "default" DeliveryChannel associated
>  -->
>            <ServiceBinding collaborationId="" channelId="">
>                 <!-- override "default" deliveryChannel -->
>                 <Override transactionOrMessage="" channelId=""/>
>            </ServiceBinding>
>            <!-- either this is the primary binding for another
>                 business process OR it is the first alternate binding for
>                 one which precedes it with the same collaborationId -->
>            <ServiceBinding collaborationId="" channelId="">
>                 <Override transactionOrMessage="" channelId=""/>
>            </ServiceBinding>
>       </Role>
>       ...
>  </Party>
>  <CollaborationProtocol id=""
>       xlink:type="locator"
>       xlink:href="">BuyAndSell</CollaborationProtocol>
>  </CollaborationProtocolProfile>
> 
>  As to a related issue on service bindings, I disagree that there
>  would be two instances of a CollaborationProcess each identifying the
>  same process definition document. There should only be one that
>  is referenced multiply if the Party plays multiple roles in the
>  same business process. I was almost ready to say:
>       Certainly a CPA would only identify a single role
>       within a single business process for a given party.
>  HOWEVER, given that there MAY be more than two roles defined
>  within a business process, a party MAY fill more than one of the
>  roles. This MAY lead to some confusion because it isn't quite
>  deterministic.
> 
>  As an example: a process may be defined as having three roles:
>       buyer
>       seller
>       creditor
> 
>  A large company like Ford might fulfil two of the three roles (as
>  they have
>  a financing division)
> 
>  e.g. seller and creditor
> 
>  A smaller company might only act in one of the roles (seller)
>  and leave the third role to yet another CPA with yet another Party
>  such as Citicorp.
> 
>  Hmmm... this means that a "validation" process outside of a
>  DTD or schema validation would be needed to ensure that if more than
>  two roles are defined for a business process that a given role
>  is NOT associated with more than a single Party in a CPA.
> 
>  Cheers,
> 
>  Chris
> 
> 
>  Martin W Sachs wrote:
>  >
>  > Dale,
>  >
>  > See my replies embedded below.
>  >
>  > Regards,
>  > Marty
>  >
>  >
>  ******************************************************************
>  *******************
> 
>  >
>  > Martin W. Sachs
>  > IBM T. J. Watson Research Center
>  > P. O. B. 704
>  > Yorktown Hts, NY 10598
>  > 914-784-7287;  IBM tie line 863-7287
>  > Notes address:  Martin W Sachs/Watson/IBM
>  > Internet address:  mwsachs @ us.ibm.com
>  >
>  ******************************************************************
>  *******************
> 
>  >
>  > "Moberg, Dale" <Dale_Moberg@stercomm.com> on 01/18/2001 01:26:26 PM
>  >
>  > To:   Martin W Sachs/Watson/IBM@IBMUS, "Christopher Ferris (E-mail)"
>  >       <chris.ferris@east.sun.com>
>  > cc:
>  > Subject:  Sanity check needed for struggling TPA participant
>  >
>  > Hi
>  >
>  > I am trying to figure out how to include the sender transport info but
>  got
>  > stuck on something else on the way to it. I need to see whether my
>  > observation here makes sense or I am just overlooking something. I think
>  > I am getting the hang of the XML modelling style in the cpp v0.23 and
>  > how you have chosen to notate some relationships, but if I am right
>  > I think something is missing.
>  >
>  > This is just to Marty and Chris. Following your comments, I can post
>  > something to the list that sharpens the issue. I hope the following
>  > is at least intelligible to you. Please ask for clarification as needed.
>  >
>  > Dale
>  > ===========================================================
>  > Capability Capture and The Issue of Association.
>  >
>  > <!-- (PartyId+ , PartyDetails , Role+ ,
>  > Certificate+ , DeliveryChannel+ ,
>  > Transport+ , DocExchange+ )-->
>  >
>  > Are we capturing the associations
>  > that are needed to understand
>  > the capabilities enabling b2b interoperability?
>  > While we have most of the most common capabilities
>  > described at some level of detail, what is not so
>  > clear is that we have ways of stating how these
>  > capabilities are associated and are integrated
>  > within a given party's software implementation.
>  >
>  > MWS:  We have the capability now to some extent.
>  > See below.
>  >
>  > If we consider our representation of a party, (above)
>  > and ignore PartyDetails and Certificate elements,
>  > the Party element consists of a nonempty sets
>  > of PartyIds, Roles, DeliveryChannels, Transports,
>  > and DocExchanges.
>  >
>  > MWS:  one clarification:  The non-empty set conisists
>  > of PartyIDs, Roles, and DeliveryChannels.  Transports
>  > and DocExchanges are referenced by delivery channels,
>  > so they are logically parts of the de3livery channel.
>  >
>  > The connection to BPs occurs
>  > via the Role, and so the party element looks
>  > as if it relates a party in a BP Role to its Transports
>  > and DocExchange details. This is the basic
>  > information that we need to know about a
>  > party's capabilities for collaborating in a BP.
>  > So far so good.
>  >
>  > MWS:  Remember:  the connection to BPs occurs in two
>  > places, the service bindings tag under role and the
>  > service binding tag under delivery channel.
>  >
>  > But next consider
>  > what happens when,
>  > except for PartyId,
>  > each of these sets have
>  > more than one element.
>  >
>  > Which Role goes with which Transport
>  > and  which DocExchange element(s)?
>  > It is certainly possible that a given
>  > Role may fail to be reachable by some
>  > of the transports. Likewise, only some
>  > of the DocExchanges may be relevant
>  > to a given Role instance. So how do
>  > we tell which Role goes with which
>  > Transports and which DocExchange
>  > instances? This is the association
>  > issue I want to raise.
>  >
>  > MWS:  see additional discussion at end.
>  >
>  > MWS:  You seem to be mainly concerned with associating
>  > doc exchange and transport properties with an individual
>  > role.  We need to be able to do it but I think we need
>  > more work with the BP team on this.  At some point, we
>  > want to be able to associate a delivery channel with a
>  > role and underneath the role with specific message
>  > exchanges (business transaction?) and perhaps
>  > with specific messages. This is equivalent to binding
>  > a delivery channel with a role but possibly a different
>  > delivery channel for each business transaction. That
>  > means being able to point an xlink directly at a business
>  > transaction, role, or message.  I'm not sure that the
>  > specification schema is crisp enough yet to do this.
>  >
>  > MWS:  The operative point is your next paragraph;
>  > the delivery channel is important to your questions,
>  > though my comment directly above is still part of
>  > the discussion.
>  >
>  > So far you will note that I have suppressed
>  > discussion of the DeliveryChannel. Will that
>  > set help? In a way the DeliveryChannel
>  > is itself part of the association, for a look
>  > inside its structure reveals that a DeliveryChannel
>  > is an association of a Transport and a DocExchange.
>  > So perhaps if we focus on DeliveryChannel
>  > we will find the needed information about
>  > associations. However, there remains one
>  > gap-- the Role, which is a view on the BP,
>  > is not associated with any of the ChannelIds!
>  >
>  > MWS:  As I indicated above, there is an implicit
>  > assocation between the delivery channel and a role
>  > through the linkage between the delivery channel and
>  > a specific business transaction or message, once we
>  > know how to make that linkage. However maybe we
>  > should make that association explicit.  Read on.
>  >
>  > MWS:  The delivery channel is, as you say, an
>  > association between a transport and a doc exchange.
>  > In addition, as I mentioned above, a delivery channel
>  > is also associated with some aspect of the collaboration
>  > protocol via the delivery channel service binding.
>  >
>  > What we need is some other element, akin to
>  > DeliveryChannel, which consists of
>  > pairs of the RoleId with the ChannelId.
>  > In this way the associations we need
>  > to capture can be expressed. Or we
>  > are at least one step closer.
>  >
>  > MWS:  One way to directly associate a role with
>  > a delivery channel is to move the role tag under
>  > the delivery channel tag and allow inclusion of either
>  > one or both roles there.  In that case, we could probably
>  > also eliminate service binding from role since the
>  > delivery channel service binding should then be sufficient
>  > for both role and delivery channel.
>  >
>  > MWS:  What remains is your question above: "So how do
>  > we tell which Role goes with which
>  > Transports and which DocExchange
>  > instances?". The answer to this question is that we
>  > define different delivery channels with the needed
>  > different combinations of transport and doc exchange
>  > definitions. This capability is already defined in
>  > the CPP and prior to that in the IBM tpaML proposal.
>  > We can then associate each of those delivery
>  > channels with the appropriate role and
>  > the appropriate  business transaction
>  > or message.  As long as the different combinations are at
>  > the granularity of combinations of transport and doc exchange,
>  > this should work fine.  If we see a need for combinations and
>  > permutations at a finer level of granularity (i.e. individual
>  > transport or delivery channel characteristics,  we will need
>  > to consider a different representation since a
>  > finer level of granularity could explode the number of
>  > delivery channels needed to express it to an undesirable
>  > degree.  My advice is to restrict ourselves to combinations
>  > of complete doc exchange and transport definitions for now
>  > and leave finer granularity for beyond version 1.0
> 
>  --
>                                 Christopher Ferris
>      _/_/_/_/ _/    _/ _/    _/ Sr Staff Engineer - XTC Advanced
>  Development
>     _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
>    _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
>         _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
>  _/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903
> 
> 
> 
> 
> 

-- 
                               Christopher Ferris
    _/_/_/_/ _/    _/ _/    _/ Sr Staff Engineer - XTC Advanced Development 
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063      
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903
begin:vcard 
n:Ferris;Christopher 
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XML Technology Development
adr:;;One Network Drive;Burlington;Ma;01824-0903;USA
version:2.1
email;internet:chris.ferris@east.Sun.COM
title:Sr. Staff Engineer
x-mozilla-cpt:;0
fn:Christopher Ferris
end:vcard


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC