Thread: Service Oriented Architecture

Hy guys, I'm so sorry if I ask an very very ordinary question, but I just learn about SOA, and i found that we use XML to provide Web Service, one thing i confused about is, what make the SOA application different from Web application that use servlet and JSP?

I recommend you spend more time learning about SOA. For example, the current trend is moving towards REST and JSON, away from SOAP and XML.

One common approach is the Web Application presents a JSP-based GUI. Users interact with Java Servlets. The Web application maintains the application database.

When there are other applications that need to interact with your database, the best practice is to NOT give them direct access to your database. Why? Say you find bad data on your database. Did it come from a bug in your application or the others? This complicates matters and reduces productivity.

This is an anti-pattern known as "coupling at the database".

It's best that each application "owns" it's own database and controls all access to it. When other applications need to perform CRUD operations on your database, you work with them to design the API's that meet their requirements, and you create services they call, keeping your database under your control.

You can even leverage existing logic in your application to be more DRY.

Keep in mind services are slow, so strive to accomplish these application-to-application interactions with a minimum number of service calls (optimally one.)

There are many variations of course. One approach is to have the front end browser call services instead of Servlets. There are cases when this justifiable, but it adds complexity.

Any time you discuss adding complexity you need to do the math. Compare what you are hoping to gain with the loss of productivity. If the benefit is not significantly greater, don't do it. Favor simplicity.

Another current industry best practice is never allow "Future Proofing" (adding features you don't immediately need), nor "Gold Plating" (features you'd like to add, such as "for appearance sake" that have not been requested by those footing the bill.)

Many folks are tempted by future proofing, but Agile methods recommend avoiding future proofing altogether. As far as I can tell this is well supported by my experience and by the industry leaders I follow, like Martin Fowler, Venkat Subramaniam, etc.

Thanks gr8ful it's very helpful.I am new in java programming and i got a lot of information from it.