cancel
Showing results for 
Search instead for 
Did you mean: 

How to handle changing requiremnts in SOA

Former Member
0 Kudos

Hi all ,

we have implemented a few services with SOA approach. Now as we are starting new projects and functionality we are required to change these services just a little bit , what is the optimum approach in handling changing requirements?

for example : one particular service is having to be tweaked and a few fields added with each new project, should we create a new service with this extra fields or should we amend the existing service each time. Amending the existing service will impact all the systems consuming the old service . Is there an efficient way to handle this ?

Drop in your views on this

Regards

Sudheer

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

In addition to what Krishna and Trevor said.

Dont change existing service as service contract between service provider and consumer should be stable.

Enhancement: Only if there is dependency between current service and new functionality you want.

New Service: If you don't want to create dependency between services i.e. changing one service should not affect functioanlity of other.

Hope it helps you.

Regards,

Gourav

Former Member
0 Kudos

Great Guys , Thanks for highlighting some key principles of SOA. will take on board all of your suggestions.

cheers

Former Member
0 Kudos

I'll add my 2 cents too Sudheer...

I suppose your versioning strategy should take into account your particular circumstances, impact analysis, ESB architecture etc...

In our case it makes sense to version the service operations because we have some consumers that want to stay on the older version & other that want to move with the changing versions...

We've noticed that SAP, with the standard delivered enterprise services also version step the service operations so you esentially have 2 service contracts but one that caters for additional fields/functionality. The consumer uses the service operation that they prefer.

The other possibility, if you are in a position to make the new fields 'optional' then you could do that without impacting all the consumers, the consumers that have the additional info to pass in the request can do so & the other consumers can carry on business as usual.

Then you could also version step the entire service, that would entail making use of a new software component version but this would entail new endpoints & depending on your architecture it could impact all your consumers. If you're using an integrated ESB architecture, your consumers would have one endpoint & the ESB would route the request to the relevant service version.

So you could minise impact on the consumers & develop a good versioning strategy depending on what your current situation is.

Regards, Trevor

moorthy
Active Contributor
0 Kudos

Hi ,

My 2 cents:

Generally as per the Design time governance best practices it needs to be handled in a Enhancement Mode i.e change the existing the Service to cater the new requirements. However it depends on the impact of those added fields in other consumers and criticality + best fit of those additional fields in the existing Service.

If you see, the additional requirement is very specific and there is no wider importance or reusability , then it is prefer to create a specific service to cater this. Otherwise it is good practice to have Custom Service which operates on one Business Object based on the Business scenarios.

If addition of fields represents a new functionality, then proceed with new Service, else it is prefer to go with Enhancement or Extend mode of the existing Service.

Hope it helps,

Regards, Moorthy