Hi!

SOA brings a new paradigm of business awareness. Along with looking at
the technology, make sure you consider the cross-functional business
processes. Under the hood, SOA is essentially
identify->assemble->deploy cycle, where in you identify common
cross-functional tasks, model them as services, assemble multiple
services (tasks) to achieve a coarse grained functionality (process),
and deploy it. The core focus should be granularity and reusability -
the code can be EJBs, Spring Components or a mainframe sitting
somewhere. This brings in the whole Enterprise Integration scenario,
where in you might end up integrating some legacy systems via messaging
or something similar. Normally, businesses do not prefer "rewrite the
whole thing" idea, so there is always going to be some wrapping.
Speaking of technology, start with very common utilities that can be
reused across applications (like audit/logging/service invocation...)
so that you will have a framework to begin with. Along with identifying
services, focus on message specs (input/output XML schemas), security
etc. Implementing SOA is a pretty big effort, given the
cross-functional and multi-tiered nature of business applications.

Best of luck and do keep us posted!

-cheers,
Manish

I think I better understand what you are looking for now.

To respond to your request, if I understand you correctly. I think the
way to do it is to use an integration tier at the client side. The
integration tier would be responsible for presenting an abstract
interface of the operations the ESB provides which the web app requires.
A tier below the integration tier would be the actual communication
mechanism used, e.g. jms, esb, web services etch.

This would give you a three tiered client (webapp/integration/comm) that
would allow you to create the desired technology mix in the client. E.g.
all tiers could use spring or the webapp could use struts and the other
two tiers could use spring and so on. Features such as transactions is
handled at the communication tier by way of signal from the integration
tier, i.e. implicit in method or by an argument.
Depending on how the communication is designed in the system, you could
possibly use an enterprise message format which travels from the client
integration tier to the service integration tier instead of an explicit
service interface.

This solution, though, is architecture independent, the reason for this
is that I am not a great believer in SOA and ESB. I would love, though,
to hear what you choose to do and how you solve the issues, as there are
not many actually doing SOA in real life.

(Sorry, the following explanation is quite long, but it is not easy to
condense)

In any case, as terms, SOA and ESB, are just "syntactic sugar"/business
terms for the age-old business component model (corba, dcom etc) of the
nineties. Its using the well know concept of service brokering to
present an idea of component/service/utility computing. I don't think
the component model works at a business level, mainly because business
processes are specialised processes for a special case in a business
that management creates to give their business an "competitive edge".

What I mean by this is that any business process/step is usually so
specialised, that it in most cases it can not be made into a general
components (or as termed in SOA: service/utility etc). The principle of
business components is easy to accept, but the reality is not. Any
business process steps requires specialised input/processing/output that
can not easily be generalised and reused in a service chain of other
processes or contexts without adaptation, this making it less generalised.

I will explain in detail how I see it, if I have missed something, I
trust you will share your experience.

For example, lets say you have a telco which has a business process
called "New ADSL customer", which consists of the following simplified
steps

1) gather customer data
2) check existence of customer
   2b) create new customer
3) check credit rating
4) check availability
5) order service personel/date
6) set subscription and details
7) activate subscription in exchange

The general description of the steps in this process seems fair enough
and could possibly make you think it can be turned into components. But
the details of each step, what they require as arguments and what they
produce as output are different for each type of "service" used. What 1)
receives is dependent on the product being bought. 2) might need
different arguments depending on the product or system it need to talk
with, which 1 might not have gathered. what information 2b) requires to
register a new customer depends on the product and 2). There might also
be steps in 2b that have to be performed in the middle of 1 to perform
correctly which are only required by 1 in certain products. 3),4) and 5)
could possibly be components, but it depends. 6) depends on 1 and the
product type. Finally 7) depends on the specific information about the
product type, the type of exchange and so on. So there are a lot of
dependencies on the product which would suggest that you actually need
specialised steps for each product type, which it how its done normally.

Regarding an ESB I don't agree on the need. Any communication can be
performed by exposing any enterprise systems through the systems SOAP
interface. A few operations, in a few systems, will probably be reused
by many systems, but mostly there will be an 1-on-1 integration between
a client and a service. By using SOAP, the communication layer is
independent. And by designing the interfaces as an organic interface
(i.e. an xml document where arguments and operations are specified so
that it can be changed without breaking backwards compatibility or
future expansions), one can change implementations/technologies in the
client or service without the system breaking.

But as I said, I am quite curious as to how you see it an how you choose
to solve it. So please let me know.

tom