Re: Réf. : Re: [ESDS] Draft Problem Statement 00

[Mark Harrison <[e-mail]>]

Dear Gregor, ESDS folks,

It is certainly our intention to keep the ESDS protocol as generic as  
possible, rather than being specific to any particular industry sector.
Regarding keeping the ESDS thin, the minimalist approach to ESDS is  
for ESDS to respond to a query about a unique ID of an object by  
returning a list of links to addresses of multiple information  
services from across the supply chain (and extended product lifecycle,  
from design and manufacturing through usage, repair and end-of-life)  
and allow those information services to hold the detailed information,  
ideally accessible through a standard interface that also supports  
industry-specific vocabularies / data fields.

An EPC Information Service is one example of the kind of service that  
an ESDS might link to - but there are also other kinds of services,  
such as web services in general, dynamic web pages for individual  
objects, etc.  One ESDS might also link at serial-level to another  
ESDS.  An example of that scenario might be if two different ESDS  
services are responsible for covering different geographic regions and  
the object travels across both regions at some time in its life.

As you and Jan both say, it is important to keep application-level  
functionality outside of ESDS - but ensure that ESDS only provides  
sufficient information and functionality for track-and-trace  
APPLICATIONS to do analysis of the data, handle reconciliation etc.

Regarding your comments about message queues, I am not sure whether we  
share the same concept of what an ESDS is.

In the past, much business-to-business communication was built around  
EDI, messaging and global data synchronization networks.

For serial-level data, this model might not be such a good fit,  
because of two main factors:

1) we might be dealing with much larger volumes of data (records or  
events for each individual object, rather than each object type/class,  
batch, lot or shipment)
2) serial-level records can reveal commercially sensitive information  
about volumes and flows of goods - so we may need to be much more  
selective about who receives that data.

For these reasons, it is important to minimize unnecessary network  
traffic and allow organizations to maximize control over their own  
serial-level data, e.g. by setting fine-grained access control  
policies that govern who is allowed to retrieve or receive particular  
data.

For serial-level information, it may be more appropriate to consider  
that each company will store their own data - and only share it on  
demand with other organizations that they trust, rather than  
distributing it by default through existing messaging services.

Of course there is a role for message queues, for example to support  
output from standing queries - but I think the primary focus of  
Discovery Services is to provide links that enable applications to  
gathering information from multiple sources, rather than being just  
another message distribution service.

Having said that, there may be *implementations* of both Discovery  
Services and EPCIS, which attempt to bridge the gap with the EDI/ 
messaging paradigm, e.g. by treating a message archive as an event  
repository and providing a standard query interface, (such as EPCIS  
query interface) to that repository  - or by extracting information  
from message relays in order to populate a Discovery Service with a  
list of information providers.  However, these are 'hybrid  
implementations' and do not in my opinion change the primary focus of  
the protocol for Discovery Services.

I hope this discussion is helpful.  Perhaps Jan or Marie or someone  
else from SITA has a comment on this topic? (I suggest SITA because  
they have a history of dealing with EDI messaging but are also moving  
towards the on-demand retrieval of serial-level data via their Auto-ID  
services.)

Best regards,

- Mark Harrison


On 30 Jan 2008, at 09:24, Gregor Baues wrote:

