![Close [x]](http://dw1.s81c.com/i/c.gif){kind=small}
The purpose of this series of articles is to demonstrate the true potential of Web services by creating an e-business dialogue that can be used to conduct real business. This e-business dialogue will be based on a real world business problem and the problem will be addressed by using a proven solution from RosettaNet. In this series, I will show you that the most important aspect of Web services is the e-business dialogue; I will explain what they are and how to construct them for business peers. In this first article in the series, I will cover the following:
- The true potential of Web services
- Understanding how to conduct e-business dialogues
- Advantages of leveraging RosettaNet
- Introduction to RosettaNet
- Translating RosettaNet into Web services
In Parts 2 and 3, I will discuss choreography for Web services and construct a sample end-to-end e-business scenario that demonstrates the benefits of combining RosettaNet and BPEL4WS.
The true potential of Web services
You can rest assured that Web services are not just a vague notion. Web services can solve business problems even today. They offer attractive features like the use of open standards like WSDL and SOAP, and the re-use of existing Web infrastructure including hardware, software, and expertise. The true potential of Web services lies in utilizing them to conduct e-business dialogues between business peers. While application integration and simple Web services serve a purpose, it is the widespread availability of collaborative Web services between business peers and the conducting of the e-business dialogue, that will really make significant positive impact in e-business. It is important to note that with e-business dialogues, Web services are not venturing into un-chartered territory; they benefit from lessons learned from tried and trusted e-business standards like RosettaNet and EDI.
In the simplest sense, Web services allow us to define services with a very accessible and technology neutral public interface. This interface is defined in the XML-based WSDL (Web Services Description Language), and may be accessed (among other options), via the Web infrastructure using XML based SOAP (Simple Object Access Protocol) messages. I will now explain why these simple features are causing so much excitement.
Figure 1: Web services bring profound change
I believe Web services are a revolution in the relationship between business and information technology. This revolution enforces a few points about e-business:
- e-business is less about 'e' (the technology) and more about business.
- The public interface of an e-business puts services first.
- e-business dialogue is technology agnostic.
- Technology should assist e-business, not overpower it.
Web services are poised to bring a significant change in how organizations think about e-business. While some of these changes are subtle, the results promise to be dramatic. The first change Web services bring to e-business is an intense focus on services, which is fitting, as one of the primary reasons an organization exists is to provide services to customers and partners. The second change is better communication and knowledge sharing between the different groups of an organization; Web services help everyone think in terms of "services," a shared concept. This enhanced communication helps in designing robust services and in getting the design right at the concept phase.
The most significant change in e-business caused by Web services is that it makes business dialogue somewhat technology agnostic. With Web services, an organization provides access to its services through a public interface based on open standards and a common language. This separation between the public and private sides of the Web service removes technology concerns like OS, programming language, and platforms from the e-business dialogue, enabling business partners with completely different technology setups to communicate effortlessly with each other. Removing technology hurdles from the dialogue is the first step for conducting e-business dialogues; the next step is to use standardized dialogues, messages, and vocabulary. As I stated earlier, we cannot realize the true potential of Web services unless we use this technology to create e-business dialogues.
Figure 2: The public and private side of Web services
The basis for a successful real-world Web service is the ability for business partners to conduct electronic business dialogues. Since we are talking about e-business, the dialogue is digital, and the software systems at both ends must make sense of the dialogue. A software system can really only "understand" what it has been programmed to understand, and the cost to conduct e-business dialogue can become prohibitively expensive if you have to program several interpretations of dialogues for the same business activity. For example, if you have 22 business partners with whom you buy and sell goods, if each of these partners define a different dialogue for conducting purchase orders, you will have to implement 22 dialogues to do the same thing. This is why standard ways of describing, accessing, and processing business activities and electronic business dialogue becomes crucial.
So, what is an e-business dialogue? An e-business dialogue is the conversation that takes place between the software systems of business partners in order to conduct a business activity. The dialogue can be simple or elaborate based on the business activity that needs to be executed.
Figure 3. The components of an e-business dialogue
In Figure 3, you can see a simple e-business dialogue in which Acme places a purchase order request with JoeLaptops. You can also see the several components that are needed in an e-business dialogue:
- Open and accessible public interfaces
- Partner roles
- Standard messages exchanged in agreed upon choreography
- A standard vocabulary
- An environment of security and trust
For Acme and JoeLaptops to start a business dialogue, both organizations need to have public interfaces that are defined in a standard manner, and accessible via Internet based protocols. The open and accessible interface makes it possible for Acme, which is a Java-based shop, to communicate effortlessly and cheaply with JoeLaptops, which is a mainframe and COBOL-based shop.
To understand roles and choreography, I want you to think of a movie script. Just like a movie script, an e-business dialogue has different roles for the business partners to play. In our example, Acme assumes the role of a buyer and JoeLaptops assumes the role of the seller. Like actors delivering lines from a movie script, the organizations "deliver" messages to each other based on the order specified in the e-business dialogue. In e-business dialogues, this concept of sequence and order is known as choreography or orchestration. In the simplest form, it creates a sequence in which the messages are exchanged. The choreography can also be used to create elaborate dialogues that orchestrate services, partners or other e-business dialogues. I will explain this in further detail in the next article that deals with BPEL4WS.
The important thing to keep in mind is that the business dialogue is being conducted between software systems, and since they are not very good at guessing, nothing can be left ambiguous. The messages that Acme and JoeLaptops exchange have a standard structure and standard vocabulary. This means that the messages must follow a defined schema, and any words used in the message must have the same meaning to both organizations. Standardizing the definition and usage of a word is important and we see this need even in our daily lives, as everyday words may take on different meaning in different professions. For example, when I mentioned a movie script earlier, if I had only used the word 'script' instead, given our technical backgrounds, the word 'script' might have caused confusion about the meaning: Perl script or movie script? For example, while 'mouse' is a small furry animal in a pharmaceutical lab, it is a pointing device in a computer lab. It is important that when a computer lab places a purchase order for a mouse, the seller does not ship a rodent. Luckily for us, there are standard bodies that build dictionaries to standardize definitions of words used in e-business messages.
One of the most important components of a business dialogue is trust and security. When organizations conduct business in the physical realm, they sign contracts to enter legally binding agreements. In e-business, this trust is established by treating each exchanged message as a contract. The messages are stored for an agreed period, and each partner is bound to the 'promise' made in the message. This concept is known as non-repudiation. The partners also identify which employees are authorized to conduct the e-business dialogue, and this authority and identity is verified during the e-business dialogue by inspecting digital certificates and the digital signature on the message. The messages exchanged are tamper-proof so that no third party can change the content and cause harm to either party. The messages are also transported over a secure wire to be snoop-proof so no third party can eaves drop on the sensitive information passing between the business partners.
The theme of my series is that Web services can live up to their true potential, if we use them to conduct e-business dialogues that leverage concepts and components from RosettaNet and are described in BPEL4WS and WSDL. Since BPEL is very capable of describing business processes, why should we bother with RosettaNet at all?
As I stated before, to create a real-world Web service, I need to create the ability to conduct an e-business dialogue. To create a useful e-business dialogue, along with open and accessible public interfaces, I need to use standardized messages, vocabulary and choreography. Essentially, I need to take a standard e-business process and enable it in the Web services environment.
RosettaNet (www.rosettanet.org) is an industry leader for e-business process specifications and therefore a natural choice to choose our "Standard" e-business process for our e-business dialogue.
I believe that we should use RosettaNet-based Web services for the following reasons:
- Easier to calculate ROI
- Benefit from business best practices
- Easier to gain partner acceptance
- Save time and effort in creating business dialogues
However promising and appealing Web services might appear, many organizations are hesitant to commit funds to Web service projects. "Show me the money," that famous line from the movie Jerry McGuire, seems to be on every battle-weary manager's lips. This is a valid demand, and I believe we can provide this proof by building Web services that focus on reducing costs and saving time for existing business problems, rather then focusing on new business models enabled by Web services.
Basing your Web service on RosettaNet specifications allows you to use some of the ROI calculations from RosettaNet. Of course, the true benefits cited by RosettaNet are for the use of standardized e-business processes, but many of the calculations are still relevant. The RosettaNet Web site contains case studies that prove the benefits of implementing business activities as e-business processes. For example, INTEL recently announced that it has used RosettaNet e-business processes to conduct over 10% of its selling and purchasing. That is over $5 billion dollars worth of transactions. The Web service I am constructing in this article is based on RosettaNet PIP3A4, an e-business process that allows partners to place purchase orders.
Benefit from business best practices
RosettaNet creates e-business processes by gathering a group of business subject matter experts that identify industry best practices for a certain business process. RosettaNet then models the best practice real world business processes as an e-business process. The e-business process then undergoes much scrutiny by industry experts before it is released as a specification. Finally, the specification is put into business use and any remaining wrinkles are ironed out. A RosettaNet PIP (an e-business process) contains vast amount of industry knowledge and expertise, including the best way to conduct that particular piece of business. Modeling our Web service on RosettaNet specifications allows us to benefit from this valuable expertise and knowledge.
Easier to gain partner acceptance
An e-business dialogue is really a dialogue between two peers. Unlike the current Web services design, a Web service for conducting e-business dialogues cannot be designed for one partner alone. It needs to be agreed to by both partners. While it is possible for partners to negotiate a brand new business process, it is much easier if they base it on a RosettaNet specification, as these specifications are being used to conduct real business and they are not biased towards either partner.
Save time and effort in creating e-business dialogues
BPEL4WS gives you the tools to create business processes. It is up to you how you design the business processes. We could use BPEL4WS to create brand new business processes, or we could use it to model RosettaNet-based e-business processes. I am a firm believer in not re-inventing the wheel and since a lot of work has been done over the past 25 years in the area of e-business, including major efforts like EDI and RosettaNet, we can benefit from this work and learn to re-use it for our projects. We can drastically cut down on the time, effort, and expertise required to craft common e-business processes by simply taking a RosettaNet e-business process and writing it in BPEL4WS.
In this article, I have discussed the true potential of Web services as a widespread use of low cost e-business dialogues to conduct real business. I explained what e-business dialogues are and how they work, and I explained why basing e-business dialogues in Web services on RosettaNet is a good idea. In the next articles, I will look at creating an extended e-business scenario using the RosettaNet PIP3A4 and BPEL4WS.
- "Web services: An elephant in the dark" by Suhayl Masud offers additional insight on the true value of Web services.
- "Best practices for Web services: Part 1, Back to the basics" (developerWorks, October 2002) by Holt Adams et.al., is an excellent source for applying best practices to constructing Web services.
- "Business Process with BPEL4WS: all columns" (developerWorks, August 2002) by Sanjiva Weerawarana et.al. offers additional insight on writing business processes with BPEL4WS.
- "Asynchronous operations and Web services, Part 1: A primer on asynchronous transactions" (developerWorks, April 2002) by Holt Adams offers useful information on creating asynchronous Web services
- "Asynchronous operations and Web services, Part 2: Programming patterns to build asynchronous Web services" (developerWorks, June 2002) by Holt Adams offers more useful information on creating asynchronous Web services
- The RosettaNet Web site is the ideal place to find out more about the technical and business aspects of e-business dialogues
Suhayl Masud is the president of Different Thinking, a consulting firm that enables organizations to understand and conduct electronic business, by providing training, architecture, and application construction services. Suhayl's experience includes consulting as the lead technical architect for RosettaNet, where he helped define the next generation of e-business process standards. Suhayl would love to hear from you at: SuhaylA@DifferentThinking.com or via the Web site www.DifferentThinking.com
Table of contents
Local resources
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
