We want to integrate lots of services (web services). I want to know the best practice and good design pattern on this front. So, can you please given me some idea or point me to the good links/material on this. Thanks a lot in advance.
Originally posted by Balachandran Vijayarajan: We want to integrate lots of services (web services).
It isn't quite clear what you are trying to accomplish. Web services are often used to integrate heterogeneous systems by virtue of only requiring HTTP and XML tools/libraries. However integrating of the services themselves sounds more like you are trying to
At the most basic level creating composed services often involves manipulating the messages directly in their XML-form rather than their "translated" Java-object form; for example incoming messages of various formats may be processed by XSLT transformations toward a unified form that can be processed by a target web service. If it fits your requirements Apache ODE (Orchestration Director Engine) might be useful.
Thanks a lot for reply. I have not selected better wording I believe. This is my requirement,Having lots of webservice. Need to know the best practice and patterns to follow to the environment better. Like more scalable, performace, maintainable and etc
Originally posted by Balachandran Vijayarajan: This is my requirement,Having lots of webservice.
That is not a requirement. Web services can be part of a solution developed in response to requirements, but they are never a requirement in themselves. Otherwise you simply end up with a whole mess of web services that do not solve any particular problem. And often lots of web services are only a very small part of a solution to a much "larger scale" set of problems.
So what problem are you trying to solve?
Like more scalable, performance, maintainable ..
Scalabilty - ensure that your web services are stateless. That means that the do not store any client or application state. As they are often used in the processing of "long running business transactions" (we are talking about hours, days, possibly weeks) they usually delegate storage of transaction state to their persistence store rather than keeping it in memory - and compensation is preferred over two-phase commit (Your Coffee Shop Doesn�t Use Two-Phase Commit (PDF))
Performance - only use web services for large-grained interactions. For example: only submit an entire purchase order - don't submit it a line-item at a time.
Maintainability - this is where things get complicated. Any web service endpoint exposes an interface - which means that changing the interface will affect both the service and consumer. There is some freedom in XML Schema as you should be able to add new optional elements without problems; however that will only work if your client's SOAP stack will simply ignore elements that it isn't expecting. Often changing the interface requires exposing the new interface on a separate endpoint so that new clients can use it while the old client aren't forced to upgrade; often this make the service more complicated as it has to support multiple web service interfaces.
Often changing the interface requires exposing the new interface on a separate endpoint so that new clients can use it while the old client aren't forced to upgrade; often this make the service more complicated as it has to support multiple web service interfaces.
This is one of the hot topic. Service versioning is starting to loom large on the horizon, so it would be interesting how the companies are approaching towards Web Service versioning without impacting consumer sometimes it could be unknown consumer too.