Throughout the book, we used an employee portal as the basis for explaining UDDI-related concepts and demonstrating UDDI API usage. We have viewed UDDI from various perspectives: that of a service publisher, a service consumer, and of a solution deployer. Understanding these perspectives is critical in deploying any UDDI-based solution. However, it is also important to see how UDDI solves critical business problems. In this part of the book, we offer case studies and delve into how UDDI fits into larger business solutions.
In this chapter, we unfold the employee ecosystem of a global corporation and demonstrate how it can be fueled by a UDDI-powered employee portal. It is designed to facilitate interactions between corporations and their employees. We describe the UDDI-based employee ecosystem in detail but leave the deployment and actual development issues to the reader.
An ecosystem of a company consists of its partners, vendors, customers, and the regulatory environment. Thus, an employee ecosystem includes the people, technologies, processes, and services that are important to employees and other interested parties. As we mention in Chapter 2, the employee portal is one of the most popular solutions in the business to employee arena. It provides access to the many services that corporations provide to their employees. Figure 11.1 illustrates this ecosystem.
Key constituents of an employee ecosystem are the people, entities, and services that interact within the ecosystem. Some people manage the ecosystem and lay out the framework in which to operate, others use the services provided, and still others provide the services available within the ecosystem.
As in any ecosystem, the employee ecosystem has a governing body that determines the policies and interaction framework that will exist within the ecosystem. In the employee ecosystem, that governing body is primarily the Human Resources (HR) department. The HR department is responsible for some decisions such as which services to provide, how to classify those services, and finally who has service access and to what level.
Note that ecosystems interface together at touch points provided by the registries that fuel them. In such cases, the HR department also interfaces with governing bodies of these internal or external ecosystems and exchange relevant information such as service definitions, categories, and interaction specifications. For example, the health care insurance provider that participates in the ecosystem of the corporation may have a set of services that are made available to member employees. These service definitions would be brought into the employee ecosystem registry for efficient and easy access.
The Global Corporate Information Technology department is in charge of the implementation and technology landscape of the employee ecosystem. Working in conjunction with the HR department, the IT department not only provides internal services for employees but also is the private UDDI registry operator for the UDDI instance that fuels the ecosystem. Both the services and the employee ecosystem technology landscape are discussed later in the chapter.
Finally, the users are the principal entities in the Employee Ecosystem. In the context of the employee ecosystem, employees are the primary users. There are many types of users in this ecosystem:
General: employees that interact with services and processes for the purpose of consumption.
Administrative: users that manage the behind-the-scenes activities such as access control.
Superusers: users that may make global platform configuration changes.
However, people are not the only users of the employee ecosystem. Service consumer applications can also be designed and written to interact with the UDDI registry as well as the discovered services.
Two other key components of the employee ecosystem are the services and processes provided for employees. For the purpose of this discussion, we separate processes and services. Note that processes are not necessarily supported by a technology backbone. For example, a process could be the corporate campus entrance authorization process wherein an employee shows a badge to a guard to enter the campus during off hours. A service is an isolated piece of logic that rests on a technology foundation. For example, managing the 401(k) elections of an employee is a service. There are several categories of processes and services. We group them at a high level and think of three major groupings:
Internal
External
Administrative
We make the distinction between internal and external services because these are owned and operated by different entities.
Internal processes and services are those that are provided for by the corporate environment itself. These processes and services are designed, developed, deployed, and managed by an internal group of people. Within the employee ecosystem, all corporate mandated and supported processes and services are registered within the employee portal UDDI registry. Hence, hereon we refer to both processes and services as services since they both will have an electronic representation within the UDDI registry.
Internal ownership of these services essentially means that the HR and IT departments own the service lifecycle discussed in Chapter 4. Migrations, upgrades, and so on are determined by the corporation and can be enhanced to best suit the needs of the employees. It is important to note also that the UDDI publishing information about the services is also owned by the internal organizations; hence, it can be tailored exactly to suit the needs of the consuming applications and employees. Examples of internal services are as follows:
Time Off Management Service
Education Course Registration Service
Conference Room Reservation Service
We mention that registries are the intermediaries between ecosystems. The purpose for this connection between ecosystems is primarily to share services. Technically, this sharing between UDDI registries can be made possible via the export and import usage models.
External services (again both manual processes and electronic services) are typically owned and operated by third-party service providers. Usage of these services by the employee ecosystem is contracted via business agreements and service level agreements set up prior to incorporation into the employee ecosystem. However, the independent nature of these services means that the service providers do have a higher level of autonomy. Generally, the only contractual guarantees that the service provider needs to uphold are of those around service levels and visible business logic (as opposed to internal functionality). The autonomy therefore implies that the service lifecycle is independently managed; while requirements may be influenced, the corporation does not own them. However, the corporation can and should influence the UDDI publishing information or service definition within the registry it controls. Recall that the UDDI operator and the ecosystem governor both play a significant role in determining the policies of the employee ecosystem. In this case, both of those entities are bodies internal to the corporation.
Examples of external services are as follows:
401(k) Information Service
Employee Stock Purchase Plan Management Service
Credit Union Information Service
We separate out administrative services because they may or may not ever be used by the general class of users described previously. These are services that mainly help HR and Corporate IT monitor what is happening within the ecosystem and the portal. These services could be either internal or external. For example, an Availability Service could be used by Corporate IT during troubleshooting exercises, to ensure that an internal or external service is available and accepting requests. Another example of an administrative service is the authentication service that could be used by all internal services.
The three Ps of the employee ecosystem are Policies, Procedures, and Policing. These are the guiding principals and enforcement constructs that are put in place for the ecosystem to function smoothly and as desired by the corporation. These may or may not have an electronic presence in the UDDI registry.
The HR and the IT departments develop policies instituted by the employee ecosystem. Policies of the ecosystem can be considered a sort of handbook for users, service providers, and administrators. There are a wide variety of situations for which policies to guide behavior are required.
There are policies that affect interentity communication with the employee ecosystem. For example, policies may dictate how an internal service can communicate with an external service to share information. This is especially important when sensitive information is passed as part of the transaction.
Other policies may be present surrounding the legal retention of the transactional information passed between users and services. Services that are affected by these policies may be able to interact with an administrative service that provides the business logic for the retention of transactional information.
Procedures are the hows to do various tasks within the ecosystem. Procedures, just like, policies can be documented only or also defined for the UDDI registry. A procedure for obtaining access to the employee ecosystem is one example. There could be various subprocedures to handle different types of users. For example, a third-party service provider would need to follow a different set of steps to obtain access to an employee ecosystem as compared to an employee.
An example of a procedure that is unlikely to be modeled for the registry is that of reporting problems with a service, information, or a policy/procedure. That is likely to be a documented item that is available as part of the employee portal Web site.
Policing of any ecosystem is critical. However, the UDDI registry is not designed to be a gatekeeper and hence appropriate security policies, procedures, and technologies need to be designed within the ecosystem to ensure employee trust is obtained, fostered, and maintained. For example, each service should handle its own authorization policies and procedures.
Notice that in Figure 11.1, the internal employee portal UDDI registry has an important role within the ecosystem. In Chapter 10, we examine the role of a registry in a variety of scenarios. In this case, the registry plays several roles. These are as follows:
Stores access information about approved internal and external services
Stores important policies and procedures
Provides access to administrative services for service developers and ecosystem monitors
Houses interaction and classification framework
Acts as a reference for service developers
The employee ecosystem is truly a technology quilt. Several disparate technologies work together to provide an interaction platform for the aforementioned users, services, policies, and procedures.
The portal technology provides an interface accessing various enterprise applications, services (both electronic and manual), and corporate information sources. The portal Web pages may be written to communicate to the UDDI registry to access services meant for direct consumption.
Consider the example of a Corporate Approved Taxi Service. This service is designed to return the corporate approved taxi provider for a given zip code. It uses the employee portal registry to query the list of taxi service providers possible. The Web pages designed for the service facilitate communications between the employee and the registry.
Other portal Web pages may call on applications or Web services that in turn use sub-services to carry out administrative functions. Noteworthy is that by establishing the UDDI registry as the source for all services, the employee ecosystem operators can ensure that applications are using the latest service edition available and not an out-dated or since discontinued but not yet turned off service.
Several internal services are also another key component of the employee ecosystem. Examples of these services are discussed previously. However, it is interesting to note that these services can be either .NET based, J2EE based, or even manual services. The entry points or access points of these services are published to the UDDI private registry such that applications and direct user interfaces can be written to access them. With respect to UDDI, because it communicates via SOAP messages, .NET, JAVA, or any other platform-based services may interact with the registry directly so long as the appropriate SOAP messages are formatted.
A variety of enterprise applications provide the business logic required for the services, processes, and procedures to work. These applications could include applications such as a payroll processing application, an employee benefits database, and a stock options grant database.
Corporations are unlikely to build all the business logic and procedures that are required by an employee ecosystem. Several companies specialize in certain niche areas. For example, 401(k) services are generally not provided directly by the corporation but by a contracted service provider. Often the services from these external entities will be available through partnering with an external ecosystem. Cross-ecosystem interactions such as import and export of service definitions may occur between the employee ecosystem UDDI registry and the external UDDI registries.
Several interactions within this ecosystem are secured. This infrastructure ensures that authorized users initiate and complete transactions and the transactional data is not compromised. For example, service publisher interactions with the UDDI registry are carried out through secured Hyper Text Transfer Protocol (HTTPS) with username and password authentication.
A comprehensive technology landscape coupled with a consistent and efficient modeling design makes the employee ecosystem a powerful solution. Recall from Chapter 6 that modeling happens at various levels and of a variety of entities. In this case study, we model the key participants of the ecosystem:
Ecosystem Governor
Service Publishers
Service Consumers
Service Developers
An ecosystem governor is usually the corporate entity itself and must be modeled as such. In this case, both the HR department and the Corporate IT department within the company share the responsibility for setting the policies for service publishers and service consumers. They also provide the structure and framework for ecosystem interactions. Given the crucial role that a governing body plays in the ecosystem, it should be modeled as a separate entity in the registry. In this example, the HR and IT departments should have a separate representation as the governing body despite being part of the modeled parent company. Modeling the governing body in this independent manner helps in creating a clear demarcation of roles and responsibilities. The ecosystem governor entity sets the policies and procedures for the rest of the ecosystem. Some examples of policies and procedures that the ecosystem governors may set in this case include:
What services are included in the ecosystem
How long ecosystem logging information must be retained
When internal and external services may schedule system maintenance
Note
It is important to point out the relationship between the ecosystem governor and the parent company in the employee ecosystem. Since the governing body is fully subsumed by the parent company, this relationship can be modeled through publisher assertions as described in Chapter 6.
There are definite differences between modeling for internal versus external service providers. These differences are primarily a result of the autonomy that external service providers enjoy with respect to their service offerings. Also the security and trust assumptions vary between internal and external service publishers. Thus, internal and external service providers should be modeled separately and differently from each other.
Internal service providers need to model the service publishing entity as well as the services themselves. The ecosystem governor provides the categories that are available for classification. Hence, simply using the approved categories is sufficient.
It is important to note that even within the corporation there may be several departments that publish services to the ecosystem. With the ability to model entities and their relationships in the registry, the individuality of internal departments may be preserved. This is critical because the user name and password are linked to the published information. Thus, for individual service publishers to manage their service registrations, they need to have their own user names and passwords. The alternative would be one corporate-wide user name and password that is shared by all internal service publishers, but we do not recommend this as it causes ambi-guity in roles, responsibilities, and separation of duties. Publisher assertions then need to be deployed linking the department-level entities to the parent company entity.
External service providers are also modeled within the UDDI registry. Ecosystem governors have to determine on a case-by-case basis whether a third-party service provider should use an existing category or whether they should define their own categories. Once decided, the entity definition may be imported into the employee ecosystem UDDI registry.
Service consumers are not necessarily modeled within the registry. In the employee ecosystem too, individual users, whether they be people or applications, do not necessarily have an electronic presence (a model) within the registry. Any authentication, tracking, or logging that is desired needs to be deployed with add-on solutions to the portal technology or the Web services technology described previously.
Figure 11.2 depicts the business entity-level modeling within the ecosystem.
Modeling entities and services also includes determining which categories and interaction specifications will be used. Thus, the model for business entities and services includes not only specifics on the entities/services themselves but also the relevant meta information.
The ecosystem governor determines the categories that are available for use within the registry. Several categories are built into the registry such as the North Amer-ican Industry Classification System (NAICS). However, external ecosystems and registries are also a source for categories. These categories may be imported into the employee ecosystem UDDI registry. For example, the Financial Services industry may have categories defined that are very prominently used by financial entities. These categories may be such well-defined standards that it makes sense for the ecosystem governor to import these rather than develop its own. The employee ecosystem governor would need to watch for other industry standards around classification schemes because loading the registry with standard definitions makes it more interoperable with the external world.
Internal and external entities and services need to determine which of the available categories makes sense to publish within. Both groups may find the need for additional categories and will need to make the case to the ecosystem governor for additional classification schemes. For example, the internal Time Off service developers may find that none of the existing categories serve its needs and, hence, a new Time Off category is desired. Likewise, the third party Counsel-ing Services entity might find that none of the existing categories are appropriate and also request a new category. Ideally, the ecosystem governor would abstract out a commonality between UDDI resources and develop higher-level categories. In this case, a new category called Personal Life may be published. Thus, a subset of categories can be published or imported into the UDDI registry and added to as necessary.
Finally, it is important to group internal and external entities and services separately. For this reason, the ecosystem governor may mandate that every entity and service classify themselves within the Internal or External categories. Being able to query on this will be useful for managing the registry and making broad declarations based on internal/external boundary. For example, all external services may undergo random testing to ensure quality of service levels are being met while internal services may be all unavailable during company-wide shutdowns.
It is critical to make these categories available to the service consumer application developers. This ensures that service consumer applications can be written to search within only a certain subset of categories. These categories and their appropriate values are published to the UDDI registry as explained in Chapter 8 as tModels.
Interaction specifications, like categories, come from a variety of sources. More than likely, when there is a category standard (like in the Financial Services industry described previously) a set of accompanying interaction specifications will also be standardized. In this case, the ecosystem governor needs to import these into the registry and make them available for the service consumer applications to develop consumer logic that uses the services based on these interaction specifications.
The second scenario exists when the ecosystem governor has corporate policies and government/legal mandates that dictate certain interaction patterns. In these cases, the ecosystem governor defines an interaction specification that is published to the registry and imposes those on the internal and/or external service providers.
A third scenario is where no industry standard exists, but no internal standard needs to be mandated—hence the external or internal service provider need only to develop a de facto interaction specification from the services themselves.
In all three scenarios, issues of security and trust must be taken into consideration and accounted for.
In Chapter 14, we discuss the enhancements made to the UDDI specification in Version 3. Version 3 of the specification is much more supportive of the global private networked registry scenario. To this end, there are many enhancements that are useful for the employee ecosystem. Key among these new features are increased support for internationalization, security, and private registry policy definition and execution.
By explaining the employee ecosystem and the role of the UDDI registry at a high level, we have highlighted several key aspects of planning such a platform. We focus mainly on the modeling of various entities and the role of the ecosystem governor in this case study. In subsequent case studies, we highlight the interactions among various ecosystem entities.