If you wanted to write the code for an enterprise service bus, you would need to deeply understand distributed computing, messaging, concepts of service-oriented analysis, service-oriented design, service-oriented architecture, service-oriented infrastructure, web services and software security.
Implementations exist that you can use, for example IBM's MQSeries.
MQ Series is not an enterprise service bus. It is software for messaging and queuing. MQ Series can be used to build a proprietary enterprise service bus. However, there is much more to an enterprise service bus than just messaging and queuing.
OpenESB is an implementation of an enterprise service bus.
Working with ESBs isn't really that hard anymore. With ESBs such as Mule and ServiceMix working with ESBs has become really simple. If you want custom functionality both these ESBs support writing services in standard java.
If you've already got lots of legacy systems (opensource) ESBs provide lots of connectivity options (HTTP / JMS / Mail / etc) to connect to those ESBs.
Some ESBs though are easier to work with then others. OpenESB was already mentioned, and this a JBI compliant ESB (just as ServiceMix). JBI is a JCP standard which defines how integration components communicate with each other. But working with JBI based ESBs however does require some knowledge of how JBI works. Mule on the other hand use a more 'pragmatic' or proprietary approach, which makes it very easy to work with.
How does an application find services? In one type of service-oriented design, a way to find services is to connect to a service bus. All of the services in an enterprise can be found on the bus. When an application finds the services, it can then use them. The enterprise service bus then provides the mechanism to locate services.
Service-oriented information systems can have a service bus, or they can use some other method of locating services.
Usually when working with larger systems or creating an enterprise wide service architecture, you'll also have some sort of a service registry where clients can search for services.
With the found information they can then invoke the service using it's definition. An added advantage of this is that it provides a nice point to start with the governance of service. For instance define when a service is available, what service levels are supported, how you're billed for using this service etc.
But SOA governance is a whole other discussion, a very interesting one though.
Hi, could you please put more highlight on SOA governance and how registry are implemented ?
i mean is this the case that if i put my wsdl file in registry and put metadata about it and other service just search mine webservice through key words ... so other can dynamically search my service and genarate stubs to communicate to my webservice or the calling service has to manually write some part of the code and mannually generate subs using axis or some other apis ? and then call it ?
how service in registory can be dynmically invoded withuout any human intervention ?
how the security could be implemented in that case ?
can registry is only for webservise or other ESB also ??
... and please put some hightlight about SOA governance ? would love to know in detail about SOA governance ? how it is implemented and some practicle case study link/reference so it can be understood very clearly
I was checking out some esb's as well and i found this esb be to be quite useful as it is based on the apache synapse esb which is very fast and light weight but also gives a really good admin UI which allows users to easily configue the ESB according to their needs...
if who i am is what i have, and what i have is lost, then who am i?<br /> <br />SCJP 5.0<br />SCWCD 1.4<br />SCBCD preparing