Scott Bushey

Subscribe to Scott Bushey: eMailAlertsEmail Alerts
Get Scott Bushey: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Java EE Journal

J2EE Journal: Article

Building Your First Trading Partner Community

A competitive edge down the road

Web services seem like a great way to tackle the challenge of trading partner integration. In theory, participants can continue to use the enterprise applications they prefer, and expose them to their partners' systems.

However, as of late spring, Web services were most prevalent among services companies and least common among retailers. The reality is that few companies have experience with integration across organizations. The default seems to be that the largest participant or customer determines the process, but rarely is thought given to the actual process of integrating applications across organizations, how to handle exceptions, or how to resolve differences. Barriers to success may range from a disparity in skill levels, to familiarity with Web services, or maturity of the IT organization.

The difference in adoption rates among services companies and retailers is ironic given that in our experience, a much older technology used by the retail and manufacturing sectors - electronic data interchange (EDI) - offers useful lessons for Web services. What's more, evolving Web services standards such as WS-I Basic Profile specifications can help eliminate haggling over definitions.

The good news is that companies can take a step-by-step approach to using Web services to establish a functional trading partner community now and enhance it later.

Relationship Management
EDI has been used as a means to automate communication among trading partners (see sidebar, "What is EDI?") since the 1960s. Company-specific document definitions quickly proliferated, and any time savings were quickly overtaken by the need to adjust systems to accommodate new, partner-specific document definitions. EDI required staff dedicated to relationship management, and gave rise to the value-added network (VAN) to facilitate issues resolution.

Relationship management is a consideration as well for companies choosing Web services to connect their supply chain. At the outset, trading partners will need to agree on certain rules of engagement to minimize the impact of disparities in experience with Web services, to ensure some degree of standardization to achieve interoperability, and to accommodate participants' choice of technology and platform. These efforts help reduce barriers to entry for future participants, too.

Most trading partners rely on the largest participant to serve as the arbiter - typically a customer requiring supply-chain integration or some other process that connects several vendors. The arbiter effectively becomes the center, or "hub," for trading partner interaction, and the other participants become "spokes."

It's a relationship model that's served well for EDI; Web services offer the advantage of a non-application-specific exchange with tremendous flexibility - and theoretically, fewer demands on staff time to handle technical issues.

There are three primary issues to address at the start of a Web services-enabled trading partner community:

  • Establishing a standards base
  • Lowering barriers to entry for new participants
  • Interoperability
Standards
Agreement on several fundamental aspects of interaction will go a long way toward getting a trading partner community up and running. These elements include what data will be exchanged, the format of that data, the transport mechanism(s) used to communicate it, the relevant interfaces to other participants' systems, and the overall approach to implementation.

Fortunately, the major players in the technology industry have defined the fundamentals of a basic Web service. As members of the Web Services Interoperability Organization (WS-I), companies including Microsoft, Sun, Avanade, and IBM have collaborated on the WS-I Basic Profile 1.0 international specification. Basic Profile 1.0 addresses Web service elements including messaging (using SOAP and XML); service description using Web Services Description Language (WSDL); and service publication and discovery using Universal Description, Discovery, and Integration (UDDI) (see sidebar, "A Word about WSDL").

With a suite of pretested specifications, trading partners can focus on choosing tools and on establishing criteria for minimum conformance. Check whether vertical standards further reduce the need for negotiation in the early stages of trading partner community formation. For example, the mortgage banking industry's Mortgage Industry Standards Maintenance Organization (MISMO) and the insurance industry's Association for Cooperative Operations Research and Development (ACORD) have established business process standards as well as message schema that may be useful to reference.

That said, some "horizontal" business process execution integration specifications under development may introduce complexity and undermine chances for the success of the trading partner community. Basic Profile 1.0's basic Web services-enabled functions can be augmented with specifications for more sophisticated actions later on. Standards to consider after the community is up and running could include advanced security procedures such as encryption, certificate standards, and digital signatures.

