Brian Cochran and Eric Stevens own and operate Atlanta CS, a software consulting firm specializing in ESB technology. They have spent the last year and a half defining and deploying ESBs in grid computing environments. Their ESB deployments have fulfilled very high transaction volumes and the integration of 100's of disparate technologies ranging from various legacy enterprise systems to millions of embedded devices.
Prior to founding Atlanta CS, Brian's experience as a Lead Architect found him creating high volume transactional systems and analytics products now deployed at several fortune 100 companies in the insurance and financial services industry. Brian holds a BS in computer science from Georgia Tech with Highest Honors.
Eric Stevens has extensive experience in software architecture and software products in the financial services and insurance industries. Mr. Stevens has led numerous projects involving frameworks, scheduling systems, analytical systems, and site management systems. Mr. Stevens is an Honors graduate of the Georgia Institute of Technology.
http://www.atlantacs.com
Tuesday, May 23, 2006
Developing in an Enterprise Service Bus
There is a lot of buzz about SOA and ESB these days, but what does it mean to actually implement on one? We will answer questions like
What is an ESB?
Where and why would someone use one?
What tools are available for working with an ESB?
How to use and implement various core ESB concepts such as routers, transformers, and messaging connectors?
ESB's vendors are promising easy integration and reuse by providing frameworks for implementing Service Oriented Architectures. But many vendors have clouded the principals and patterns needed by the actual developer with a lot of buzzwords and fluff.
That said, SOA does seem to be gaining traction. IT organizations are looking for more reuse of their applications and better agility in responding to changing business needs. If adopted, the applications we build may be required to plug in to the corporate ESB. As developers we need to know how to partition our applications into functional services that can be used and reused by external applications. We also need to know how to find and reuse existing services so we can deliver more quickly.
There are many patterns and tools found in ESB frameworks which can make a developer's life much easier. These frameworks provide the tools to handle many common problems such as message routing and message transformation. It is often the case that a standard POJO can be exposed to over a dozen different messaging technologies ranging from Web Services to email to flat file simply by making configuration changes within the ESB. For existing applications, developers can use the frameworks to expose existing components such as EJBs as services in the ESB using simple configuration.
Although popular, application integration is not the only application of ESBs. These services based frameworks are also being applied in the areas of grid computing, networking, and as simple messing layer abstractions inside applications.
ESBs have their challenges. Services often have asynchronous interfaces and this mode of development can sometimes be confusing. It is also difficult to manage the configuration in an ESB that covers many different applications. It is not uncommon for entire applications (or versions of the applications) to come and go as services participating in the ESB.
What is an ESB?
Where and why would someone use one?
What tools are available for working with an ESB?
How to use and implement various core ESB concepts such as routers, transformers, and messaging connectors?
ESB's vendors are promising easy integration and reuse by providing frameworks for implementing Service Oriented Architectures. But many vendors have clouded the principals and patterns needed by the actual developer with a lot of buzzwords and fluff.
That said, SOA does seem to be gaining traction. IT organizations are looking for more reuse of their applications and better agility in responding to changing business needs. If adopted, the applications we build may be required to plug in to the corporate ESB. As developers we need to know how to partition our applications into functional services that can be used and reused by external applications. We also need to know how to find and reuse existing services so we can deliver more quickly.
There are many patterns and tools found in ESB frameworks which can make a developer's life much easier. These frameworks provide the tools to handle many common problems such as message routing and message transformation. It is often the case that a standard POJO can be exposed to over a dozen different messaging technologies ranging from Web Services to email to flat file simply by making configuration changes within the ESB. For existing applications, developers can use the frameworks to expose existing components such as EJBs as services in the ESB using simple configuration.
Although popular, application integration is not the only application of ESBs. These services based frameworks are also being applied in the areas of grid computing, networking, and as simple messing layer abstractions inside applications.
ESBs have their challenges. Services often have asynchronous interfaces and this mode of development can sometimes be confusing. It is also difficult to manage the configuration in an ESB that covers many different applications. It is not uncommon for entire applications (or versions of the applications) to come and go as services participating in the ESB.
Subscribe to:
Posts (Atom)