Not all ebXML implementations are using all of those capabilities. Some are using just the messaging layer and leaving everything else to text. Some of the big ebXML implementations decided to use the registry first, which puts a transaction-friendly interface over a database so that the XML messages coming out of their can essentially do business with the database and log and put queries against the database that is easier to rig together than with custom programming. Different implementations are starting, using different pieces. Everyday commercial users are experimenting with and adopting these methods. The auto industry is way out in front because they've got a huge supply chain with so much to hit, so much rationalization that needs to be done, they're a perfect case for needing the cost savings that go with making this stuff automated. They're choosing to do this stuff with
FEEDBACK: What are your enterprise's plans for ebXML?
Send your feedback to the SearchWebServices.com news team.
Our experts have intentionally designed it so that it's not. We think it's not. Think about what's happening in the back 40 of a company making this decision. They've got a transport mechanism -- what used to be called a VAN or a channel -- where they send it to an FTP site and then the correspondent picks it up. They've got some methods about sending some stuff back and forth. There's some human intervention loop where a human being look and check what came and in and send acknowledgments in some automated or manual way. They've got the documents themselves that get mapped into a database and doing whatever they can to automate triggers to respond or react. That's EDI.
If you want to use ebXML methods you can start with the transport layer and start sending things of the Internet instead. You can also add metadata to the messages so that people are able to more robustly and in an automated fashion, handle questions of receipt confirmation and duplication for example. You can start to send more complex messages of a kind that EDI would not have supported and start associating these messages into logical chains and start responding to them in a way that would allow a more intelligent, automated workflow system to operate without human intervention. You can use more robust content. You are now sending things where the message body content can be in XML and you can use some of the methodologies that are out there where your content is more robust and full of meaningful metadata so that the purchase order can walk itself to the dock, so to speak, without a human having to be involved. Is ebXML the natural alternative for EDI? And if so, why?
EDI as a method is not software specific. It is essentially the substitution, one-for-one, of electronic messages for paper business documents. In almost all EDI methods, you will see that one-for-one correspondence. EbXML was designed to allow people who are in that early adopter field to move over to a modern XML-based upwardly compatible methodology without have to completely redo their business processes. If you want to do X12 or edifat or Rosetta tips or OAGI bods over the ebXML transmit and choreography layers, you can do that and still use the same old documents.
It isn't attempting to replace that stuff, but it does allow you to replace whatever layer you choose. It is intentionally decoupled and modular. It is explicitly designed to create that migration path, but EDI never realized its promise. It wasn't such a compelling value proposition that all the business that could go electronic did. It didn't. So you have to deliver something more than EDI in order to attract large, robust, pervasive networks of people to make business this way.
There are some aspects of ebXML which are designed to allow those people who never came into EDI to play and use it to achieve their goal as well. It's a fair statement, but it would not be fair to say that EDI is dead, or that they're in competition with each other. They're successive, evolutionary steps that are intended to be backwardly compatible.
So is the timing finally right for ebXML?[ISO] means we can allow a broader range of possible implementers to look at this specification and do something with it where they previously could not with only the OASIS stamp on it.
I can tell you exactly why you didn't see hundreds of spontaneous implementations of ebXML in May 2001 when we left Vienna and had the first series published. You didn't see them because the people who were using it weren't wired up enough with their plans, business processes and understanding of what tools would be available to do anything like that using ebXML or anything else. The driving business requirements that create a business marketplace for things like ebXML are only now coming to a head. I think if anything had been issued three or four years ago, we'd still be waiting until the last six months or so to see a big uptick.
It's transmitting virally. You think about the original expectations of ebXML which was to make these things available freely, easily and in a modular manner and is agnostic as to method and software vendor, viral transmission is exactly how it should occur. It's very gratifying. OASIS as a not-for-profit consortium, we don't do vaporware. OASIS would love to get excited about things, but unlike some commercial developments, we don't have the reason or the authority to go out and talk about how great something is until it actually ships. Now that ebXML has earned ISO approval, have you readjusted your expectations or goals for ebXML adoption? How does this readjust the landscape?
There's a lot more people who have not heard of any of the standards bodies [like OASIS] who do electronic commerce work who know who ISO is. When they hear ISO thinks [ebXML] is safe, and they've begin taking positions in this area for the first time, that's going to make them feel like it's a reliable, safe appropriate technology. We'll see more people who would have been hesitant making that commitment, look for that outside assurance. Something else you have to factor into this, that despite all the excited partisans, electronic commerce is very young. Now that ebXML has earned ISO approval, have you readjusted your expectations or goals for ebXML adoption? How does this readjust the landscape?
The development and further approval of these specifications is an ongoing effort. There are quite a number of implementations out there and as feedback comes back from these parties that are implementing specs and they have suggestions for it, we'll continue development as long as it makes sense. We'll continue to submit further versions of this spec to ISO for their approval. This ISO approval is not the end of the road. Now that ebXML has earned ISO approval, have you readjusted your expectations or goals for ebXML adoption? How does this readjust the landscape?
EbXML has the lifespan and adoption curve of open standards and open source work. It is not an open source work, but it has that same character of being thrown out without strings so that anyone can experiment. They like to tell us sometimes, but for every adoption and experiment we find out about, there tend to be two or three we don't find out about. There is a long stealth growth phase. All of a sudden, people start popping out of the woodwork and we hear about 'so-and-so government' has decided to adopt it for all of their transactions. It just blind-sides us. Our expectation has always been that it would be a long, slow experimental path of development leading then to critical mass. Everything we're seeing now suggests that critical mass has aggregated pretty rapidly in the last year. Is it a time-consuming or complicated process to gain ISO approval?
ISO's process is composed of national delegations, so in order to get something passed you have to take the work, float it for comment and eventually a vote. It goes to all of the national delegations that care to vote in that area. Each of those have a process; some have technical advisory groups or mail lists. The vote comes back and you get whatever comments you get and it requires a certain degree of agreement to pass. There is some process, and you can get some questions and comments back. Luckily in this case, practically all of the people who voted thought it was a great idea and were willing to approve as it was. This was partly because our submission package told them that we had been through a two-to-three-year process already. If this had been a draft, I suspect some parts of ISO would want to go back and go over it slowly. EbXML was an 18-month project with 1.0 and other versions and they were relying on the adequacy of that pre-existing and public process.
Companies that are in the field that work in this business regularly and know their way around and participate, they've heard of us and some of the people involved and that would be enough for them. But the end users would prefer to have worry about standards only occasionally. They just make a decision to commit and use them and move on with their lives. It's very much like knowing that Underwriters Laboratory has a seal and that means you probably won't get shocked by handling an electrical cord on a home appliance. Outside of our area, which is e-business, there are a lot of people who don't know what e-business is, but do know who ISO is. Is it a time-consuming or complicated process to gain ISO approval?
Not too bad. We had to work within their process. The people at ISO were very supportive of the work we've done and were happy to have us submit these specifications to them and champion them through their process. @1886 Could you provide some perspective on how important it is to earn ISO approval for ebXML?
We submitted those four OASIS standards to ISO for their approval so that we could get this sanction from the international organization in order to promote the adoption of ebXML. International approval of the specification allows various organizations within countries to adopt the specification where they would otherwise not be allowed to. For example, in some countries a government agency can only adopt a specification that has international sanction or approval. By having the ISO stamp on the specification, that means we can allow a broader range of possible implementers to look at this specification and do something with it where they previously could not with only the OASIS stamp on it.