Once participants have agreed on standards, it's important to withstand exceptions. The Web services-enabled trading partner community provides a universal foundation for integration. Deviation from core specifications will make it difficult to add new participants later, not to mention threaten the chances of smooth integration among the inaugural partners. It's important not to underestimate the amount of effort involved in setting these standards, but the investment will pay off in multitudes over time.

What is EDI?
Electronic Data Interchange (EDI) is the computer-to-computer exchange of business data in standard formats. In EDI, information is organized according to a specified format established by the parties exchanging data, allowing a computer transaction that requires no human intervention or re-keying of information. Today, more than 300,000 organizations use the 300+ EDI transaction sets to conduct business.

A Word about WSDL
Setting a standard for Web services description is perhaps the biggest enabler of successful integration. It is crucial for companies to know what interface requirements they must meet in order to integrate with trading partners, and establishing a single interface standard for all "spokes" of the community is much preferable to having multiple interfaces - and the potential for complexity and even failure. It's another reason we recommend clients consider adopting Basic Profile 1.0.

Conformance - Lowering Barriers to Entry
Besides standards for participation, a level playing field is vital to the success of the trading partner community. Standards selection requires complementary skills to implement them. That's why it's extremely important to take stock of trading partners' capabilities and even certain aspects of their infrastructure. Participants may or may not have IT organizations that are well-staffed. Personnel may or may not be well-acquainted with technology and industry standards. And they may or may not have past experience with Web services and related technology.

The "hub" of the community must acknowledge the difference in competencies, and take the lead in establishing the relative skill of each participant. Then the group must factor this assessment into standards selection, technology choices, and timeframe for implementation. In some instances, "hub" companies may provide some form of support to partners with less advanced IT capabilities, supply sample code, or even recommend a complete "black box" solution.

A high-level infrastructure assessment will help determine which Web services characteristics to delay for future implementation. For example, a "hub" may specify digital encryption for every Web service call, but "spokes" may not have the public key infrastructure (PKI) to support that sophisticated function. The community may default to Secure Socket Layer (SSL) as a means for network security to lower the barrier to entry into the community, sacrificing the benefits of PKI in the short term in order to expedite the community's launch.

The format of Web services ultimately must reflect the capabilities of the group, as well. There are two methods for exchanging data: the simpler document-literal approach, and the more complex remote procedure call (RPC) approach. Document-literal exchanges specify the format and content of data (such as a purchase order) and tend to be more message-based. RPC-based Web services invoke action on the data conveyed and tend to be more stateful. Document-literal transactions have a smaller payload and are easier to implement.

Of course, the vision for Web services is a multiplatform trading partner community - one where participants may elect the development environment they prefer, whether Python, J2EE, or Microsoft .NET, on the platform of their choice such as Linux or Microsoft Windows Server 2003. Nevertheless, until the Web services experience is universal, the multiplatform environment can be the most challenging. Taking inventory of participants' platforms can help the community understand whether there could be additional difficulties. In turn, they might redefine aspects of Web services collaboration so that they can be supported easily by all partners.

Avoiding Interoperability Issues
Once standards are in place and steps have been taken to inventory capabilities and ensure every participant has relatively equal footing, implementation can begin. Frequent communication among "hub" and "spokes," necessary in the early planning stages, is absolutely essential in this phase. The rule of thumb we advise is for companies to talk at least once a week and plan to test frequently all the way through production.

Communication can smooth the way for a fairly uneventful implementation. It also sets a precedent for problem resolution. Programming may begin and code may not work - unfortunately, because it is possible for a partner to hide its lack of capabilities by writing code that looks like Web services via scripting, but that doesn't actually implement them, because there is no logic and no infrastructure in place for SOAP and/or WSDL.

In one unfortunate situation, a client's partner didn't invest in the necessary development environment and tools, and managed to write scripts that fooled the teams until tests drew responses that were erroneous. The client's first response was to examine the code line-by-line to find the error; however, we examined the URLs to which the partner's WSDL files were pointing and discovered that the partner had utilized extensive scripting that did not truly implement Web services.

