Page 1 of 1

Building a Application with WebServices

Posted: Sun Oct 16, 2005 3:05 pm
by Hardcore4Life
Hi!

At the moment i develop a really big Application in a nice Java Client,
The next Step is to develop an 'Engine' that do some really cool things automatically,
so the user only set up his settings, save it in a database and the cronjobs do all the stuff for him
while he sleeps or make vacations in the sun ;)

So thats wat the plan (and the managers) say!

Know i think about the architecture and a really important question is:
"Did i make the sytsem in the 'normal' OOP style? Or should i make it SOA like and pack all the stuff in Services?"

So i'd like to know all the important things you know about developing a app full of services!

For example:
- Whats the advantages and the disadvantages?
- What things can i do to get better performance?
- What about own objects and services?
- nuSOAP or PHP SOAP?
- Caching?
- Security?
- And all the Stuff you know about this all ;)

Before i forget: Only the cronjobs call the webservices - so no user has direct contact with it!

Thanks a lot!

Re: Building a Application with WebServices

Posted: Mon Oct 17, 2005 8:27 am
by Buddha443556
Hardcore4Life wrote:Know i think about the architecture and a really important question is:
"Did i make the system in the 'normal' OOP style? Or should i make it SOA like and pack all the stuff in Services?"
My interest in SOA has been purely academic so far, so take what I say with a grain salt. However, I really don't see OOP and SOA as mutually exclusive. There's no reason OOP can't be used to implement SOA. SOA is an architecture and isn't concerned with what language or methodology you use to implement it.

You probably need to be asking other questions to determine if SOA is something you want to implement. Do you see a need for these services beyond the cron client? The cron client is known, it's the unknown clients that SOA actually addresses. Are there other components in the enterprise that might provide services? How will clients discover these services? How will the service be invoked across a network? Transport type? Payload format? There are many more questions which need enterprise wide consideration.
Whats the advantages and the disadvantages?
Reuse is one advantage and maybe disadvantage too. Take for example authentication. Instead of implementing authentication for each project, SOA allows each project to use the same authentication service. Of course, if that authentication service has a vulnerability then so does every project that subscribes to the service. However, you only need to fix the one implementation of the service which improves maintainability.
What things can i do to get better performance?
Performance would depend mostly on the network. Your cron client might not have a problem as it would probably be part of the same system and could even bypass the published interface. However, network performance could be a concern for other unknown clients. You could implement a stateful service to cut down on the amount of data needed to be passed back and forth however scalability may suffer as a result. SOA adds a layer of complexity. Complexity never helps performance.

Posted: Tue Oct 18, 2005 8:29 am
by Hardcore4Life
So first of all thanks for your post ;)

Hmm - as i said before - we develop a Java Client that interacts with other 3rd Party WebServices
and know the 'Engine' must also consume these 3rd Party WebServices and work with it.

So - everyone can see - the Java Client works with that Services and our Engine ALSO works with the SAME services ...

The idea:
If our Engine is also developed in/with services our JavaClient can call OUR API and if the 3rd Party API changes only
the PHP Code must be updated from us and all things works fine ...

For now thats the only plus we see in the Services but maybe at one day there comes another advantage fo that
and then i am prepared ;)

What did you think - is this a stupid idea?

Posted: Tue Oct 18, 2005 9:27 am
by Buddha443556
Hardcore4Life wrote:The idea:
If our Engine is also developed in/with services our JavaClient can call OUR API and if the 3rd Party API changes only
the PHP Code must be updated from us and all things works fine ...

For now thats the only plus we see in the Services but maybe at one day there comes another advantage fo that
and then i am prepared ;)

What did you think - is this a stupid idea?
Hope it's not a crazy idea I've been having similiar ideas of my own. :oops:

Only problem I see is if "OUR API" changes then the JavaClient may need to be updated. Does the JavaClient do anything besides serve up the clients UI? Can it be replace by a web browser? The less code outside your control the easier maintaining it will be. Using something like Java Web Start would eliminate this problem all together.