RE: ebXML TP&R Overview & Requirements Doc diagrams

[David Burdett <david.burdett@commerceone.com>]

Dick

See comments below marked with ## ...

In reading your points (and writing my response) I think that we would all
benefit from a bit more clarity in what a repository management system needs
to do. Perhaps we should involve the Repository group to find out ;-).
Without a clearer requirement we could end up going round in circles.

I also think that this is a good topic for the call on Wednesday.

David

-----Original Message-----
From: Dick Brooks [mailto:dick@8760.com]
Sent: Monday, February 21, 2000 2:38 PM
To: Rik Drummond; David Burdett
Cc: ebXML Transport (E-mail); Nikola Stojanovic
Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams


Rik,

There are some good reasons why one may want to have the repository access
contained within the Messaging Services component,
for example:

	- The Messaging Services component will likely have an interface
with the
repository (for DTD's, trading partner
        data, etc.). Why not re-use this code and manage the processing in
one place.
## For messaging I think access to DTDs (or Schemas) is a myth. Messaging
should only need to access a small number of DTDs (for Message Headers,
Message Routing Information, etc). Dynamic access to DTDs won't be required
as there will be a lot of processing that will be highly dependent on the
semantics of the data in the message header etc. The only way you can handle
these semantics in my view is by writing application logic that understands
what's in the data. This means that you really need to "compile in" the
semantics of the DTDs. This is BTW quite different from schemas that define
Business documents where there may be many definitions of similar documents.

On the other hand trading partner data that is held in a Messaging Policy
Repository as illustrated in recent diagrams, will need to be accessed
frequently both remotely and locally.

Now the local Messsaging Policy Repository is likely to be a database that
is mapped to the logical (i.e. entity-relationship) model of the data we
will need to produce. However changes in this data will need to be
transmitted to other partners that need to know it using documents as part
of a document choreogrphy that is designed for the purpose.

Although re-use of code is possible, I actually think that providing
different (better?) functionality in this area is how vendors of one
messaging system will differentiate themselves from their competitors. ##

	- As repositories evolve there will likely be differences in
version/capability across implementations. It would be
	  easier to manage these differences if the code is in one place as
opposed
to several backend systems running
	  on various platforms.
##The main benefit in having the code in one place is so that changes to the
system (either code or data) don't need to be replicated. This implies that
the data will be in one place (am I right Dick?). In practice I don't think
that the data can realistically be kept in one place as it won't scale.

Again, as long as we have a defined doument choreography for how to interact
with the various repositories, then it should be OK for anyone to write the
code that accesses it.##

	- The repository location, I assume, will be dependant on the
trading
partner involved in any transaction exchange.
##Each trading partner (party?) will have their own policies on how they
conduct business that they will need to share or negotiate with their other
partners. But I don't see this being done for every transaction. Instead
they are much more likely to be cached locally.##
	  If this is true then the backend system will need to interface
with the
Message Service to get access to the trading partner information.
##Only at set up time ... not for every transaction.##

	- The Message Server can provide some economies of scale, for
example,
caching services for frequently accessed sites.
##Do you mean caching services or caching policies.##

	- Eliminate redundancy/code management that exists when there are
multiple
implementations of the repository interface.

These are just a few advantages of having a centralized repository interface
through the Messaging Service.
## I agree with a centralized repository interface it's just that I think it
should be layered on top of the Messaging Service rather than be part of
it.##

##Dick. We need to talk about this - perhaps we can on the conference call
on Wednesday since I'm not sure I've fully understood the point you're
trying to make.#


Dick


-----Original Message-----
From: Rik Drummond [mailto:drummond@onramp.net]
Sent: Monday, February 21, 2000 3:07 PM
To: David Burdett; Dick Brooks (E)
Cc: ebXML Transport (E-mail); Nikola Stojanovic
Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams


If we follow david's logic, our service could connect and be used easily by
other repositories that don't follow the details of the one ebxml is putting
in place. so i agree with david's take on this.... best regards, rik

-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of David
Burdett
Sent: Monday, February 21, 2000 1:19 AM
To: Dick Brooks (E)
Cc: ebXML Transport (E-mail); Nikola Stojanovic
Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams


Dick

You say ...

>>>it appears that access to the repository is not part of the service
interface of the messaging system ... as I recall, it was decided that the
messaging service interface would provide a "service" for accessing the
repository (read & update)<<<

In a senses I think we are both right. My view is that:
1. We need a basic "Messaging Sservice" that can reliably exchange messages
over the net between any two parties that is completely independent of the
content or the payload of the message
2. We define a "Repository Management Service" that can be used to
read/update a repository that we identified.

The Repository Management Service would:
1. Have a Service Interface so that the content of the data in a repository
held locally could be maintained, and
2. Use the Service Interface of the Messaging Service to access the content
of repositories held remotely.

The attached diagram provides (I think) are more accurate representation
than my original one.

The rationale is that the Repository Management Service is really nothing
more than a distributed system that reads or updates data on local or remote
repositories that has a Service Interface to manage/access the repository
content.

I think that this type of "layering" is important as I think that eventually
we will want to describe a number of other Service Interfaces that will use
the basic messaging service interface, for example:
1. A Publish & Subscribe Interface
2. A Large Document Transfer Service (e.g. to transport multi-MB files
reliably by splitting them into several parts).

I'd appreciate your thoughts.

David