An agreed-upon inventory of skills, experience, and platforms - as well as regular communication - should uncover the need for assistance and also help teams more quickly determine the source of problems by eliminating certain possibilities. A carrot-and-stick approach may be required, to offer - and take away - additional support for non-conforming partners who need access to other experts in the community.

Several tools for code comparison also help you diagnose certain issues quickly. For example, Mindreef SOAPScope and Microsoft .NET Web Services Studio 2.0 make it possible to compare trading partners' WSDL interface to the agreed-on standard, validate their interfaces against WS-I standards, capture Web services traffic sent during testing, and analyze it to make sure it meets standards and is correctly formatted. Since Web services give participants some flexibility in designing their interfaces to other partners' Web services, this automated comparison saves a good deal of time. Some tools will allow resending of RPC or document-literal messages for quick diagnostic testing without running the application itself.

Another bump in the road to interoperability is access to trading partners' infrastructure. A host of issues can bring work to a halt, from changing firewall settings to setting permissions on servers, to network and machine administration ensuring a stable connection to partners outside the firewall. One aspect of Web services development that's foreign to all organizations is the need to expose development - as well as production - to the outside world. The challenge of consistent Web services management within a trading partner community shouldn't be overlooked.

As implementation advances, it's important to keep track of each participant's progress as well. One trading partner might have migrated its work to its test bed, while another remains in development, and a third has moved on to its quality assurance environment. Participants in the Web services-enabled trading partner community must keep track of where each one is in its work, even using a manual mechanism to do so.

Finally, it's important to build into Web services some mechanism for error tracking among organizations. This may be as simple as an asynchronous error notification that annotates events with a tracking number, so that companies can reference both instance number and time of event. Referring to the time of event alone has limited value, in cases where the error results in some action not taking place - such as a rejected purchase order or invoice.

Moving Forward
As participants' expertise grows, no doubt the trading partner community will choose to enhance aspects of its Web services once up and running. In our experience, security usually is the first subject of augmentation, whether through the addition of encryption or digital signing. Next in line is the exposure of more internal business applications in order to expand the trading partner community or add more business processes. Other architectural services may be introduced for reliable messaging, routing, and management as well.

Proactive support is essential in the post-implementation phase of the trading partner community. When Web services operate around the clock, year-round, identifying a problem or error as soon as possible will help a trading partner address an issue before it ripples throughout the supply chain. Mechanisms to trigger proactive support range from human intervention - such as periodic review of event logs - to automated tools, to application-initiated notification via e-mail.

Although retailers may lag other industries in Web services adoption, next-generation Web services tools are getting easier to use, and have richer features. Ease and cost-effectiveness will tip the scales in favor of Web services and away from EDI and value-added networks, and gaining experience now with Web services integration will serve retailers looking for a competitive advantage very well.

Reference

  • Forrester Research, "Who Has How Many Web Services," May 10, 2004.
  • More Stories By Tyson Hartman

    Tyson Hartman, Avanade Fellow
    As an Avanade Fellow, Tyson is responsible for working with the senior
    technology team to define the vision and road map of Avanade's solution
    development practices. With focused experience in building e-Business,
    Enterprise Application Integration (EAI), and Business-to-Business solutions
    for large enterprises, Tyson is a skilled architect and thought leader. As
    a specialist in integration and high volume transactional Websites, Tyson
    has a deep background in deploying complex solutions and is a frequent
    contributor to business development and technology marketing efforts on a
    global basis.
    He is also one of Avanade's senior-most technologists responsible for guiding Avanade's .NET vision and go-to-market solutions.

    Prior to joining Avanade, Tyson spent eight years at Accenture where he led
    multiple e-Commerce system implementations, from design, development, and
    testing through production. He holds a bachelor's degree in Computer
    Science and Computer Engineering from the University of Southern California.

    More Stories By Scott Bushey

    J. Scott Bushey is a consultant with Avanade, Inc., a technology integrator for Microsoft solutions in the enterprise. Bushey is an Avanade Principal Solutions Developer, and is responsible for architecting and developing .NET solutions, focusing on Web services.

    Comments (0)

    Share your thoughts on this story.

    Add your comment
    You must be signed in to add a comment. Sign-in | Register

    In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.