Students

Smooth integration of web services depends on common vocabulary — part three

Many IT professionals, called upon to specialize in the integration of Web services, have morphed into "service choreographers." In working to employ service-oriented architecture (SOA), they are developing "ecosystem" awareness, an understanding of IT services interrelationships. In this third part of a series on the new IT paradigm, W. P. Carey Professor Michael Goul explains that the key to easily employing SOA may well start with ontology, or "a common vocabulary that allows multiple stakeholders to communicate and interact." Goul is a member of a team of researchers in an ontology development project aimed at creating just such a common vocabulary for IT services. Once complete, it could dramatically simplify how companies share capabilities and interact in service-oriented IT infrastructures.

2006-02-15

In the world of IT infrastructure, a services revolution is under way. Software isn't just something you buy in a box. Instead, IT professionals seek and use services that companies can access online and use as needed in bigger applications. For example, Web sites such as Travelocity are "mash-ups" of services and content from many providers. Hotels, car-rental firms, airlines and credit-card processing companies all amalgamate their virtual services within the site so that customers can see their available options and book them online. Called service-oriented architecture or SOA, this new approach to applications development calls for an "ecosystem" awareness, or way of thinking. That is, IT ecosystems are similar to biological ecosystems. A change in one subsystem can have major implications for others. What's more, understanding those interrelationships is critical. Whether a company wants to purchase a single "best of breed" service or a slew of them, effective integration of services represents a new IT-management challenge. But, what if you could rapidly incorporate a composition of services into your IT infrastructure to do business the way you want without having to change processes or hardware? What if you could swap several services in and out of your applications as business needs change and the services market evolves? What does all of this mean to the IT professionals, many of whom are now being referred to as "service choreographers?" For service choreographers, the key to easily employing SOA may well start with ontology, or "a common vocabulary that allows multiple stakeholders to communicate and interact," says Michael Goul, professor of information systems at the W. P. Carey School of Business. Goul is a member of a team of researchers in an ontology development project aimed at creating just such a common vocabulary for IT services. Once complete, it could dramatically simplify how companies share capabilities and interact in service-oriented IT infrastructures. Blueprint for a new IT paradigm Because SOA pulls services from multiple sources — and perhaps even multiple companies — it is by nature a collaborative process. And, where you have collaboration, you also must have communication. "In a computing sense, ontology stores documents or some computer artifact in a way that's retrievable and usable by all stakeholders," Goul says. As an existing example, Goul points out that there is an ontology implicit in the coding used by insurance companies and medical-care providers. "Doctors and insurance companies figured out a set of diagnostic codes and procedure codes so that when they communicate what was done in the doctor's office, everyone is talking about the same thing," Goul says. Like any ontology, medical coding allows users to view the information from their differing perspectives. That is, an insurer may look at a code and recognize it as a procedure reimbursed at only an 80-percent level. The physician might look at the same code and know that another type of test should be the next procedure performed. Different users also can have different applications tap into the ontology. In the medical-coding ontology example, the insurer might apply an artificial intelligence mechanism to catch fraud perpetrators who file multiple claims through multiple doctors within a short time frame, Goul says. Meanwhile, medical experts might mine the ontology to look for patterns in the spread of infectious diseases. That may make an ontology sound a little like a database, but it's not. It is a much more flexible and robust storage system. Doing databases one better "A database is a very structured way to organize data," Goul says. "It has a lot of constraints and limits on how you classify things." An ontology, on the other hand, can sort bits of more unstructured data into common categories. W. P. Carey information systems Professor Haluk Demirkan, another of the SOA researchers, explains one implication of an ontology's unstructured approach: "In a database, if I know someone's Social Security number, I can find that person's address and phone number. In an ontology, I can find structured data like that, but I also can look at different topics, like where that person was born." An ontology also puts information into "machine-readable vocabulary," notes an ontology FAQ produced by IBM. "While most queries in databases retrieve the same data as stored previously, queries against ontologies infer or reason about the asserted facts and retrieve new facts implied by the known facts," the FAQ explains. Put another way, ontologies have the ability to retrieve and interpret historical information. "The richness of an ontology comes up after you have some sort of historical information," Demirkan says. "You use that information to make new decisions." Complexity, history, inference and flexibility combine to make ontology a potential powerhouse in service-oriented architecture. "What we want to do is create an ontology of services" that includes the way services were previously choreographed and executed in hardware "so that there are patterns to follow to support a business process," Goul says. Goul explains that the ontology envisioned by his team serves as a "services ecosystem in the sense that service interrelationships can be managed, their historical choreographies can be reused, and their execution on an evolving, virtualized hardware platform can be managed." Demirkan adds that the ontology operates similarly to a library index. It doesn't contain the corporate knowledge, but it tells you where to find what you need, he says. Music to a software choreographer's ears Considering the complexity of what Goul and Demirkan's ontology model could store, the two researchers knew they had to break up IT services into even smaller units. To do so, they borrowed concepts you'd be more likely to find in a school of performing arts than business. Specifically, Goul and Demirkan use the term "choreography" to represent the composition of specific IT services to deliver a business service. When the business service is performed and executed, that's what Goul and Demirkan call an "orchestration of the choreography." Demirkan drives these concepts home with the example of a pizza parlor. Suppose the restaurant owner has two ways to make one pizza. Method A uses one person, who takes the order, tosses the dough, covers it with toppings, bakes the pizza, boxes it up and delivers it to the customer. Pizza making method B calls for two people — one to take the order, toss the dough, handle the toppings and bake the pizza, the other to get the box ready and make the delivery to the customer. Demirkan explains: "The service is the making of the pizza, the choreographies are the two different ways of making the pizza, and the orchestration is actually doing the job — making the pizza, including baking it in the oven," which Demirkan likens to a restaurant's version of hardware. "Our intent with the ontology is to capture the heart of what needs to be in an organization's IT infrastructure ecosystem so that multiple stakeholders can find and do what they need to do to coordinate rapid change in all of the traditional infrastructure layers," Goul notes. "We also see the need for collaborating organizations to share services that can serve to make their alliances more effective -- in essence, integrating multiple organizations' independent services ecosystems into a broader, virtual ecosystem." Goul and Demirkan extend the pizza parlor analogy further: "What if we hire more pizza makers, some don't show up for work, one of the ovens doesn't fire up, etc.?  What if we outsource delivery to a taxi cab company? How about taking all delivery orders through a dedicated call center? What if we find a better way to put sauce and cheese on the pizza?" they ask. "Our pizza parlor needs to be ready and able to rapidly accommodate such change, and it needs to be capable of collaborating with services provided by an evolving value chain of partners." Ontology at your service "What you are really creating with services ecosystems are focused value chains that can quickly put together common processes, common semantics, common agreements ... how things should be done," says Vasco Drecun, research director for Collaborative Product Development Associates, a Connecticut-based consultancy involved with process modeling for collaboration in manufacturing. Drecun has been working with researchers at Santa Clara, California-based Intel on architectural models to support service-oriented design, and he's been a contributor to the ASU ontology project, which he says "supports SOA by helping define and represent interaction between services that need to take place in a collaborative context so that participants can accomplish their objectives." In a project involving many companies, Drecun sees the ASU ontology as facilitating rapid product development and deployment. "Each company would represent itself with a set of capabilities, a set of services and resources it can provide to the ecosystem," he explains, adding that each would be fully exposed to the process while a project was underway. "They'll get all the information they need as they need it." Along with information, service choreographers assigned to a service-oriented project will be working with virtual resources. "The virtual-resource environment is a virtual-computing environment. It's where you don't know what computer you're going to execute your process on, you just make the request," says George Brown, an IT researcher at Intel, who is also part of the ontology project team. He points out that any automated business process has resource requirements, which translates into the computing time and power required to complete the task at hand. The ontology project is a "key step in mapping the resources requirements to the virtual resources" that are available to manage them, he adds. According to Brown, Goul and Demirkan "are extending their work to include some logic to make decisions or choices about the best way to execute services." In other words, when a choreographer makes a request for a service, the system helps pick the best one. Where does this leave software developers? Well, they're not just writing code any more, Drecun maintains. Instead, they need to learn how to describe business processes so that they can generate instructions to execute a process on the virtual machine of the SOA, he says. Drecun adds that this change in software development is not as futuristic as it sounds. "Every bit of this concept is already in existence somewhere," he says. "We're just putting it all together."

KnowIT