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

[Gregor Baues <[e-mail]>]

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