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

[Vasara Matti <Matti.Vasara@fingrid.fi>]

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:rvkuijk@abz.nl]
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:Matti.Vasara@fingrid.fi]
Verzonden: woensdag 4 augustus 2004 11:08
Aan: 'ebxml-msg-comment@lists.oasis-open.org'
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: matti.vasara@fingrid.fi
http://www.fingrid.com

eheaderv031.xml