In this installment of the DCS series I want to frame Oxlo’s infrastructure approach for readers with technical interests.
Oxlo addresses dealer communication for lots of companies in automotive retail through our centrally managed and hosted Dealer Integration Network. Connecting systems in support of the business activities and processes of dealers, automakers, lenders and the like, requires a robust infrastructure of hardware and software. From our earliest days when we were just starting the business, to our latest refinements and scalability improvements, Oxlo has implemented what, in part, can be referred to as a B2B Enterprise Service Bus (ESB) for automotive retail.
Make no mistake, a simple hosted ESB would not solve the myriad problems and challenges involved in integrating automotive retail. That’s why Oxlo’s core ESB framework is one layer of an overall service oriented architecture (SOA). The broader SOA encompasses a great deal of support capabilities, configuration and management services, business intelligence services, and even self service capabilities for business partners.
But today’s focus is the ESB component of Oxlo’s SOA. There are a lot of authoritative sources that describe the concept and capabilities of an Enterprise Service Bus. Wikipedia has a good summary of core capabilities, which are largely in line with how Oxlo handles our ESB component:
Category |
Functions |
Invocation |
Support for synchronous and asynchronous transport protocols |
Routing |
Addressibility, content-based routing (Oxlo also addresses validation here) |
Mediation |
Adapters, protocol translation, data transformation and translation |
Process Orchestration |
Business process definition (& execution) |
Complex Event Processing |
Event interpretation, correlation, pattern matching, publish/subscribe |
Other Quality of Service |
Security (encryption and signing), reliable delivery, transactions |
Management |
Monitoring, audit, logging, metering, admin console, BAM |
In addition to this generic definition, the way Oxlo has implemented our Dealer Integration Network has been specifically focused on automotive retail, which means we’ve accommodated for STAR Standards, as well as a lot of the proprietary dealer communication protocols already in use in this industry. In other words, we’re not generically supporting say SAP iDoc or generic STAR WS, but rather message formats and protocols that are specific to each particular automaker. Even with standards everyone implements differently.
In addition to the message-based communications that our ESB handles, dealer communication in this industry often involves a portal that is hosted by the dealer’s business partner. Automakers are the best example here—such as Toyota’s Dealer Daily, GM’s Dealer World, or Chrysler’s Dealer Connect. These portals provide dealer users the ability to add information when a message-based process needs additional data (plus a dealer portal can support other types of dealer communications, such as training materials and document archives).
The reason I make mention of this complimentary portal infrastructure is because I contend that a robust ESB approach can reduce the need to operate an expansive portal presence. (Not eliminate.) Oxlo’s executed our ESB approach because our fundamental belief is that dealer integration should not only increase responsiveness to point-of-sale needs, but also decrease cost for dealer communications. The time and resources needed to develop, maintain and expand an extensive portal presence are costly.
Since we’re talking about a technical framework, for those in IT at an automaker, lender, insurer, remarketer or other auto retail business, here are some of the most obvious benefits of ESB:
- First, you can respond quickly to business customers’ needs and dealers’ needs, and in fact take a leadership position by enabling additional value for existing applications and information
- Second, you can add new applications more easily, and quickly connect users (dealer personnel)
- Third, you can reduce software development and maintenance costs. This is particularly true in Oxlo’s case (pardon the blatant commercial) because we host the ESB as part of our broader SOA.
Interested in more expert sources on ESB? Try these:
IBM: http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=landings/esb
Oracle: http://www.oracle.com/appserver/esb.html
BEA: http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/aqualogic/service_bus/
Microsoft: http://www.microsoft.com/biztalk/solutions/soa/esb.mspx
SAP: http://www.sap.com/usa/platform/netweaver/index.epx
Tibco: http://www.tibco.com/software/enterprise_service_bus/default.jsp
RedHat: http://www.redhat.com/about/news/prarchive/2006/jboss_esb4.html
Comments