FIMS Media SOA Framework - AMWA

More documents

Recommendations

Info

FIMS Media SOA Framework Phase1 (Preliminary)6 Media Service Management[Media services have high availability requirements that must be met by implementations]6.1 Service lifecycleThe FIMS framework includes a service registry, which among other functions manages the lifecycle of services.A lifecycle is a set of states with transitions defined between them. The FIMS standard does not specify how theservice registry shall be implemented, but it rather focuses on the following aspects:• Minimum set of capabilities that a service registry should provide to support the following servicelifecycle states:ooooService deployedService updatedService replacedService decommissioned• Information model for supporting the lifecycle states defined above.6.1.1 DeploymentThe service registry shall support the deployment of a service to the following types of environment:• Development environment• Test environment• Production environmentA service deployed to the development or test environment shall not be discoverable in the productionenvironment. A service can be deployed to one of the environment above (e.g. to the developmentenvironment) and can be promoted to other environments (e.g. to the test environment).A service is deployed when the new service or service instance is registered in the service registry. Theinformation provided in the registration process includes:• Service interfaces and imported schemas• Service endpoint information (might be imported from the WSDL service binding information)• Service description metadata (as described in xxxx)• Service policies• SLA/M-SLA contracts.Details on the information provided for registering the service are provided in section xxx. Once the service isregistered in the service registry, it becomes available for discovery and invocation.6.1.2 DecommissioningDecommissioning services from the production environment is supported by the service registry, which allowsthe system administrators to first deprecate existing implementations so that potential new consumers do notsee the specific implementation. Administrators can then use reporting and impact analysis capabilities in theservice registry to allow the operations team to identify remaining service version consumers and ensure thatthey migrate onto the correct alternative version. After all of the consumers have been migrated, the old serviceversion can be retired from use and remove it from the deployment environment.6.1.3 Replacement/UpgradeA service can be updated or replaced by updating the service information in the service registry. Theinformation to be updated might include:Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 14 of 89
FIMS Media SOA Framework Phase1 (Preliminary)• Service interfaces and imported schemas [for new versions of the specifications]• Service endpoint information• Service description metadata• Service policies• SLA/M-SLA contracts.The service interfaces and schemas are standardized in this FIMS proposal and should not require update if aservice is replaced by one providing the same business functionality with the same version of the interface.However, as FIMS specifications evolve, new versions of the interface may be published [see 6.2.4] and mayneed to be updated in the registry. As service versions are superseded by new implementations, which deliverthe same required business capability, the service governance lifecycle should allow specific versions to bedeprecated and, ultimately, retired6.1.4 Backward compatibilityBackward compatibility issues might arise for a variety of scenarios. This version of the specification focus ontwo key scenarios:• There is a new version of the FIMS specifications for the service interface.• A service implementation has been modified for adding or removing features (such as operations).6.1.4.1 New Version of the Service InterfaceWeb Services versioning approaches are described in detail in [REF1]. To summarize those findings, there aretwo key approaches to service evolution and versioning:• Compatible evolution: In compatible evolution, designers are expected to limit changes to those thatare either backward or forward compatible, or both. A change is backward compatible when thereceiver behaves correctly if it receives a message in an older version of the interaction language. Achange is forward compatible when the receiver behaves correctly if it receives a message in an newerversion of the interaction language.• Big bang: A change to the WSDL document implies a change to the document's namespace, a changeto the interface implies a new interface namespace and a change to the message contents iscommunicated using a new message namespace.• Combined approach: the approaches above are combined together. For example, the namespace couldbe changed when message descriptions are changed, but the namespace could stay the same whennew operations are added.With a compatible change the service need only support the latest version of a service. A client may continue touse a service adjusting to new version of the interface description at a time of its choosing. With anincompatible change, the client receives a new version of the interface description and is expected to adjust tothe new interface before old interface is terminated. Either the service will need to continue to support bothversions of the interface during the hand over period, or the service and the clients are coordinated to changeat the same time. An alternative is for the client to continue until it encounters an error, at which point it usesthe new version of the interface. There is currently not a standardized or recommended approach, but rather aset of best practices.The current FIMS specification recommends the following guidelines, based on current best practices and[REF1]:• Interface documents and schemas shall have a version with a major and minor number.• A compatible change shall be at least backward compatible.• If a change is compatible, the minor number of the version shall change. If a change is incompatible,the major number of the version shall change.Private committee documentWorking Draft for review by FIMS Rev v1, Nov-16-2010 Page 15 of 89
Page 1 and 2: FIMS Media SOA FrameworkAMWA Specif
Page 3 and 4: FIMS Media SOA Framework Phase1 (Pr
Page 13: FIMS Media SOA Framework Phase1 (Pr
Page 65 and 66:
FIMS Media SOA Framework Phase1 (Pr
Page 67 and 68:
Page 69 and 70:
Page 71 and 72:
Page 73 and 74:
Page 75 and 76:
Page 77 and 78:
Page 79 and 80:
Page 81 and 82:
Page 83 and 84:
Page 85 and 86:
Page 87 and 88:
Page 89:
show all

FIMS Media SOA Framework - AMWA

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?