Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.
Solving the Last Mile
Expect some final roadblocks when trying to expose your enterprise systems as services.
6 Min Read
The service-oriented integration (SOI) market is expected to grow from $435 million in 2001 to about $6.2 billion in 2006, according to a ZapThink report. Impressive numbers. They indicate that enterprises have reached an inflection point as they prepare their infrastructures to leverage services.
However, as with any new trend, there are always those annoying problems that you must solve in order to offer a complete solution. In the case of SOI, it's the "last mile" issue, or bringing your service-oriented architecture (SOA) to your existing systems, be they built 20 years ago or 20 days ago. In other words, exposing all your enterprise systems as services, as well as managing how those services work together.
Information Vs. Services
Services are very different from points of information production or consumption because they denote behavior. Indeed, they are application functions that you may extend from one application to another by leveraging some type of service delivery standard such as Web services. Promoting the reuse of application functionality from one application to another is the core reason enterprises are moving to SOA and SOI.
Having said that, many people still view the ability to expose information, albeit through services, as service-oriented. This is a common mistake. You must keep in mind that the notion of SOA and SOI is all about the ability to share behavior and information bound to those behaviors, not just information. The rise of messaging technology with Web services interfaces has led to this confusion. Although they are indeed leveraging services, they are doing so to move information across a queue, not aggregate and manage remote application functions.
Services are a bit more complex to expose due to the intricacies of the native interfaces, if they indeed exist. How you expose existing services requires some creativity and perhaps some good technology. I like to classify existing services in one of the following categories:
Existing and exposed services are just what they sound like. They already exist and are already exposed as Web services. Examples include the newer versions of SAP and PeopleSoft that have redone their interfaces as Web services and thus are ready to plug into a SOA. In some instances, you may have to do some fine-tuning for compatibility, but the idea is that your major enterprise software vendors do the service-enablement work for you. This, of course, is the best-case scenario — least expensive and least risky.
Aggregated and single transactions are transactional systems that are exposed as services. Examples of these types of existing services are CICS, Tuxedo, and even J2EE transactions that are seen as Web services externally, typically through software provided by transactional container vendors. For example, in the case of CICS, IBM's WebSphere is able to expose these transactions as services and almost all J2EE tool and container providers also offer Web services capabilities. This tends to be more of a natural one-to-one fit, because transactions are well defined and granular, and so should be Web services. This is less costly and less risky.
API services are APIs that are "wrapped" so they appear as services. This approach means leveraging an API-to-Web services translation layer, such as the mechanisms some middleware vendors provide, or creating a translation layer on your own. The translation layer needs to manage the mediation between the exposed Web services that represent the API, and the API itself. Mediation includes exception handling, reliability issues, as well as security. The low hanging fruit here is to find existing software that takes care of this layer for you, that's the least risk and cost. However, if the software can't be found, you're going to have to code your way through this translation layer, which adds both cost and risk.
Recast standard interfaces, like API services, means that you're looking to leverage an existing standard interface, such as JMS, JCA, ebXML, or RMI, and expose it as a Web service. In essence, you're recasting one standard for another, and the same problems that you solve when considering API services you need to solve here, including managing the mediation between the standards and exposed services, as well as all operational aspects. The cost and risk trade-offs are the same as with API services.
Ported services, the last resort, are a rewrite exercise where you take existing application functions and rewrite them as Web services. You'll need a new architecture and have to hand-code the existing interfaces so they appear as true Web services. As you may have guessed, this approach is the riskiest and most time-consuming of all these categories because you must suffer through the redevelopment, testing, and redeployment of the systems just to support Web services.
Approaching the Last Mile
So, how do you approach the last mile problem when building out your SOA? Simply put, it's really a matter of understanding and applying the right technology. I recommend the following procedure:
Create a catalog of your potential services, or existing application functions — new or old services, it doesn't matter. Keep in mind that services should be limited in their scope. For example, a service that controls inventory is too broad, not granular enough. It would be much better to document all the sub-functions and sub-subfunctions to identify 1,000 potential services, not just a few out of a single enterprise application. A granular approach gives people who use the services the opportunity to mix and match services at a much lower level, which makes those services more useful.
Figure out a strategy for exposing those services. Each system is going to need a different technique and a different enabling technology to complete the last mile. In some instances, the strategy is going to mean redevelopment, in other instances, it's going require software to mediate the difference between the native interfaces or standard interfaces and Web services. In some cases, if you're lucky, the Web services are already exposed.
Document the data and structures bound to those potential services. In other words, how does that service use data and what's the schema employed?
Determine a strategy to test the exposed services, making sure the exposed services function and perform correctly. You may need to do some tuning and tweaking, depending on what you find. Remember, these services are destined to become parts of other applications, so any quality problems will be replicated over and over again.
Clearly, integration can be complex and difficult,. The hardest part of integration is linking your existing systems to your SOA and seeing those systems as a true set of services. This point is also where most IT shops fall down, not able to make the walk down that last mile. Unfortunately, it's the last mile to your success with SOI and SOA. If you don't complete your journey, the problem isn't solved.
David S. Linthicum is the author of three books on application integration, including Next Generation Application Integration: From Simple Information to Web Services (Addison-Wesley, 2003). He was CTO both for Mercator Software and SAGA Software, two application integration technology vendors.
RESOURCES
ZapThink: www.zapthink.com
About the Author(s)
You May Also Like
More Insights
Webinars
Editor's Choice
May 2, 2024
While there are plentiful options in cyber resiliency and business continuity tools and platforms, there isn’t one that can knock out everything from sudden cloud outages to prolonged ransomware attacks in a single punch. What can you do to keep the company on its feet no matter what is thrown at it? Find out in this new virtual event.
Reserve Your Seat Now