VL: Äebxml-msg-commentÅ Proposal of some changes to ebXML MS 3.0

Title: Viesti

Hello

 

Yes, 
this is one way and I know that adding extra headers of the ebXML MS 2.0 
spec in the envelope, it is fully possible to identify multiple hops. But I want 
a standardized, simple solution and many providers for the users.  The 
reason for route information is the need to be sure, that the acknowledge 
travels back on the same way.

 

You 
can naturally use information, which is not shown on the header to accomplish 
various things, but to my mind it is against the reason of using a 
header.

 

Another example is added. 

 

Matti

 

 

 

-----Alkuperäinen viesti-----
Lähettäjä: Ronald van Kuijk 
[mailto:] 
Lähetetty: 4. elokuuta 2004 
18:53
Vastaanottaja: 'Vasara Matti'
Aihe: RE: 
Äebxml-msg-commentÅ Proposal of some changes to ebXML MS 
3.0

Hi,

 

I've 
looked at your example and we do (in a demo system) exactely what you want with 
the current ebXML MS 2.0 specs. The initial 'hop' is only not in the 
envelope, but (dynamically) hard coded in the client. The thing is that the 
system where the client delivers the message does not have to be the same as the 
value in the to element of the envelope.

 

Ronald

 

-----Oorspronkelijk 
bericht-----
Van: Vasara Matti 
[mailto:]
Verzonden: woensdag 4 augustus 2004 
11:08
Aan: 
''
Onderwerp: 
[ebxml-msg-comment] Proposal of some changes to ebXML MS 
3.0

  
Hello 

  
There has been in my enviroment three faults on 
  ebXML MS2.0. On the other hand it too complicated, too much not needed but 
  required elements, and on the other hand the routing information, when using 
  multihop is missing and there are some doupts on security, when only mime is 
  binding two parts together.

  
The accusation of too complicated can be handled 
  easily, put dummy data on elements, which you don't need, but it is an 
  obstacle of the use. In rather stable environment, where nothing happens 
  spontanously, the specification has many elements not needed.

  
In the published specification of ebXML MS 3.0 I 
  have not seen anything concrete for the routing information. 

  
In the electricity industry in Finland ftp-protocol 
  on private WANs with hubs is used. The hubs work together, so that we have an 
  IP network between all about 100 users. In the similar manner the Finnish 
  banks have made a service, where you can send invoices via banks from seller 
  to buyer. The banks care for security and transfers between banks. All Finnish 
  companies have secured connections to the their banks, when 100% of payments 
  between companies are made electronically.

  
Even with Web Services the use of hubs for 
  outsourcing and security seems to be a valued solution. The hub can naturally 
  be inside of your own company e.g. for encryption purposes.

  
In the attached schemes you can see the element 
  route for the routing information, both to and from are not needed any more. 
  The whole route element is not needed, if there is a direct connection between 
  sender and receiver.

  
Other proposal is putting the payload element 
  directly inside of SOAP body using the XOP WD specification of W3C. It means 
  that in SOAP body there is an binary base 64 element for payload. In the most 
  cases compression is needed, but compressed document can be transformed with 
  mime to base64. 

  
For short payloads there is the option of not using 
  mime transformation, but for simplicity reason it may go out later. These 
  specifications are now under consideration in the ETSO WG EDI. No decision of 
  the use has  been made.

  
<<eheaderv03.xsd>> 
  <<eheaderv03.xml>> 
  <<soap12envelopev.xsd>> <<xlink_1999.xsd>> 

  
Matti Vasara 

  
Phone:+358 30 395 4253 
Fax:    +358 30 395 5201 
email:  
http://www.fingrid.com 

eheaderv031.xml