A key entity in realizing SOA Governance is the Service Intermediary. To understand the importance of its existence, real world scenarios could help in identifying the required capabilities in dealing with Web services/assets. This is required as the service assets can be easily managed across service providers and consuming applications.
Motivation:
1) Service providers would like to dictate service access privileges for Consumers.
2) Make the service assets manageable by providing viewer ship – A taxonomy-based approach could be used for categorization.
3) Changes in service definition needs to be propagated / notified to targeted consumers; changes more specific to service life cycle - Available, Unavailable, Deprecated, Versioned, Suspended (could be merged with unavailable). Also in case of versioning.
4) Design time policies, specific to a consumer/Organization required to enforce assertions during creation
5) Privileges need to be defined for the possible function/operation availabile for a service
6) Roles for a set of privileges
7) Groups having a set of roles
A complete distinction needs to be made between the users of the system.
9) Personalization needs to be done on consumers where new services, which are added to the system, can be showcased to the existing consumer base for them to subscribe.
10) An easy subscription mechanism is required which consumers can subscribe to based on related service interest. When new services are added the consumers can have a glimpse of the new service. If they wish to use the service they can send in a request to the service provider. Involves a subscription life cycle.
11) While defining runtime policies the provisioned services need to be used directly for similar services in policy assertion such as Routing, SLA etc –also filtering of services.
12) When adding a service to the system one would require a WS-I basic profile 1.0 compliance test for the service
Target usage:
Mostly B2B, C2B
WS Intermediary/proxy usage:
High
Domain:
Network based applications
Participants/Actors:
Consumers, Service providers, Applications
Dependency:
Depends on user, role, group, organization, service, WS-Security
Motivation scenario 1 & 2:
At design time a service provider admin can add a service to the system and assign privileges to consumers. A service WSDL URL could be used by the service Provider that is added to a category or taxonomy. Say, Stock Service; under the category of finance. (Note: One could use a UDDI specified taxonomy, for this instance let’s consider a custom taxonomy or a folder/item analogy where folder is the group/domain and item is the service itself).
A service provider would also assign viewer-ship privilege to 0 or more consumers for a particular service.
Viewer-ship
A Consumer application/user could visit our published service page and navigate the folder structure and view the services that are available to them. This again would depend on the kind of privilege the user has. Mostly for consumer application/users it will be view services.
The other purpose of this is to have a clear distinction between the various users of the application as a whole.
Motivation Scenario 3:
Changes to the state and accessibility of a service need to be tightly monitored and the information needs to be made available to a consuming application. The mode by which this would be achieved is more of an implementation matter and could be configuration based. SMTP or SNMP based mechanism could a way by which this could be accomplished. The purpose would be to let the consuming application know the state. In case of change of version in which say the method signature has changed it should be notified so that the consuming application can take preemptive action.
Motivation scenario 5,6,7 and 8
Service Privileges: an imported service (WSDL) can be privileged based on CRUD (Create Read/view, Update and delete) operations, where the Provider Organization Administrator (POA) can give selective privileges to other Provider Organization Users as well as service consuming organizations.
Service Provider Roles: Roles will be critical to the provisioning of services. The main category of roles that would be useful from a provisioning perspective for a Service provider is:
1) POA – Provider Organization Administrator: responsibility of this role is to assign privileges/roles to various other users of the Service Provider Organization and also create users.
2) SI – System Integrator: This role will provide Service access to consumer applications (Note: Consumer applications are users of services, each consumer application can have users associated with them)
3) CA – Consumer Applications: This role will be given to consumers of a particular service consuming organization for a particular Service Provider Organization, in most cases they can view the services.
4) Other roles could be added by the provider organization to suit their purposes.
In a nutshell, there will be two kinds of organizations that would participate in the service life cycle. The Provider Organization and the Consuming Organization. Each of them can have users and participate during the different phases of the service life cycle. The first phase of provisioning would be more focused towards adding an end point (WSDL in most cases) to the system and assigning it to a category. In the second phase these endpoints would be made available to the SI for selectively exposing them to consumers for consumption.
Defining consumer applications/users would be more evident when we introduce Security features. Say for instance we provide a WS-Security capability and allow the client to send encrypted data to our proxy based intermediary. Now to decrypt the data we would require a public key. At the intermediary end the only way to find the public key would be by using the Consumer Application ID to fetch it from the keystore.
Motivation scenario 9,10:
Personalization of services could help consumers to easily access related services or the services that the consumers are interested in. The mechanism by which this can be achieved is to capture service interest area from consumers in terms of service categories. So when a new service is added to the system this could be linked to interested consumer and showcase the new services. When the consumer application/user logs in to the system these new services could be shown to them. If interested then the Consumer Application users can send a subscription request and avail the service. This would certainly have a workflow associated with it – in terms of who will assign service permission, what would be the terms under which this service will be made available etc.
Motivation scenario 12
WS-I Basic Profile test would be an important criteria by which a service being added could be tested for conformance. This would serve two purposes 1) Validate the usability of the service and 2) also serve as an item on the consumer’s checklist as this has wide acceptance.
Gourangi
Recent Comments