Jwbt251-Sweeney March 22, 2010
Download 120.98 Kb. Pdf ko'rish
|
9781119200178.app02
|
P1: OTA/XYZ P2: ABC
appB JWBT251-Sweeney March 22, 2010 11:15
Printer Name: Hamilton APPENDIX
B Service Categories and Types N o book on service-oriented architecture (SOA) would be complete without a discussion of services. Services have been defined in many different ways by different individuals writing about SOA. Despite all the variations, the definitions all cover the same basic points. The service definitions I use and the way I slice and dice those definitions into categories and types are provided here. It is not coincidental that the way I classify services is consistent with the architecture layers and frameworks that have been described throughout this book. I included these definitions as an appendix so you could find and reference them easily. Business analysts and business architects should use the definitions to help them understand and explain why requirements are gathered and structured in a certain way based on the type of service being defined. Solutions architects should refer to them to help them in defining and estimating project costs and scope and to produce the high-level design architecture on SOA initiatives. Project architects will use them when describing the detail design and development characteristics with the systems analyst and programmers. Finally, all the design patterns and design standards that the enterprise architects develop will have characteristics that align with the different service categories and types. Service Categories The major service categories are:
Business Domain services Enterprise framework services
System or utility services The Business Domain services include:
Channel services Business process services
Business services Integration services 311
By Rick Sweeney Copyright © 2010 by Rick Sweeney.
P1: OTA/XYZ P2: ABC
appB JWBT251-Sweeney March 22, 2010 11:15
Printer Name: Hamilton 312
Appendix B: Service Categories and Types Enterprise framework services are comprised of consumer and provider services. Consumer enterprise framework services include:
Security services Identity provisioning services
Personalization services Profiling services Provider enterprise framework services include:
Logging services Audit services
Billing services Exception processing services System or utility services include:
File transfer services Encryption/decryption services
Data format transformation services Monitoring services Business Domain Services Business Domain services are those that exist within a specific horizontal layer of the service-oriented architecture (SOA) enterprise architecture framework (SOA EAF). Their purpose is to provide business capabilities. Business Domain services handle all the presentation logic, business logic, and data logic defined by the business. Channel services manage:
The access and use of a channel. The invocation of policy enforcement points for processing authentication ser- vices provided by the enterprise SOA security framework.
The session and state (if supported by the channel) of the user while using the channel.
Any presentation layer characteristics defined by any personalization or profiling attributes provided by those frameworks.
The presentation and invocation of the lower-layer services the user is allowed to invoke based on its authenticated user’s profile. Business process services are the most comprehensive and complex services. They are multistep, multibranching process flows that manage a defined business process from start to completion. They consume and orchestrate multiple lower-level business services that are required to complete the defined business task at hand. While many business process services will be consumed directly by a user through a channel, they do not have to be. Business process services can be designed to perform complex background processes with no human intervention. A business P1: OTA/XYZ P2: ABC
appB JWBT251-Sweeney March 22, 2010 11:15
Printer Name: Hamilton Appendix B: Service Categories and Types 313
process that gathers and compiles all of a user’s utilization statistics over a defined period of time and generates a bill for that utilization is an example of a background business process service. Business services are more granular than business process services. They provide discrete, bounded units of work more in line with a business function than a business process. Business services represent the lowest level of granularity exposed to a consuming constituent. Everything that happens below this layer ultimately should be completely invisible to the consuming constituent. Integration services:
Manage the physical characteristics and restrictions of the non-SOA legacy ap- plication environment and isolate the higher-layer services from them.
Provide isolation and abstraction from the physical legacy systems. Handle semantic data model mapping and translation to the proprietary formats of the underlying legacy systems.
Handle the routing of requests to multiple systems and if necessary multiple systems of record, when they exist, and handle all CRUD (Create, Read, Update, and Delete) activities associated with those systems.
Integrate with the enterprise SOA security framework services to acquire and provide the appropriate profile attributes for authentication and authorization by the proprietary security systems within the legacy application environment. Enterprise Framework Services Enterprise framework services are vertical services. They transcend the horizontal layers of the SOA EAF and provide supporting interaction capabilities needed be- tween the services at each layer. They represent shared capabilities that need to be managed and monitored holistically. They eliminate the requirement for coding the integration of these vertical capabilities within every service at every layer and the creation of thousands of point-to-point integration and interoperability code sets. Consumer Enterprise Framework Services Security services manage the security policy enforcement specified and required at each layer of the architecture. At the Channel layer, the enterprise SOA security framework provides services to authenticate the user and establish authorized service privileges. At the Business Process and Business Service layers, it provides services to validate credentials and authorize the use of the process or service invoked. At the Integration Service layer, the enterprise SOA security framework provides the appropriate individual or group security profile attributes required for access to the underlying legacy system’s embedded and/or proprietary security system. As you can see from this description, the design pattern and design standards used to invoke the security services by services at each horizontal layer are different. The enterprise SOA security framework also has distinct design patterns. It has to manage what credentials and attributes are established at each layer and if and how those credentials and attributes are needed by services in other layers. Each service has a design pattern that ensures that every service in the same layer invokes P1: OTA/XYZ P2: ABC
appB JWBT251-Sweeney March 22, 2010 11:15
Printer Name: Hamilton 314
Appendix B: Service Categories and Types the enterprise SOA security framework services the same way and uses the same consistent set of credentials and attributes. Identity provisioning services are enterprise services that maintain all the cre- dentials and profile information of the enterprise SOA security framework as well as any remaining stovepipe security systems in the legacy environment. These services are used to create the security profile for a new user in the enterprise SOA security framework as well as in any underlying legacy systems that require user authenti- cation and authorization from integration services accessing the legacy application’s application program interfaces or data stores. Provisioning services are used to syn- chronize security data across these security systems to support events like password changes and resets. Provisioning services are also used to disable the user’s security in all the systems if the relationship with the user is terminated. The security and provisioning services just described are not a single-sign-on (SSO) solution. SSO is a user presentation layer login and logout synchronization technology. It facilitates user access to multiple applications with multiple authen- tication logon mechanisms. SSO’s value proposition is predicated on the basis that multiple embedded stovepipe security systems will continue to exist and grow. The security and provisioning components of an SOA framework provide support of and migration to a single enterprise SOA security system designed to control access to all services through all channels by all constituents. The enterprise SOA security and provisioning frameworks provide a mechanism to handle the support of the security requirements of the underlying legacy applications for as long as they exist. The SOA’s goal is for all these stovepipe security systems to go away as legacy appli- cations are modernized or replaced. The expectation is that ultimately all the core business applications—regardless of if they are custom-built in-house, purchased, or leased—will expose services through the enterprise SOA security framework utilizing a federated security model. The security and provisioning frameworks discussed here and throughout the book are architectural design approaches that are critical to achieving the SOA strat- egy and realizing its benefits. The success of your SOA strategy will be based on your ability to facilitate the delivery of any service through any channel to any con- stituent as efficiently as possible with no or minimal additional coding investment. Having an enterprise SOA security framework that every user authenticates through and every service authorizes against is the only way to achieve this objective. Since you are adopting an architectural approach to SOA, you understand this requirement and apply these frameworks to all SOA developments from the beginning. Personalization services manage the attributes associated with user-configurable customized offerings within your applications and provide this information to all SOA components that use it. An example of a personalization capability is language preference. When a language preference is specified, all services use this attribute supplied by the personalization service to display all fixed data in the language spec- ified. An architecture framework designed to support this capability is defined by the enterprise architects. The design patterns for all services with exposed presentation services specify how to interpret the personalized attribute and display the correct language. Under this approach, each service would construct XML templates for the fixed-format presentation layer data in each of the supported languages. When the service is invoked, the fixed data template for the specified language would be used by the presentation layer logic.
P1: OTA/XYZ P2: ABC
appB JWBT251-Sweeney March 22, 2010 11:15
Printer Name: Hamilton Appendix B: Service Categories and Types 315
An alternative approach would be to have all the fixed text stored in English and have each service use a translation service to translate the text to the appropriate language. There is a performance trade-off with this second approach. The architects may determine that both approaches are allowed with performance considerations determining the appropriate one to use. Regardless of which approach you use, if you want to support multilingual capabilities in your SOA applications, the architects should design and implement language management and maintenance services within a personalization manage- ment framework. This framework would allow for adding new language templates to existing services and new language translation rules to a language translation ser- vice. It would also allow for word replacement or substitutions in existing templates and rules when necessary. The personalization management framework is to the personalization frame- work as the provisioning framework is to the security framework. The security framework assumes the security profile has been provisioned in the legacy system so the credentials it provides to the integration service will work. They work be- cause the provisioning services have created the profile and synchronized the data within the profiles. The personalization framework assumes the language template or translation rules the service needs to support the specified language are in place. This framework created them, so they will be in place. Building SOA applications from an architecture perspective takes the consid- eration of requirements like personalization from a tactical point solution or af- terthought to a strategic level where they can be designed and embedded into an architecturally driven development approach. If you want to build SOA applications to support global or multilingual usage, you need to architect how to do this up front. If you do not, you will be forced to create new versions of all the services to accommodate these needs in the future. The implication of a tactical approach will become evident if you need to consider additional personalization capabilities and profiling capabilities in the future. The impact of these changes will be significant as each service would have its own framework for handling personalization and profiling. If you do not architect these frameworks up front as part of your enterprise SOA strategy, you will be forced to follow the same duplication and redundancy model that you are trying to eliminate through your SOA approach. Profiling services are different from personalization services in that they are not determined and set by individual users. Profile services manage attributes that apply to a group or set of users based on conditions unique to that group. Examples of profile attributes are “customer status” and “monetary currency.” You may decide to have platinum, gold, and silver customer levels and provide different services or levels of service to these customers. An order business process may automatically give free priority shipping to a platinum customer whereas gold and silver would have to select and pay for it. Using this profile attribute, the order business process will completely bypass the “select shipping method” activities with the work flow when a platinum customer is using it. A currency profile service would determine that any currency fields embedded in the service need to be displayed, captured, and processed as euros rather than dollars, for example. The integration services would use this profile information to understand that in one case the legacy system of record stores currency in euros, and in another case, dollars. Alternatively, the integration service would need to P1: OTA/XYZ P2: ABC
appB JWBT251-Sweeney March 22, 2010 11:15
Printer Name: Hamilton 316
Appendix B: Service Categories and Types know that the legacy system stores currency in multiple formats and needs to be told which one to return or update. Other profiling attributes can change the business rules used within the busi- ness process or business service. Orders placed by overseas constituents may have restrictions on which products can be sold or shipped to that country. Some states or countries may require that a disclaimer or disclosure statement be read and accepted by the consumer before the order is accepted. Following the logic of all the services just described, you can see that the design of architectural SOA frameworks allows you to:
Authenticate users and authorize services through a shared, common enterprise SOA security framework.
Deliver those services customized to the personal preferences of consumers and to support the unique conditions based on their profiles. I can guarantee you that none of this would be possible at a strategic enterprise level if you did not take an enterprise architecture approach to SOA. Provider Enterprise Framework Services Logging services provide the capability for business domain services to log a usage event. This framework is designed to allow service logging for domain services at any layer. Entries created through logging services can be accessed by other services in the same or different layers that are interacting with the service that created the log entry. A logging service framework can be designed to support logging of traditional flat-file records or logging events within a publish/subscribe framework. An example of a traditional logging service is the Channel layer logging a record for each user who logged on through the channel specifying who the user was, when he or she logged on, how long the user was logged on, and potentially all the services the user invoked during that session. This type of log record could be used by an audit service or a billing service at a later time. An example of a publish/subscribe service is one where a shipping service publishes a record of each order shipment. The customer notification service would subscribe to this publication and generate a shipping notification e-mail to the customer. Having logging services through a common shared framework provides the capability for any new service in the future to log transactions through these services and use any existing logged records or publications to support its processing needs. Audit services provide capabilities to monitor and manage information about the entire SOA application environment. Audit services can be designed as ad hoc, scheduled, or dynamic. They can be utilized by other business services, other frame- work services, and other stand-alone tools and platforms used to monitor and man- age the application, platform, and network infrastructure. For example, a channel adapter may create an audit record periodically to notify a socket “listener” of its availability. Alternatively, an out-of-band service may interact with the channel and create the audit record on its behalf. In the case of an FTP server supporting an EDI channel, this could be as simple as a response to a ping or a file lookup in one of the FTP directories. P1: OTA/XYZ P2: ABC
appB JWBT251-Sweeney March 22, 2010 11:15
Printer Name: Hamilton Appendix B: Service Categories and Types 317
A billing services framework provides enterprise capabilities to capture and maintain utilization data necessary for billing external constituents for utilization or generating charge-backs to internal business unit budgets for internal utilization. A billing services framework should leverage logging and audit services to capture and compile the utilization data needed to calculate the utilization charges. This framework may also include fixed overhead costs and standard rates for charge- back of that overhead. A billing services framework is essential for companies that need to charge in- dividual departments or business units for the cost of the information technology infrastructure and support resources. The stovepipe application model with dedi- cated servers and bounded user populations no longer exists. The cost of a shared portal server or enterprise service bus (ESB) platform will need to be allocated back to the business units that use the portal channel adapter and consume ESB services. Exception processing services are another critical framework within the SOA enterprise architecture framework. In an SOA application, the exception may be thrown by a service in one layer but handled by a service in the same or different layer. Under SOA, exceptions that are common and occur in multiple services may be handled through an additional common service that handles the exception for all the services. Having an exception processing framework prevents every service from having to redundantly code exception handlers and potentially prevents consumers of the service from having to understand and handle the service. This is not to say that consumers will never need to handle exceptions, but the framework provides the capability to handle the exception outside the consumer’s realm if possible. Examples of exception processing services that could be provided by the ex- ception processing framework are presented next. Assume that an order business process submits an order to be created on the legacy order system that will return a confirmation number upon successful creation. The “CreateAnOrder” business ser- vice invoked by the order business process in turn invokes an integration service to create the order. If there is a network or application failure and the legacy order Download 120.98 Kb. Do'stlaringiz bilan baham: 
|