Subject: RE: service binding - tech comment v0.2 CPP/CPA
What would make my proposal NOT reusable (or less reusable than the current
one)?
/Stefano
» -----Original Message-----
» From: Chris.Ferris@east.sun.com [mailto:Chris.Ferris@east.sun.com]
» Sent: 23 January 2001 17:17
» To: Stefano POGLIANI
» Cc: ebxml-tp@lists.ebxml.org
» 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
Powered by
eList eXpress LLC