- What is AS4?
- How does the AS4 Profile relate to AS2 RFC?
- Is the AS4 Profile a subset of ebMS 3.0?
- How did AS4 get started?
- What is the purpose and/or benefit of actually making this an OASIS standard?
- Will this be part of the ebXML set of standards and would the profile actually include the ebXML name?
- Which markets would be interested in using this profile?
- What are Drummond Group's plans for Interoperability testing AS4?
"AS4: Secure B2B Document Exchange Using Web Services" is a specification developed by a subcommittee of the OASIS ebXML Messaging Services Technical Committee. The intent and purpose of the formation of the AS4 subcommittee is the development of a Web Services Constrained Profile of the ebMS v3.0 specification, referred to in this FAQ as the "AS4 Profile." This profile provides guidance for a standardized methodology for the secure and document-agnostic exchange of B2B payloads using Web services.
AS4 is for the secure and payload-agnostic exchange of B2B documents using Web services. The intent is to map the AS2-like functional requirements onto the WS-* stack using ebMS 3.0 as a leverage point. AS4 constrains the ebMS v3.0 specification (and the underlying WS-I profiles and WS-* stack) for messaging packaging, transport, security, exchange patterns, and non-repudiation. AS4 is a Web services based protocol that brings simplicity to organizations that are heavily invested in Web services. It provides B2B vendors an on-ramp to Web services based B2B solutions that have otherwise resisted.
AS2 (Applicability Statement 2) is the RFC specification by which AS2 software vendor applications communicate EDI or other business-to-business data (such as XML) over the Internet using HTTP, a standard used by the World Wide Web. The AS2 standard continues to be one of the most widely adopted messaging standards in the world.
The technical committee which drafted the initial AS4 Profile utilized the lessons learned from AS2. However, that is the only relation between AS4 and AS2. It is not the plan that AS4 products takes the place of AS2 products. AS4 offers organizations that are already invested, or want to invest in web services, a web services based protocol with the simplicity and lessons learned from AS2.
AS4 has been developed in the open standard arena of OASIS to make that subset publicly available and publicly maintained. The extensible nature of Web services via the WS-* stacks gives great freedom in expanding and adding features in the future by composing other WS-* specifications. That can be done by either evolving the Profile over time, or by deferring to a full implementation of the ebMS v3 specification.
AS4 has the AS2 functional requirements, plus more functionality because it is a subset of the ebMS v3 specification. In looking over the landscape of using Web services for B2B messaging, it did not seem like there was anything as simple and elegant as what AS2 affords for that domain space. Whatever was out there was either very complicated, document/WSDL-centric, or just underspecified.
In 2007, DGI invited a large group of B2B software vendors to come together for a series of technical discussions to explore what Web services B2B might look like. Those series of technical discussions produced a high level list of business functionality. We made some general broad brush consensus on some Web services functionality around packaging, security, non-repudiation, error handling, etc.
In reviewing these requirements after consensus, the interested parties realized that there was ample common ground with the AS2 functional requirements. And, soon after, it was noticed that there was some common ground with the ebMS v3 specification development that was ongoing. Eventually, agreement was reached that the best plan was to profile the ebMS v3 specification as an "entry-level on-ramp" to Web services B2B, similar to ebMS3.
Because of the competition between various WS standards and groups, the group decided against competing with the ebMS v3 effort. Instead, they decided to join forces in an effort to help drive Web services adoption in the B2B arenas. Obviously, the fractured nature of Web services bodies and the general lack of interoperability are obstacles to Web services adoption. It was felt that this was a necessary approach to drive adoption. The ideas of our software vendor technical group and the ebMS v3 TC are congruent and both parties felt it is more conducive to work together.
Instead of the subset of ebMS v3 that would be certified based on a document, like a DGI Test Plan for instance, the subset would be officially defined as an OASIS profile. The ebXML Messaging Services TC has embraced this and an official sub-committee of that TC with the express purpose of producing the AS4 Profile has been created. By aligning ourselves as an ebMS v3 profile, it clarifies a number of opportunities.
- The Profile jump starts ebMS v3 implementations by constraining and paring down the options for vendors to implement, as well as provides some specific guidance for using Web services as a secure, document-agnostic B2B messaging platform.
- The Profile provides the ebXML Messaging Services TC at OASIS a tangible Profile to work on expanding ebMS v3 functionality in the areas of compression, very large message support, etc.
- The Profile provides the marketplace an entry-level on-ramp to begin leveraging their internal SOA platforms for external B2B messaging while taking on some of the more complicated aspects of Web services.
- At this point, there are no real ebMS v3 implementations, but, in time, DGI will expand its certification program to include not just this Profile, but full ebMS v3 implementations as they become commercially deployed.
- By having the subset of ebMS v3 officially profiled, it makes the whole approach to Web services B2B more open.
Will this be part of the ebXML set of standards and would the profile actually include the ebXML name?
Named "AS4," the profile was published at OASIS as part of the ebXML standards.
AS4 adopters include markets interested in leveraging SOA infrastructures for doing B2B messaging. While some traditional AS2 markets might consider using Web services as well as AS2, the goal for AS4 is for organizations and industries that want to use SOA architectures for B2B messaging. There has been interest in healthcare, electronics, retail, and, of course, the automotive group, which already has a history with ebMS. Software vendors and end-user markets have shown interest as well.
Typically, Drummond Group interoperability tests involve testing products that are already developed and/or in production. AS4, however, is fairly new and the majority of AS4 participants will be in initial development of their products. Drummond Group has learned from experience that identifying interoperability issues after the products have been developed can be time-consuming. In software development best practices, using the iterative approach has proven to be a more preferable methodology for developing quality products.
A NEW APPROACH FOR TESTING:
For AS4, DGI offers an iterative approach to interoperability testing, allowing participants to test and identify issues early in development, as opposed to the end. It synchronizes with the iterative approach to software development. When software coding milestones are achieved, testing is performed with all adopters. This allows interoperability issues to be discovered and resolved early on in the development process and provides feedback to the AS4 specification.
- Start testing earlier in the development cycle as opposed to AFTER the product is complete.
- Software will be tested in PHASES as the code is being developed to build consensus and interoperability during the code development.
- Testing may be done by the Developers or QA staff.
- Each PHASE will last several weeks and focus on a specific part of the AS4 profile shortening the Interoperability certification event.
- This iterative approach to interoperability testing and product and profile development will provide immediate feedback to the profile authors and developers.
- Many open standards require several implementations before the specification is approved and published.
- Drummond Certified Interoperable Product are released concurrent with the AS4 specification approvals reducing the product-to-market interval.