The Service Life Cycle

The service life cycle is a very important topic when you start considering the governance of all the services developed across the enterprise and SOA landscape. One of the dilemmas is to define on how long a service should be maintained and given support and when should it should be deprecated and retired.

The services can be grouped as a portfolio of services available in an enterprise. Any service defined or designed in the enterprise will need to be published to the portfolio of services.

•        Before you define a service make sure that the service doesn’t exist.

•        Define stage - To define a service, identify the purpose of the service, appropriate name and design the service  

•        Development stage - Once the service design is approved it moves to the development stage

•        Release stage – Once the development /testing is completed the service is released/published to the consumer

•        Upgrade stage - As the time passes, initial release may not be enough to cater to all the consumer requirements, so will need an upgrade to the service. When the upgrade is published, the older service becomes deprecated. A deprecated service will be in production and available for consumers use for a pre-defined time frame, before they need to upgrade to the new service.  

•        Retirement stage - A retired service is no longer available to consumers and is removed from the enterprise.

Life cycle of the service can be tracked as metadata in a service registry or as part of the header information in the SOAP message. For example service in the released stage should provide the date of its release and deprecated service should record the planned date of its retirement. To maintain the lifecycle we can always leverage capabilities of Enterprise service Repositories and Registries.

Upgrade options

1.       Service URL will have the version number so that it will be clean and easy for deprecating the previous versions and can track the number of cycles of evolution. The consumers will need to change the service url when they have to migrate to new version.

2.       The other mechanism is to add a user header with version mentioned in it, and the Router will need to decode the version and route it to the appropriate service implementation. No change in URL for consuming the new service, but the version number in header only gets modified.

I somehow like the first option because it’s easy for maintaining the services and deprecating them. Anyway to use newer version means the consumer is getting additional functionalities for which anyway they need to make changes. So the URL change can be clubbed in with that, for a consumer it’s not mandatory to upgrade to new service, but the constant change in today’s environment is change ,so you always need to change and move on to new things. Migration can always be planned and worked out as enough time would be given to consumers to upgrade their system to move on to new service.

OSB Dependency/Process flow diagram

Really nice plugin for Eclipse to generate the process dependencies and process flow diagram between proxies and business services, different artifacts like xsd’s,wsdls,xqueries etc.
Thanks to the blog -http://blog.grummt.org/?page_id=33

Restful Gateway Architecture in OSB

In one of my customer’s environment I was reviewing the existing OSB processes. One of their main concerns was Security, so they had implemented security mechanism in all the processes. As you know for SOAP services the OWSM policy feature can be leveraged to embed out of the box security implementations or else for custom implementations use custom OWSM policy and attach it to the process. The environment the customer was working on was 11.1.1.5 where only policies for SOAP services were supported by OWSM. Most of the OSB proxy services were RESTful in nature and all were having the security code scattered all over. That’s when I started looking at reusable and repeating functionalities/steps that need to be built into every service flow. I was able to find lot of repeating steps that had to be done in almost all the flows. As part of refactoring and redesigning I was looking at the Gateway architecture where the request comes in through the Gateway request pipeline and reply through the response pipeline.

As per the new flow we will be clubbing all the common calls into a gateway and internally routing the requests to different projects.

There will be a registry(XML file) which will be having details of all the exposed services in REST. It can be GET  or POST.

The registry will decide on routing the different services based on relative URI

https://<hostname>/GEOGateway/Employee/requestAddress?ID=121

The Gateway will use Employee/requestAddress to figure out which Project and which proxy service to invoke.

The rest of the query string à ID=121 will be passed to the respective proxy services.

Advantages

• Standardization of all the exposed URLs.
•     Request Validation happens in the gateway, only if it is successful it will be routed. A new project developer should only develop the flow, not worry about validation, test it completely then plug it in to gateway.
•   Easy to add/modify new security mechanism.
•   Enrichment/manipulation of request data like populating custom headers which can be useful in tracking the request flow as well as error handling.
•   Response can be converted/transformed from XML to JSON/or any other consumer specific format in response pipeline of Gateway. So tomorrow they want to use a different format we can have it added here instead of doing it in all processes
•  Gateway can also be leveraged to send back properly formatted Error Messages in case of errors suppressing the error stack trace and transforming to consumer understandable error messages.
•  Reduces development time for individual services.
•   Ease of testing

Impacts

• The exposed URLS will change so existing users will be affected.
•   No impact if this is taken care at design time at the beginning of the project.

