- The Information Age and the Internet
- The Web of Services
- The Ecosystem
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.3 The Ecosystem
An ecosystem, as we saw earlier, is a collection of related services. This collection, as a whole, provides a set of services in a specific domain. Using the example we discussed earlier, a Travel Industry ecosystem would cater to the traveling needs of a certain set of customers or a Medical ecosystem 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 just 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 Travel Industry ecosystem, for example, the airlines, cab services, and hotels can be thought of as lower level member services in that ecosystem. A higher level service aggregates these services to create a tour package that consists of traveling by a certain airline, going to points of interest using a specific cab service, and staying at a specific hotel. The tour package service can either have static relationships with certain entities or can put together a package unique to the set of requirements provided.
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 1.3 shows the relationship between various roles in an ecosystem.
Ecosystem Host
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 trader firm trade any shares using its facilities.
Governing Body
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. We will discuss a similar scenario in Chapter 5.
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 specifica-tion 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. Some examples of consortium are:
Consortiums of similar functions coming together to actualize economies of scale or to streamline their business process (for example, RosettaNet)
Consortiums of groups trying to solve a certain societal problem
Consortiums of technology pioneers (for example, W3C or Universal Description, Discovery, and Integration [UDDI])
E-Speak supports vocabularies and contracts to allow groups such as consortiums (discussed in Chapter 5), 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 1.3.
Ecosystem Monitor
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.
)
Figure 1.3 Introducing the ecosystem players.
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.
Ecosystem Arbitrator
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.
Member/Service Directories
A directory 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 directories are an important means to get information about them. For the stock markets, several such directories, such as ValueLine, are available that provide a variety of data about listed companies and their financials. In service-based ecosystems, such directories provide specifics about the registered services. Earlier in the chapter, we described how services can be discovered and used on the fly. The service directories have a crucial role in effective discovery of services mechanism. In Chapter 11, we discuss the default service directory that e-Speak provides.
NOTE
The role of a service directory and its importance in an ecosystem are widely accepted in the industry. As a result, standards are emerging to formalize creation of service directories. An example of this is UDDI. It is an industry-wide initiative to create a platform-independent open framework for building service directories.
Ecosystem Members/Services
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 1.4 diagrams the relationships of these additional ecosystem citizens.
)
Figure 1.4 Relationships of ecosystem players.
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
Service Provider
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.
Service Deployer
As mentioned earlier, 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.
E-Speak's architecture is based on this clear separation. In several examples we will discuss in subsequent chapters, this architecture has been used.
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 directories 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 1.5 depicts the complete ecosystem with all its citizens.
1.3.2 Fostering Ecosystem Loyalty
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.
)
Figure 1.5 depicts the complete ecosystem with all its citizens.
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 is 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 and that even if it did, they will 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 8 discusses the mechanisms that e-Speak uses to address the security, as well as the trust assumptions.
1.3.3 Service Lifecycle
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 very 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 1.6.
Strategic planning: Appropriate business relationships are formed in this phase. Should a consortium 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 to participate together in.
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.
- Strategic Planning
- Requirements
- Architecture & Design
- Development & Quality Assurance Loop
- Deployment
- Support & Documentation
- Obsolescence
)
Figure
1.6 Service lifecycle.
Architecture and design: Catering to an "unfamiliar" audience will be important. 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 in 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. The later chapters of this book discuss the development of services based on the e-Speak technology. However, the chapters also discuss service programming basics that are applicable toward using other platforms. However, the quality assurance must 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 again, as defined by the ecosystem, and so on, is essential in
Deployment: The deployment of a service or the "opening" of the service doors really is activating 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 and frustrations of distributed computing — separation of the requestor and the doer — are enhanced in a service-centric environment. The service support model must be not only one of effective documentation and help desks but also of 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 important to recognize this and to plan for improved offerings via future enhanced services.
1.3.4 New and Improved Trip-Planning Experience
Earlier in this book, we discussed the problems of working with the Web. Figure 1.1 depicts the complicated and tedious task of trying to pull together something such as a trip. Ecosystems of services help to put a rational face to the complexity and simplify the experience for the user. Now, planning a trip from San Francisco to New York is simply a matter of finding the right Travel Industry ecosystem and using a trip-planning service. This service transforms your trip criteria into a travel itinerary that includes everything from airline tickets to the most appropriate jazz concert reservations. The choice of airline or hotel would be based on your preferences, restrictions, and criteria. If your travel plans must change, you need only let the trip-planning service know, and it can do everything all over for you. Note that the resultant set of lower level services, such as airlines, and hotels, could be completely different from the original itinerary yet still satisfy your original trip wishes. The final result is that ecosystems and services make the Web work for you. Figure 1.7 shows this new and improved way of getting work done.
){kind=link}
)
Figure
1.7 Making the Web work for you.
Creating an ecosystem can be a very complex task. As we discussed earlier, there are several roles that must be fulfilled by relevant entities to populate the ecosystem environment and make it sustainable. The most crucial role, the governing body, needs to identify the processes and policies for the functional aspects, whereas the ecosystem host needs to deal with the operational environment to facilitate the processes and implement the policies.
Several tools (software, hardware, professional services) are available in the market to address a single aspect of ecosystem creation. However, a holistic approach makes it easier to build such ecosystems. Such an approach provides a framework for different areas in ecosystem creation. Because the idea of service-based computing and ecosystem of service is now adopted as the future of distributed computing, there are a few initiatives in the works from leading companies such as Microsoft, IBM, Sun Microsystems, and HP.
However, other industry initiatives are rallying behind the concept of a web service. At the conceptual level, a web service and an e-service are not that different. However, the foundations they are built on and the underlying technologies are where they differ. Web services are built on interoperability and standards-based initiatives, whereas e-Speak (also a visionary in this space) had to focus on providing a complete solution to realize the vision because there was not much available in the market.
E-Speak is focused on providing a whole solution to foster the ability of deploying e-Speak-based services in an ecosystem. In that light, it addresses everything from service description to service discovery and, to some extent, high-level business interaction on the wire — all within a highly secured environment. Web services are focused on ensuring an interoperable environment based on the exchange of a specific electronic document formatted in a particular way (an XML document) is produced. To some extent, web services are agnostic of the technology, as long as the exposed endpoints (the web services in the ecosystem) can understand the XML document carrying the information.
Conceptually, e-services and web services support the concept of making the Web work for you. Exposing business assets in such a way that they can be dynamically registered, discovered, and invoked through a series of programmatic constructs (e-Speak Java Application Programming Interface (APIs) or web service electronic documents) is at the heart of the service economy. We discuss the current technological nuances that differentiate the two industry terms in Chapter 13. In the near future, these terms are likely to converge into one common meaning and technology.
In the next chapter, we look at the e-Speak architecture and how it supports a service-centric economy.