Paavo,
My comment on the RosettaNet use case addressed the second point you
mentioned. There
are many constraints that two parties in a RosettaNet B2B integration
need to agree upon.
When I made my comment to the use case, I included the "(aside from
implied constraints)",
which is (in the document you attached in the email) in the forth
paragraph. After reading
through the use case again, I get the impression, that the message is
still not clearly stated.
It would be conveyed far better, if - as you suggested - some of the
factors would be documented
more clearly. One way would be, to extend the forth paragraph and
include your additional
elaborations on the set of constraints to make 2 RosettaNet systems
interoperable. It also would
give a reader the confidence, that the problematic regarding implied
business constraints negotiated
between two parties at integration time and not necessary explicitly
reflected is understood.
Thanks,
Peter
Paavo Kotinurmi wrote:
I sent this once on Monday already, but list server did not accept the
message for some reason. So here is the second try:
Hi Peter,
I wrote the RosettaNet part of the document. Regarding your comment in a
email earlier:
On an additional note: in the document assumptions are made around
eBusiness environments, such as RosettaNet. Service brokers in
eBusiness carry many implied constraints, because of the relationship
and expectations of the parties involved. SWS's targeted at
integrating with existing environments need to be able to adhere to
these constraints and would need to capture these accordingly.
So to clarify this, what is exactly what you mean by these implied
constraints?
Is it more like, the assumption that certain trust is in place and both
parties commit to basic RosettaNet definitions that underlie the B2B
integrations.
Or is it more that there are very many things (constraints) that in real
RosettaNet B2B integrations need to be agreed. Now, in order to keep the
document short, there are many not explicitly stated assumptions about the
RosettaNet details. In the case, I just provided one example of mediation
between productIdentifiers used within the messages as an example how SWS
environment can help to mediate between different concepts pointing to a
same resource.
There are very many constraints needed to be agreed and stated to make 2
RosettaNet systems fully interoperable.
- using the PIPs similarly (optional elements, set of allowed values used)
- processes (what triggers processes often very implied, sequence on PIPs
used, exceptional situations)
- Use of same version of RosettaNet Implementation Framework for secure
communication over Internet (retrys, security, non-repudiation document
storage),
So if I need to state in the use case document some of these factors more
clearly, I can say more on those. But now I am not sure what kind of things
I should now elaborate more in the case.
I attached the current version to which I just corrected couple of simple
typos in the RosettaNet part.
Paavo Kotinurmi
DERI Galway, Ireland
tel +353 85 1513589 fax +353 91 495541
Visiting researcher from Helsinki University of Technology, Finland
http://www.soberit.hut.fi/~pkotinur/
--
|
Peter L.
Gratzer
CNS - Technology Office
email:
Peter.Gratzer@Sun.COM
accessline: +1 303.395.3786,
x41188
/ fax: +1 303.272.5011
|
| NOTICE: This email message is
for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is prohibited. If you are not the intended
recipient, please contact the sender by reply email and destroy all
copies of the original message. |
|