Downside

If the gateway is down all services will be inaccessible. Central point of failure.

                Not a valid case since

•  the OSB will be always up and running
• Any changes to the Gateway will be tested in lower environments before promoting to PROD.

Implementation

        On the implementation side, all the proxies other than gateway need to be changed to local from http. More on how to handle the new custom headers

References:

http://www.oracle.com/technetwork/articles/soa/architecting-restful-services-083025.html

Response based on Service Types in OSB

Restful services can be implemented using either Proxy type- Any XML Service or Messaging Service types.

·         Messaging Service - to create a service that can receive messages of one data type and respond with messages of a different data type. These exchanges can be either request/response or one-way.

·         Any XML Service - to create an XML service that does not have an explicitly defined, concrete interface.

There is a difference in the way the responses are handled in each case. It’s interesting to see how the response looks like if we add a proxy layer before the existing proxies. I was implementing the Gateway approach where all existing proxies need to be plugged in into the Gateway proxy. In Gateway I am converting the response to either JSON or pass through XML based on the response format requested by the consumer.
Messaging Service response

<soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<![CDATA[<GetStatusResponseMsg xmlns="http://geo.com/v1.0">

 <GetStatusResponse xmlns="http://geo.com/test/v1.0">

<ResponseStatus xmlns="http://geo.com/status">PENDING</ResponseStatus>

</ GetStatusResponse >

</ GetStatusResponseMsg >]]>

</soapenv:Body>>

In case your proxy is Messaging service based then the response will be encapsulated in the CDATA tag. You will need to use fn-bea:inlinedXML($body) to fetch the XML from the response body.
Any XML Service response

<soapenv:Body xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

  <GetStatusResponseMsg xmlns="http://geo.com/v1.0">

 <GetStatusResponse xmlns="http://geo.com/test/v1.0">

<ResponseStatus xmlns="http://geo.com/status">PENDING</ResponseStatus>

</ GetStatusResponse >

</ GetStatusResponseMsg>

</soapenv:Body>>

In case of this approach the response will be in proper XML format without any CDATA encoding.

Service Versioning in OSB

             I was looking at different ways in which we can version the OSB services for my customer. It is a dilemma for all when you get requests for OSB changes due to system standardization like change in the proxy URLS to meet new standards/new functionalities where signatures will change of the exposed services. This issue can arise in any enterprise because when you start of initially without properly architecting the SOA services, not laying down proper standards and guidelines and. Going forward, there will be huge increase in services and how to manage all these services and consumers of these services will be always painstaking. In this article I will put down some points on the service versioning that can be done in OSB.

Backward Compatible changes

The types of changes that are backwards compatible are:

1.       Adding  new XML schema types to WSDL document that doesn’t affect existing schema types

2.       Adding new operations to an existing/new port type in WSDL document. These are basically new functionalities so will not affect existing consumers.

Not Backward Compatible changes

1.       Altering/Removing an operation that is currently consumed.

2.       Modifying the structure/parameters of existing data types

Versioning

All the artifacts need to be versioned at

1.       Namespaces - Unique namespaces to define the new version, usually implemented by mentioning version number.

2.       Folder structure - Separate folders for storing artifacts and folder name mentioning version.

On a high level I am listing the available options

         

Option1 :

If the consumer need not be affected and the new service is backward compatible, then we can deprecate the version1.0 and move on to the new version by changing the proxy service

Option2 :

If the consumer need not be affected and if the new service is not backward compatible, then its always better to maintain different versions of proxy service and have new consumers consume the new Version. When the old consumer is ready to upgrade and move to new version we can deprecate the v1.0 and shutdown the proxy service.

Option3:

This is scenario where there are signature changes and new functionalities required by consumer can be provided only  by modifying the signature then the only option is to work together with consumers and get the new version out which will include changes at consumer as well as provider. Its always better to number the releases so that you can track the service versions and easily identify references to deprecated older versions

I prefer the Option 2 it’s more easy and clean and doesn’t affect existing consumers. Option1 and Option3 are quite similar except that in Option3 the consumer is affected due to the endpoint change and consumer is aware about the version of the Service it’s consuming.

References :-

http://www.infoq.com/articles/contract-versioning-comp2

http://www.ibm.com/developerworks/webservices/library/ws-version/

http://rogervdkimmenade.blogspot.com/2009/09/osb-10gr3-service-versioning.html