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

[Gregor Baues <[e-mail]>]

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 <[e-mail]> 
             Harrison                                                   cc 
             <[e-mail]         [e-mail], [e-mail],  
             .ac.uk>                   Ashkan Fadaiefard/Simard            
                                       <[e-mail]>             
                                                                     Objet 
             01/30/2008 04:35          Re: Réf. : Re: [ESDS] Draft Problem 
             PM                        Statement 00                        
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




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.

> 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.

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.

> 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.

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.

> 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

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.

> 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.


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.

> 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.


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.

> 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


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