Converting object from one format to another Java ( Design pattern )

Question

I am building a service that depends on another service. A typical Service oriented architecture. The service i am dependent on exposes some API and data types. I am confused should i be converting the object types exposed by that service into specific objects which my service understands. I do expect their service to change with time as these are two different services. I have two options:

• Directly use those data types in my service and pass those in methods.
• Transform those into specific data types which only my service understands. ( objects will look exactly same if i do this with 0 changes ).

I tried to answer these questions but still could not make the final call. I need help in making this decision.

Why should I have encapsulated/transformed types ?

• To prevent building every time they build changes in the service.
• To prevent widespread changes ( adapter pattern ) : Changes to the wire format will lead me to change only the encapsulating classes.

Why should I not have the changes for the types encapsulated ?

• The classes will look exactly same as the wire format classes. ( Useless effort to maintain extra classes )

As i understand the impact will be same if i go with either approach. Help ?

Answer 1

This is sort of opinion based question, so my opinion is, you should make your own data-types to let your piece of code understand what should be contained in which variable.

I think of services as a data provider, which accepts certain request and fulfill our needs and in return may give us some data. I think role of service is just providing services to client.

It should be responsiblity of client to accept the data returned by service and store them in certain data-structure as there can be n different clients for single service and they can have n different requirements which may lead them to design client specific data-structure to contain data.

Also, as you said client service is subject to change over the period of time, then if you make your own data-structure, then you will need to make change in one single place, and rest of your code will be safe.

Answer 2

I am no architect or SOA specialist, so excuse me if I am saying anything stupid :-)

But I really think the way here is to keep your services simple.

In your shoes, I'd just directly use the existent API. I would not spent any time wrapping or adapting the methods into another API. Your second service (that uses the existent first service) business logic should take care of this convertion, IMO, except if you're being forced to do something that is really expensive with the existent API.

Remember that services are mutable. They're software. They have bugs, business logic changes as time goes and you'll have to change the API and sometimes you'll have to keep older methods compatible for other service consumers. You probably don't want to maintain two APIs that provide the same information without any good practical reason. Not for twice the maintenance work.

Creating another API just to adapt the data format sounds to me a little like that old "DTOs are evil" flame war. And I think a very few people write about the advantages of using DTO nowadays :-)