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.
Friday, March 03, 2006
AJAX, SOA, and the end of the Model 2 MVC
It appears that AJAX introduces the opportunity to deprecate many of the MVC (Model 2) frameworks that exist today in place of direct communication from the Web Browser to the ESB. I confirmed many of these assumptions recently when I integrated an AJAX enabled Ruby on Rails web application with an ESB backend based on Mule. While integrating these apps it appeared that much of the development seemed as logically implemented on the Web Browser client as the server. What lies ahead for Web Application frameworks? Is the quest for JSP 2.0, and the next JSF with AJAX support misguided?
Consider the following.
Asynchronous behavior is desirable on a user interface. In fact, traditional web interfaces have suffered from the lack of asynchronous behavior in the form of weak usability when compared with thick clients.
Anyone who has implemented a system based on an ESB discovers quickly that there is a philosophical difference between developing a synchronous application versus an asynchronous service. Moreover, the "problems" that immediately arise with integrating an asynchronous service with the web user interface, seem to evaporate when AJAX enters. Programs are often written with many synchronous assumptions. In fact, synchronous behavior in the physical world is not nearly as common as one might think. People rely on context when they communicate, not correlation id's. Such context can often be modeled with workflow engine contextes instead of relying on correlation at the thread level. Workflow engine's such as jBPM, OSWorkflow, and others make use of the application's ability to establish context.
So what does all this mean? SOA architects model documents asynchronously flowing from one service to another. AJAX models the asynchronous exchange of XML content (documents) to and from the web browser. One might deduce that standards such as REST, RDF, and AJAX (indeed most of Web 2.0) suggest that the web browser's interaction with the server is merely another component participating in the SOA.
If this philosophy is adopted, what does it mean for our beloved MVC container architecture? Most Java MVC frameworks are fairly synchronous by nature. In addition, some of the most valuable features of these frameworks are their validation and layout frameworks. I enjoy struts tiles. I enjoy struts validator. But when combined with AJAX, I find them less useful. The "tiles" like behavior is delegated to the client using div's, AJAX, and javascript. And the validation framework seems as if it can be fairly easily implemented on the client. Not to mention that any web services developer has fairly rich validation frameworks available with XML Schemas. Admittedly this area may be a little short though I might not be as up to speed with the Web Services, Web Client validation integration mechanisms as I should be.
Ultimately, is the answer to the ultimate server web framework to not have one at all? Time will tell.
In the mean time there are a few efforts I am keeping my eyes on in tracking these concepts.
I am anxious to hear what others think.
Humbly,
Brian Cochran
Consider the following.
Asynchronous behavior is desirable on a user interface. In fact, traditional web interfaces have suffered from the lack of asynchronous behavior in the form of weak usability when compared with thick clients.
Anyone who has implemented a system based on an ESB discovers quickly that there is a philosophical difference between developing a synchronous application versus an asynchronous service. Moreover, the "problems" that immediately arise with integrating an asynchronous service with the web user interface, seem to evaporate when AJAX enters. Programs are often written with many synchronous assumptions. In fact, synchronous behavior in the physical world is not nearly as common as one might think. People rely on context when they communicate, not correlation id's. Such context can often be modeled with workflow engine contextes instead of relying on correlation at the thread level. Workflow engine's such as jBPM, OSWorkflow, and others make use of the application's ability to establish context.
So what does all this mean? SOA architects model documents asynchronously flowing from one service to another. AJAX models the asynchronous exchange of XML content (documents) to and from the web browser. One might deduce that standards such as REST, RDF, and AJAX (indeed most of Web 2.0) suggest that the web browser's interaction with the server is merely another component participating in the SOA.
If this philosophy is adopted, what does it mean for our beloved MVC container architecture? Most Java MVC frameworks are fairly synchronous by nature. In addition, some of the most valuable features of these frameworks are their validation and layout frameworks. I enjoy struts tiles. I enjoy struts validator. But when combined with AJAX, I find them less useful. The "tiles" like behavior is delegated to the client using div's, AJAX, and javascript. And the validation framework seems as if it can be fairly easily implemented on the client. Not to mention that any web services developer has fairly rich validation frameworks available with XML Schemas. Admittedly this area may be a little short though I might not be as up to speed with the Web Services, Web Client validation integration mechanisms as I should be.
Ultimately, is the answer to the ultimate server web framework to not have one at all? Time will tell.
In the mean time there are a few efforts I am keeping my eyes on in tracking these concepts.
- ws-wsajax is an IBM project that seems to be an Javascript AJAX SOAP client.
- REST provides an interesting possibility toward simplifying the Browser, Web Services Mechanisms.
- Mule provides a popular and very interoperable ESB implementation.
I am anxious to hear what others think.
Humbly,
Brian Cochran
Subscribe to:
Posts (Atom)