In Chapter 3, we describe the Web services phenomenon. The paradigm defined by Web services, in which several Internet services interact together to accomplish a task or process, highlights the need for business registries. Business registries, as we learned in Chapter 2, act as a collection point and a discovery platform. Business registries in the Web services paradigm house Web services and make them available for browsing and searching by other applications or processes. Figure 4.1 depicts the Web services world with business registries at its core.
Understanding business registries in the Web services context involves describing their place in the Web services ecosystem and lifecycle. In this chapter, we discuss these topics in further detail.
A Web services ecosystem is a set of related services. This set, as a whole, provides a set of services in a specific domain. In Chapter 2, we describe the employee portal. A portal Web site is an example of a Web service ecosystem that caters to a specific audience. An employee portal would cater to the needs of a certain set of employees or a medical portal would provide services related to medicine — including services such as medical advice, sale of prescription and nonprescription drugs, and archiving of medical history. But an ecosystem is not merely a collection of services. As the name implies, it is an orderly group. Just like a biological ecosystem, an ecosystem of services can have a hierarchy among its citizens, and it provides a set of rules and regulations that every member must abide by. However, in this case, the hierarchy is not in the sense of food chain or power, but one with the notion of higher- and lower-level services. A hierarchical view of the ecosystem helps in defining service composition — bringing together lower-level services to create higher-level services. In the employee portal ecosystem, for example, the Retirement Plan Financial Institutions, 401(k) services, and others can be thought of as lower-level member services in that ecosystem.
Higher-level services aggregate these lower-level services to create solutions that may be tailored for specific needs. For example, a higher-level service to induct a new employee in the company will make use of the appropriate lower-level services mentioned above and enroll the employee in the 401(k) plan and the stock purchase plan using relevant service interactions. In a similar fashion, a higher-level service can interact with relevant lower-level services to terminate an employee.
The regulatory aspect of the ecosystem is essential for smoother interoperability between the members of the ecosystem. In that respect, an ecosystem can be thought of as having two separate classes of services.
Regulatory class services —. These are services that ensure interoperability among the members of the ecosystem and enforce standards and regulations required for that purpose. Some examples of this are standards-setting services, service-rating services, and monitoring and dispute-settlement services.
Member class services —. These are the services that use the standards and rules set by the regulatory class services to offer a certain service that is within the domain of the ecosystem.
Together, these two layers of services provide a complete ecosystem that can sustain itself and provide useful services to its users. Among these classes, there are several roles that different entities will play to make an ecosystem successful.
The complexity of an ecosystem can vary significantly as can the necessity for various roles. The discussion below provides a general view of an ecosystem and corresponding roles. The exact nature and types of the roles are dependent on a specific ecosystem. Figure 4.1 shows the relationship between various roles in an ecosystem.
This entity is responsible for providing the necessary infrastructure for an ecosystem to function. The host’s role is mainly to facilitate the general functioning of the ecosystem. An example of an ecosystem host would be the New York Stock Exchange (NYSE). It provides the means for the stock traders to buy or sell stocks and to provide data about those transactions, such as bid/ask prices and the Dow Jones Industrial Average (DJIA) — an index expressing the market’s general sentiments about the top 30 companies listed at NYSE. The host also has policies for granting or revoking membership to interested parties. The NYSE, for example, has certain policies in place to let a firm trade any shares using its facilities.
A governing body, as the name suggests, provides policies in an ecosystem that form the framework for transactions in the ecosystem. It is important to distinguish between the roles of the ecosystem host and the ecosystem governing body. The governing body is a more passive entity — one that sets the policies but does not look into operational or day-to-day functioning of the ecosystem. It also does not facilitate interactions in the ecosystem. That responsibility is on the ecosystem host. For trading of company shares and other financial securities, the Securities and Exchange Commission (SEC) acts as the governing body.
Because the governing body is not associated with a specific ecosystem host, it is possible for multiple hosts to host an ecosystem that follows the guidelines provided by the governing body. For example, the NASDAQ provides an alternative stock trading facility to the NYSE. The two rival infrastructures are separate from each other; however, they both follow SEC guidelines. The companies listed on either of these two exchanges are expected to abide by SEC guidelines and to follow the day-to-day operational policies set by the respective ecosystem hosts.
In the service world, a governing body will most likely be a consortium. A consortium is a group of interested parties that work together to develop a specification for a certain task. Consortiums typically are a group of partners, competitors, common-interest parties, or legislature people; they determine certain guidelines, rules, maybe even interaction patterns and quality-of-service levels. The specification developed by a consortium is not necessarily binding to the members of the consortium, nor is a membership necessarily required to accept a specification. If a specification provided by a consortium is widely accepted, it becomes a standard for performing that task. Consortiums can deal with any topic you might imagine. We discuss some examples of consortiums in Chapter 2.
Business registries, like UDDI, support taxonomies to allow groups such as consortiums (discussed in Chapter 6), standards-setting bodies, or other governing third parties to apply these concepts to the network of services and clients that have decided to participate together in a service-based ecosystem. We introduce the ecosystem players in Figure 4.2.
An ecosystem monitor entity monitors the interactions between ecosystem members and ensures that the members of the ecosystem are following the interaction guidelines set by the ecosystem host and the governing body. Based on this, the ecosystem monitor can recommend changes in the functioning of a specific member entity or the ecosystem as a whole. There can be several monitoring entities in a given ecosystem. Also a specific monitoring entity may concentrate on only certain aspects in an ecosystem. For example, in the financial securities world, various independent auditing firms act as monitoring entities that audit the accounting and other financial business practices of companies to ensure compliance. The monitors can also provide metadata about an ecosystem and its members, based on their observations. One example of such metadata is service rating. A service rating can provide a relative or absolute standing of a service’s offering, based on a variety of parameters, such as price of the service and usage satisfaction. The users of the service can then judge whether to use the service or not, based on this rating.
It is possible in an ecosystem that the members get involved in a dispute for several reasons, including noncompliance with guidelines, unsatisfactory quality of service, breach of contract, or fraud. An ecosystem arbitrator acts as the mediator between the parties involved to resolve the issue. The governing body may provide guidelines for such arbitration, as well. In some cases, the ecosystem host or the governing body itself may act as the arbitrator. An example of this is the Internal Revenue Service (IRS) in the tax ecosystem. However, the arbitrator must be noted as a separate role in an ecosystem.
The role of ecosystem arbitrator is important even though it plays no part in the transactional aspect of the ecosystem functioning. Without it, effectiveness of the ecosystem could be compromised due to lack of recourse for any issues a member faces while interacting with other members in the ecosystem.
A registry in an ecosystem is a useful tool to locate a certain participating entity or a member of the ecosystem. Because it is possible that the number of the ecosystem members could be huge, the registries are an important means to get information about them. For the stock markets, several such registries, such as ValueLine, are available that provide a variety of data about listed companies and their financials. In service-based ecosystems, such registries provide specifics about the registered services. Earlier in this chapter, we described how services could be discovered and used on the fly. The service registries have a crucial role in the effective discovery of services mechanism.
Note
The role of a service registry and its importance in an ecosystem are widely accepted in the industry. As a result, standards are emerging to formalize creation of service registries. An example of this is UDDI. An overview of UDDI is provided in Chapter 5.
The ecosystem member entities are the very reason why an ecosystem exists. These form the second tier of the ecosystem — the member class services. The entities in this category use the ecosystem infrastructure provided by the ecosystem host and interact with each other to fulfill their needs. The ecosystem members must abide by the rules provided by the governing body, and they are subject to audits from the monitoring entities. Figure 4.3 diagrams the relationships of these additional ecosystem citizens.
In the service-based ecosystem, a further characterization of the member services is necessary. There are three main roles that can be identified for launch and use of a service:
Service Provider
Service Deployer
Service User
A service provider’s role is to provide the core functionality for offering the service. For example, a service provider for the Order Status service will provide the means to query the order database using several fields from the database and related conditions and will extract the order status information from the database in some format. Usually, a service provider will need to cater to needs of several interested entities and may not have the expertise or reason to pay close attention to needs of a specific entity or its operational environment. That is the responsibility of the service deployer (see the following).
We use the term business logic in this book to refer to the core functionality provided by the service provider. For example, the business logic provided by a stock broker service is the functionality to buy or sell stock with potential buyers or sellers, based on user-specified criteria (such as limit price) at the stock exchange.
As mentioned previously, a service provider is generally agnostic to the operational environment of the user of the service. A service deployer, on the other hand, is very sensitive to the operational environment and can do the best job of creating a user-friendly service experience. A service deployer works with the service provider to bring the service’s business logic to a certain ecosystem and corresponding operational environment. For example, Enterprise Resource Planning (ERP) system vendors, such as SAP, provide an operational environment to streamline the business processes for a company. The core for the business processes is in the form of the business process analyst team in the company, and the vendor’s professional services team helps in bringing those processes to the ERP platform.
A clear separation between the service provider and service deployer ensures optimal use of competencies. A service provider with the core competency in providing business logic can cater to several interested parties and platforms. On the other hand, the service deployer can help several service providers to provide their service to a specific ecosystem and its operational environment.
The Web services paradigm is based on this clear separation. We use this archi-tecture is subsequent examples throughout the book.
A service user uses the service offered by the service provider to fulfill its needs. There are several resources available in a service-based ecosystem at the disposal of the service user to ensure ease of use and quality of service. The service provider and the service deployer are mainly responsible for the ease of use and the regulatory class services ensure that a certain quality of service is maintained. The service user uses the appropriate service registries and the monitor ratings to choose a service that is most suitable for its needs. Any disputes regarding the service delivery between a user and provider can be resolved by the arbitrator.
Note
A user is not necessarily just a user in the Web service architecture. Because it is possible to compose several lower-level services to create a higher-level service, a user of a service can be another service itself! Thus, for all practical purposes, the distinction between a service and a service user is notional. An entity can be a service provider in one interaction and a service user in the other.
Figure 4.4 depicts the complete ecosystem with all its citizens.
For an ecosystem to be successful, it is necessary to have the right mix of all of the aforementioned roles — only that would ensure that the ecosystem is scalable, sustainable, and can cater to a growing user base. There are also two other factors that influence the subscription to an ecosystem.
Confidence: An ecosystem will be widely adopted if potential service providers and service users feel confident about the ecosystem environment. The ecosystem environment includes not only the existing members and the composition and credibility of the host and the governing body, but also the operating processes that the ecosystem employs. The existing and potential members should feel confident that the ecosystem provides a trusted environment for their business process and for dispute resolution. This trust or the confidence in the ecosystem comes from adoption of appropriate business standards and effective functioning of ecosystem-monitoring entities.
Note
Having trust in an ecosystem does not necessarily imply the same trust assumptions for individual members of the ecosystem. In a dynamic business environment, it is likely that you may not even be aware of the existence of the entity you discover, much less its trustworthiness. The importance of trust in the overall ecosystem environment is more underscored due to that.
Security: The wide variety of roles in an ecosystem also raises an important question — What are some of the security measures required in an ecosystem to make it a safe environment for the business transactions to take place? This concern comes from the fact that an ecosystem can be an open environment that facilitates intercompany transactions and, thus, carries sensitive data about business dealings. Before you send a quote for a certain product to a potential customer or a product specification to a potential vendor, you want to be assured that it will not fall into the wrong hands; moreover even if it did, you want to make sure that they will not be able to read it.
There are several security aspects that the ecosystem host and/or the governing body need to address — first, independently, to address each of them thoroughly, then, collectively, to maintain consistency. These security aspects range from encryption of data on the wire and authenticity of an individual entity to security enforcement infrastructure of the ecosystem as a whole. Chapter 10 discusses the mechanisms that the Web service paradigm uses to address the security and the trust assumptions.
Bringing services to life is an interesting task for business IT managers of the ecosystem participants. It requires not only the operational resources, such as time, talent, and funding, but also the strategic (both horizontal and vertical) partnerships of other ecosystem members. It is an all-encompassing activity that is akin to the efforts required in building a product or software. From a business manager’s perspective, it is useful to recognize the similarity. Following a lifecycle approach to launching a service can greatly assist in planning; however, recognizing the nuances is also important. The standard lifecycle is depicted in Figure 4.5.
Strategic planning: Appropriate business relationships are formed in this phase. Should a consortium wish to foster co-opetition be desired, the discussions and negotiations with competitors and partners must happen here. Having a clear vision of what the consortium should provide will help guide the discussions. The consortium then needs to work to develop the framework for services.
Requirements: The requirements for the service will be gleaned from the consortium decisions, as well as the target market. It is important to notice that some of what the service does (or the minimum that the service does) will be strongly influenced and governed by an ecosystem and its monitor, so taking these into consideration will be very important during the service planning.
Architecture and design: Catering to an “unfamiliar” audience is important in this step. Because of the dynamic discovery capabilities of a service-centric architecture, you will find a whole host of users (hopefully!) who may or may not be familiar with your name. Accounting for unfamiliarity will promote use of your service and perhaps allow for repeat business and a superior service rating.
The usual distributing computing design issues still exist. Internet latency and instability must be designed for the service so that reliability and speed can be forced and handled in the complex web of computers.
Development and quality assurance loop: The standard software development processes follow in this phase for the service. However, the quality assurance must also take into account any requirements placed on the service by the ecosystem in terms of system engineering metrics. Ensuring that it is “fast enough,” as defined by the ecosystem, stays “alive” long enough, as defined by the ecosystem, and so on, is essential in this phase.
Deployment: The deployment of a service or the “opening” of the service doors really activates it in the ecosystem environment. The ecosystem dependencies need to be thought out; thus, deployment needs to be orchestrated such that all prior ecosystem dependencies are fulfilled.
Support and service documentation: The complexities of distributed computing, such as separation of the requestor and the doer, are enhanced in a service-centric environment. The service support model must not only be one with effective documentation and help desks but should also provide reactive and after-the-fact resolution. The kinds of questions that need to be addressed by a comprehensive support model are:
How do I use this service?
What do I do if the service does not perform its task?
How do I report data discrepancy?
What is my liability protection for bad service implementations?
Obsolescence: A service’s offering becomes outdated over its life. It is very important to recognize this and to plan for improved offerings via future enhanced services.
Figure 4.6 describes the service lifecycle. This lifecycle considered the stages a service goes through in its lifetime. Let’s consider a different time span and a narrower scope of simply deploying and using a service. The steps involved in that are shown in Figure 4.6.
As shown in the figure, the first step is to create and deploy the service in an ecosystem. Both the service provider and service deployer are involved in creating and deploying a service. The service provider manages the implementation of the business-level decisions such as the service’s business logic, market, and pricing. The service deployer manages the implementation of the transactional frame-work of the service, based on the operational requirements set by the ecosystem’s governing body.
A deployed service is functionally ready to be discovered and used by service users; however, it must be registered and advertised first with the ecosystem. This is done during the Service Registration and Service Advertisement steps. More complex services (made up of other simpler services) may need to be composed prior to being invoked by the service users. After the composition, the complex service is fully formed and usable. Users can interact with discovered services to accomplish the specific task for which they were chosen. This interaction with the services can be direct or brokered through a mediator.
A mediator is desired for transactions between a service and its clients. It plays the role of a trusted third party in a dynamic interaction environment. The mediator can log and monitor the interaction. It can also create a persistent interaction experience for the service or the client by shielding them from failures on either side. In a fully trusted environment, direct interaction between a service and client is possible.
Note
There is a cost associated with the mediator’s benefits. The added step in the interaction sequence may result in lower throughput. A service user may experience slower response during a mediated transaction versus a direct transaction.
Once a service is deployed, its potential customers can use the service. For best user experience, service delivery is just as important. In case of business users, the service delivery may also be associated with the integration with existing infrastructure. The more seamless the integration is, the more appealing the service is to its users. While a service developer or deployer can design a default service delivery and experience, typically a more customized approach would be needed.
Registry-powered business implies that a business registry is not only at the center of the ecosystem; it also plays a substantial role in the transactions that occur in the ecosystem. In Chapter 2, we discuss the role of the registry in an employee portal. In that example, not only does it serve as the central storing house for services in a particular ecosystem, but it also serves as the intermediary among various ecosystems.
The employee portal from Chapter 2 is a private registry that caters to employees of a company. The business registry is not limited to providing discovery of services only within its established ecosystem. Business registries can be the intermediaries for an ecosystem with external entities whether those are other services, another collection of services (a business registry), or even a full ecosystem. As the intermediary, the business registry can play several roles. It can:
Assist members of the ecosystem to discover, browse, or interact with services of another ecosystem (assuming the appropriate relationships have been formed; for example, contracts and security arrangements have been made)
Provide members of another ecosystem access to its service portfolio (again assuming the aforementioned arrangements)
Interact with a larger open-access or restricted registry (import or export service meta deta)
In essence, the intermediary nature of business registries can be considered the virtual link between an ecosystem and other external entities. In the example of the employee portal, the registry can provide access to services that are external to the Employee ecosystem but are the result of relationships formed between the company and external service providers. For example, if the company has a relationship with a top-tier Cinema Theater, the portal could route employees to the Cinema Theater’s online ticket purchasing service. Employees receive a discount on movie tickets using the referral mechanism. This requires collaboration between the employee portal and Cinema Theater’s online services. Figure 4.7 depicts this relationship.
The Web Services lifecycle (described in Section 4.2) facilitates the process of developing and deploying Web services. However, as we also see, Web services are found in two categories — lower-level and higher-level services. Lower-level services can be combined together to form higher-level or complex services. Figure 4.8 depicts this relationship.
Notice that a lower-level service can be a part of several higher-level services. In that respect, it is a many—many relationship.
The process of creating these higher-level services can be thought of as service composition. Service composition creates a unified user experience — one that is inclusive of and different from any constituent service experiences.
One advantage of service composition is that it makes the creation of complex services simpler. A complex service can be thought of as a service that consists of several lower level services. For example, a virtual storefront could be created by assembling together cataloging, order management, payment, and shipping ser-vices (each from entities whose core business happens to be providing that particular business service). Each lower level service provides a specialized offering. The lower level order management service would provide only ordering functionality for the virtual storefront (a complex composite service). As you can see, a virtual storefront provider is shielded from the intricacies of supply chain management if a set of reliable supply chain services has been composed into a higher level complex service, thereby allowing the storefront to focus on finding, selling, and advertising high-quality goods.
Using this model of service design, it is possible to create services of any complexity with a good degree of manageability. Conceptually, service composition is analogous to functional decomposition or top-down design approaches used in software engineering.
Continuing with the top-down design analogy, Web service developers identify the functional components that are needed to build a higher-level service. In the employee portal example, to develop a higher level IT Helpdesk Service, a Corporate IT developer may need:
Employee Authentication Service
Problem Ticket Service
Employee Survey Service
The developer must collect these services together to provide the necessary functionality. Business registries can facilitate this collection. They act as the depot of available services that can be composed together. There is another advantage to this design. Besides the obvious reusability, due to the fact that the employee authentication service is already deployed within the environment; there is no need to redeploy it for this purpose. A scalable Employee Authentication Service that is only used very briefly for verification purposes should be shared among various components of the employee portal. Business registries not only help discover functional units, but also provide access to deployed services that can be shared.
Business registries, as we see, play a vital role in distributed solution architectures. There are several types of business registries. In Chapter 13, we discuss these in detail. However, the Web services paradigm is standardizing around the Universal Description Discovery Integration (UDDI) business registry. In the next part, we discuss UDDI in detail.