Home > Articles > Web Services

  • Print
  • + Share This
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.3Figure 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.4Figure 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:

  1. Service Provider
  2. Service Deployer
  3. 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.5Figure 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.

  1. Strategic Planning
  2. Requirements
  3. Architecture & Design
  4. Development & Quality Assurance Loop
  5. Deployment
  6. Support & Documentation
  7. Obsolescence

Figure 1.6Figure 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.

Figure 1.7Figure 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.

  • + Share This
  • 🔖 Save To Your Account

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020