-----Original Message-----
From: Dick Brooks (E) [mailto:dick@8760.com]
Sent: Saturday, February 19, 2000 3:20 PM
To: David Burdett; Nikola Stojanovic
Cc: ebXML Transport (E-mail)
Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams


David,

I believe you've captured what people are expecting in terms of a solution
from the ebXML MR&T group. Nicely done.

Only one comment, regarding diagram 5, Repository physical flows of
information, it appears that access to the repository is not part of the
service interface of the messaging system. This is different from what I
recall from our discussions in Orlando. As I recall, it was decided that the
messaging service interface would provide a "service" for accessing the
repository (read & update). This was discussed around the time that John I.
introduced the tpaML spec.

Dick Brooks


-----Original Message-----
From: owner-ebxml-transport@lists.oasis-open.org
[mailto:owner-ebxml-transport@lists.oasis-open.org]On Behalf Of David
Burdett
Sent: Tuesday, February 15, 2000 12:27 AM
To: Nikola Stojanovic
Cc: ebXML Transport (E-mail)
Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams


Nikola

I agree with your comments. I'm copying my reply to the TP&R group since I'd
like the groups comments on the diagrams and attached notes during the
conference call on Wednesday with a view to including them in the
Requirements document.

David

-----Original Message-----
From: Nikola Stojanovic [mailto:nstojano@cjds.com]
Sent: Monday, February 14, 2000 11:54 AM
To: David Burdett
Subject: Re: ebXML TP&R Overview & Requirements Doc diagrams


<snip>
As I understand then:

1) We will use TP&R services only to go remotely (via Internet only?). There
is no need for formal (header, doc, signature,...) XML packing between ebXML
components. Internally Systems talk to each other via specified Service
Interfaces ("Program Language independent ..."). There are some ebXML
threads regarding "Syntax neutral" (some call it syntax-free?) notion of
Interfaces and Components. It would be necessary to decide which syntaxes to
use as examples, because there has to be at least one.

2) Integration System (ebXML Gateway, Service Handler) will be the one which
will handle (route, ...) ebXML Service Processing. It will serve the purpose
of a "Facade controller" for the overall ebXML space. It will also serve the
purpose of "Indirection" in order to avoid "Direct Coupling" of Systems
(Components), which will never talk directly to each other, like: Message
System will go via Integration System to Repository System to get needed
Messaging Policies.

I will need to read your docs again to have a better understanding of all
the entities involved.
Nikola



----- Original Message -----
From: "David Burdett" <david.burdett@commerceone.com>
To: "Nikola Stojanovic" <nstojano@cjds.com>
Sent: Friday, February 11, 2000 9:20 PM
Subject: RE: ebXML TP&R Overview & Requirements Doc diagrams


> Nikola
>
> I've looked at your diagram and think that there is too much information
on
> it for it to easily make it easy to understand. So I've added a few more
> diagrams to explain a number of different aspects.
>
> Tell me what you think.
>
> David
>
>
> -----Original Message-----
> From: Nikola Stojanovic [mailto:nstojano@cjds.com]
> Sent: Friday, February 11, 2000 7:22 AM
> To: David Burdett
> Subject: Fw: ebXML TP&R Overview & Requirements Doc diagrams
>
>
> Hi David.
>
> 1) A few more changes (corrections) from me.
>     Message System now talks to:
>         - Another Message System via Internet (or something else?) in
order
> to reach another Party. I guess we don't need local version of this?
>         - Another Message System via Internet (or something else?) in
order
> to reach Repository Server (Repository).
>         - Repository System locally.
>
> 2) I am of the opinion that sometimes smaller group of people can do more
> then a larger one. In XP (Extreme Programming) they have 2 people (2 pair
of
> eyes, ...) working on a task. I thought if you and me can just discuss
this
> version and then, if we agree on it, give it to a one person from each of
> our groups for comments and then present to whole groups? If not in
> agreement or not working together, I assume you'll pass it to your group
and
> I pass it to my group.
>
> Thanks
> Nikola
>
> ----- Original Message -----
> From: "Nikola Stojanovic" <nstojano@cjds.com>
> To: "David Burdett" <david.burdett@commerceone.com>
> Sent: Thursday, February 10, 2000 2:49 PM
> Subject: Re: ebXML TP&R Overview & Requirements Doc diagrams
>
>
> > Hi David.
> > These are just few of mine initial changes. I have informed our group
> about
> > your meeting and what was discussed.
> >
> > Why changes:
> >
> > Assumption #1: Everything is a Service. Not only business services, but
> > technical (infrastructure) as well. That would imply that Registry and
> > Repository (RR) should comply with this design => you can ask RR if it
can
> > Change a Core Component or just Browse Core Components, ... Even Message
> > Systems comply with this => thus Service Interfaces instead of API.
> Message
> > systems' Services could be "Discovered" as well.
> >
> > Implication #1: Everything talks uniformly via Message Systems. I guess
> > language is XML.
> >
> > Assumption #2: RR could be available both Locally and Remotely (via
> > Internet, ...).
> >
> > Implication #2: Integration System just talks (is a Broker) between
> > Enterprise and ebXML space. It can also talk to other spaces (we can
hope
> > ebXML will be a meta one so it wouldn't need to) if needed.
> >
> > Assumption #3: Policies are Business Rules.
> >
> > Implication #3: Policies are part of Business Rules. As such they could
> also
> > be Local or Distributed.
> >
> > What do you think?
> >
> > Nikola
> >
>
>
>