1

We are in the middle of a strange situation. We and a partner firm have to put up a web portal. They have a lot of functionality already done on their other portal and we are the managing firm on the project. But there are also some new development needed on their side which is designed by us. Strange thing is, we are going to do the GUI on the project and they will provide us some web services to gather data.

They are using .NET and we will be using PHP for the frontend project.

So what do you think that the best approach is to avoid communication and integration problems? For example

  1. We provide them with just the view files and they do the rest all by themselves?
  2. We develop a PHP project where we gather the required data using SOAP/REST web services?

Thanks in advance guys.

Improve this question

2 Answers 2

Reset to default
1

This depends on level of coupling and clarity of abstraction between the GUI and web-service.

Following conditions at architectural level are must to make things work :

  1. The abstractions of data elements must be clearly well defined. Also, if the data exchange is closer to the schema of DB on the web service side, it would be easier. (if applicable).
  2. The flow of message exchanges must be very clearly articulated. the more stateless it is, the better it is.
  3. Web-service should have NO knowledge of the how the GUI is using the data, and there should be no specific logic in the implementation of webservice. For example, depending on the current view or last query, web-service should not be doing computation.
  4. It is best that sessions of web front-end are kept away from service or restricted; mechanisms like authentication should either be based on independent brokers (like OpenID) or it is shielded between User to GUI vs. GUI to Web service.
  5. Business rules are well documented and agreed upon.
  6. Application of encryption of messages if applicable.

In general try to design web service API such that at least two different type of GUI might need to use it without having to run in inconsistent behavior. (this helps you to make conscious notice of GUI specific coupling).

The above are most basic rules for any to any platform. Apart from this, since you have mentioned, that this is a marriage between .NET and PHP, i would try to play safe and communicate only using pure XML. So i guess REST or even better plain old XML RPC might just work much better than SOAP. It is not that SOAP cannot work - but i guess it wont be without the trouble compared to "plain XML" communication.

Dipan.

Improve this answer
1

I think you over simplified the descriptions of your ideas and thus, it is hard for me to understand what you actually meant by them. That being said, this is how I seem this all coming together.

  • You draft a communication api for their service. What the actual transfer protocol is less important, focus on what the calls are and the data structures needed.
  • Present the api to your partner. Come to an agreement and finalize the api and transfer protocol.
  • They are in charge of implementing the api and you are in charge of all the display work to present the data.

The benefit of the clearly defined api is that you can do your work before they deliver the service implementation. You can write tests that utilize a mock implementation to ensure that you are handling data correctly based on the defined api.

There are always going to be something that makes integration more interesting than you had hoped, but the clear division line and defined ways to cross that line allow you develop and test your code in an attempt to minimize the issues with integration.

Improve this answer
1
  • we have already put out a api document to our partner, we are waiting for their answer. But in terms of mocking up the API calls, we are trying to figure out if synchronized/asynchronized data transfer would make some problems in mockup. Commented Nov 4, 2011 at 7:37

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.