> Jan, all
>
> I fully agree with your view ESDS has to stay lean, simple fast to  
> deploy. ESDS should not take care about specific
> functionality of a given industry as it is not in terms of  
> archirecture on the Enterprise / Buisness level but on the  
> infrastructure level. We would not ask for e.g. baggage  
> reconcilation functionalty inside the ESDS although this could be a  
> place to do parts of this process but this is part of the backend  
> buisness systems and not an architectural pattern we would like to  
> see.
>
> As a fast shortcut ESDS could be seen as the MQseries of the  
> internet which makes it extremely interesting as we have a unified  
> interface for thousands of possible partners in our industry and we  
> do not have to do individual technical integration with each of them.
>
> Actually you could even replace the term 'Supply Chain' by 'Queue' -  
> Most of the time i would use ESDS not with a "Supply Chain"  
> semantics at all. Please keep it as much, if not totally, industry  
> agnostic in order to allow a true universal
> usage thus keeping ESDS at the infrastructure level. This would lead  
> also to a much larger disemination of the uasage of such a service.
>
> Let the variours industries define the messages and the semantics of  
> the messages fllowing through the system and build their relations.
>
> Best Regards
>
> Gregor Baues
> Chief Architect Application Platform
> Air France Information System
>
> [e-mail] a écrit : -----
>
> Pour : Mark Harrison <[e-mail]>
> De : [e-mail]
> Date : 01/29/2008 08:20PM
> cc: Ashkan Fadaiefard/Simard <[e-mail]>ca>, [e-mail]
> Objet : Re: [ESDS] Draft Problem Statement 00
>
> Mark, all,
>
> Just one general comment:
> What we should keep in mind is that the DS is a "THIN" service.
> As long as the service is thin, slim etc I see no problem in adding  
> some
> functionality.
> It should not however evolve in to a full fledged application service.
> That's not what it is intended to be.
>
> Best regards,
>
> Jan
>
> Jan Boen
> Director Auto ID SET
> CSBU - SITA
>
> Tel: [phone]
> Fax: [phone]
> Mobile: [phone]
> E-mail: [e-mail]
>
>
> Mark Harrison
> <mark.harrison@ca
> ntab.net>                                                  To
> Ashkan Fadaiefard/Simard
> 29/01/2008 19:47          <[e-mail]> cc
> [e-mail]
> Subject
> Re: [ESDS] Draft Problem Statement
> 00
>
>
>
>
>
>
>
>
>
> Dear Ashkan,
>
> Many thanks for posting these use cases to the ESDS mailing list.  It
> is always very helpful to receive such input from potential end-users
> of Discovery Services.
>
> I agree with you that it may be important to be able to record changes
> of aggregation (including disaggregation) within a Discovery Service,
> even if such aggregation events are also available within an
> information service (e.g. an EPC Information Service) provided by an
> organization that is doing the aggregation / disaggregation.
>
> One of the problems with relying on 'following the chain' from the
> manufacturer to the current downstream custodian of the object is that
> there could be a broken link in the chain if one of the organizations
> does not provide an onward link - or if their information service is
> temporarily (or permanently) unavailable.  A Discovery Service can
> provide some resilience to ensure that (subject to having the correct
> credentials and access privileges), it is always possible to 'navigate
> beyond a broken link' to find who currently has the object.
>
> However, if the identifier of the object to be tracked changes at some
> intermediate point within the supply chain, then this is potentially
> equivalent to a broken link.  Aggregation and disaggregation (as well
> as re-labelling) all represent a change of identifier (including
> convergence or divergence between one identifier and the identifiers
> of many 'child' objects contained within a 'parent' container) - so in
> order to solve the 'broken link' problem, we may well need to allow
> for changes of aggregation to also be stored within Discovery
> Services, even if such information is also available elsewhere most of
> the time (e.g. in EPC Information Services of individual companies).
>
> Although the current ESDS internet drafts do not explicitly support
> aggregation event at this time, the EU BRIDGE project has considered
> this in their design for Discovery Services.  We have contributed a
> number of our public documents to the ESDS mailing list and also begun
> a comparison of the ESDS internet drafts with the BRIDGE designs.  The
> initial version of this comparison exercise will be posted to the ESDS
> mailing list very soon and is intended to stimulate discussion on
> topics, such as the one you raise, regarding aggregation changes.
>
> Many thanks for your comments today.  We look forward to further
> discussions with you.
>
> Best regards,
>
> - Mark Harrison
>
>
> On 29 Jan 2008, at 16:07, Ashkan Fadaiefard/Simard wrote:
>
> >
> > Dear ESDS group,
> >
> > I have read the proposed Problem Statement, and I had some comments.
> > As a large logistic company the problem of Discovery Service is of
> > interest to us. I feel that an important scenario is missing from  
> the
> > document, and that is aggregation and disaggregation. The use case
> > below explains the scenarios in detail.
> >
> > Products produced from manufacturers can be packaged differently.
> > Single product in one box, or multiply products in one box.
> > For example a shoe company produces shoes from different  
> manufacturer.
> > Some manufactures packages one pair of shoe in one box and some  
> others
> > will put multiply boxes of shoes, different sizes and colour mixed  
> in
> > one larger box. Once the products arrive in the distribution centre,
> > the products needs to be sorted based on their model, colour and  
> size
> > however all the boxes have the same tag thus the distribution
> > centre needs to identify each box and apply new tags.
> >
> > Another example is when a box contains 1000 products. The box is
> > tagged as 1 box set to contain 1000 products. In a pick and pack
> > operation the box
> > will be opened and based on orders from retailers the products will
> > be removed
> > from the box thus the inventory of the box is reduced however the  
> tag
> > still reads 1000 products. Also the products shipped to the
> > retailers need to be
> > re-tagged before shipping to consignee.
> >
> > So in the future, when we want to have visibility from beginning to
> > end of a supply chain,
> > we need to have proper handling (protocol) for this kind of  
> scenario.
> >
> >
> > Best Regards,
> > Ashkan Fadaiefard_______________________________________________
> > ESDS mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/esds
>
>
> _______________________________________________
> ESDS mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/esds
>
>
>
>
> This document is strictly confidential and intended only for use by  
> the addressee unless otherwise stated.  If you are not the intended  
> recipient, please notify the sender immediately and delete it from  
> your system.
>
>
>
> _______________________________________________
> ESDS mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/esds


_______________________________________________
ESDS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/esds