OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Proposal of some changes to ebXML MS 3.0

Title: Proposal of some changes to ebXML MS 3.0


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





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]