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

From: Gregor Baues <[email-masked]>
Date: Wed, 30 Jan 2008 10:24:46 +0100

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

[email-masked] a écrit : -----

Pour : Mark Harrison <[email-masked]>
De : [email-masked]
Date : 01/29/2008 08:20PM
cc: Ashkan Fadaiefard/Simard <[email-masked]>, [email-masked]
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: +32 2 745 0598
Fax: +32 2 745 0570
Mobile: +32 473 933 190
E-mail: [email-masked]

             Mark Harrison
             <mark.harrison@ca
             ntab.net>                                                  To
                                       Ashkan Fadaiefard/Simard
             29/01/2008 19:47          <[email-masked]>
                                                                        cc
                                       [email-masked]
                                                                   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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/esds

_______________________________________________
ESDS mailing list
[email-masked]
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/esds

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

---

From: Mark Harrison <[email-masked]>
Date: Wed, 30 Jan 2008 15:35:10 +0000

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
> 29/01/2008 19:47          <[email-masked]> cc
> [email-masked]
> Subject
> 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.
>
>
>

---

From: Gregor Baues <[email-masked]>
Date: Thu, 31 Jan 2008 12:46:32 +0100

Dear Mark, ESDS community

my > comments below  in the text.

Best Regards

Gregor

             Mark Harrison                                                 
             <mark.harrison@ca                                             
             ntab.net>                                                   A 
             Envoyé par : Mark         Gregor Baues <[email-masked]> 
             Harrison                                                   cc 
             <[email-masked]         [email-masked], [email-masked],  
             .ac.uk>                   Ashkan Fadaiefard/Simard            
                                       <[email-masked]>             
                                                                     Objet 
             01/30/2008 04:35          Re: Réf. : Re: [ESDS] Draft Problem 
             PM                        Statement 00                        

                                                                           

Dear Gregor, ESDS folks,

> I might have here some misunderstanding and you may correct me. In
> my opinion ESDS can provide links but if it does ESDS starts replacing
> UDDI in the SOA world refrencing the services my IT system will offer
> to others in B2B integration schemas. The model for those services
> can be defined on an industry level as we do this for part of our
> business or in a P2P manner. In any case i will manage all aspects of
> access to information in the backend system and i want to be in contol
> what information is available to others. If its only links no ESDS
> is ractually required as i can pull off information from all
> of my partners just using Webservices which have been agreed upon.

> The real point to ESDS, from my point of view, is to get unsollicited
> event information about the objects i am interested in and for which
> i have the appropriate rights.

objects, etc.

> To my understanding ESDS is technically a Webservice architecture
> isn't it anyway but on an infrastructure level i.e. "technical services"
> and not "business services". The buisness comes with the data delivered
> by the service. Being a standard protocol this is how webpages,
> RIA application etc ... would integrate and leverage the ESDS.
> The point to ESDS is that i have a single www definition of such a
> service and i don't have to discuss technical integration details
> with my partners or agree to "business level" webservices in order
> to manange event data exchange.

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.

> That is a manadtory part of the ESDS architecture because everybody
should
> be free to choose which ESDS provider he would like to use or even decide
> to run one for themselves.

> I agree and i think this model will evolve and not be built around
> centralized infrastructures anymore. Just like webservices and SOA
> suggests. Buisness level messaging thus will not go away at all and we
> will still send billions of messages around the world every day.

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

> Could you more precisley define what you mean by 'serial-level' data

> Yes i totally agree and thats exactly the point. ESDS provides the
industry /
> individual company defined information about a given object. I may now
> have alraedy enough information in my backend systems for
> the related buisness processes or require more information in such a case
> I call the appropriate service at the originators IS system or any other
> IS system ( and this my not be a webservice nor even on the internet
therefore
> links in the ESDS would ev. have to be modeled in such a way that all
> possible B2B intergation schemas could be described ). At the stage where
> i would have to call a service for more information i am not anymore
> within the scope of ESDS as i lookup the service in the UDDI and make the
call.

> Yes I understand that Discovery Services are build around a pull model,
so I call
> DS to see is there anything about a given object. But thinking about the
starting point
> being RFID and real-time data capture this is in my opinion not enough.
Enterprise
> architecture will more and more move to an Event driven Real-Time
processing environment
> e.g. I would not like to poll an DS with 1000s of Baggage id's once a
second after arrival
> of the plane I don't think the DS providers would like this .... so push
I think
> is important as well. Once again the beauty of ESDS being an internet
standard
> is that suddenly the flexibility for event exchange and the capability of
building fast and
> lightweight event messaging in order to drive real time processes grows
by several orders of
> magnitude and allows to leverage all partners from all industries with
whom we work.

I hope this discussion is helpful.

> Definitley and thank you for your input

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