>
right now, we're in design talks. the design calls for web
applications to connect to an enterprise service bus. this could
deliver both web service and jms message calls.
with the web framework being the client, it shouldn't really matter.
i'm looking for the nuts and bolts of how these will talk to each
other. i'm assuming you'd have to call from the business or service
layer of your web framework, do a lookup, start the transaction, and
call the service on the ESB.
spring seems to have it's own framework for accessing services. from
what i read
it is transactional. i would simply do a lookup on the ESB, start
spring's transaction, then
pass my web service query. j2ee also allows exposing an ejb as a web
service. i'm not sure how easily this could be rolled to work in the
SOA paradigm. i could also easily just write a stateless session bean
(ejb) and have it access the ESB. it could start off the transaction,
do the lookup on the ESB and pass the query. using spring seems the
most simple.
my last resort is to mimic a "data access object" pattern to create a
"service object
access" pattern. like dao, i would have high level objects for the
general services.
they would do the lookup against the ESB, began a JTA transaction. i
would then have finer grained classes represent the queries which will
be passed to the jms queues or web services.
i wasn't sure if anyone had done any of this before and had best
practices to share for all of us. i'm sure we'll be going through
iterations of trial and testing. i'll gladly share the results.
(except to arne).
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
