You have purchased applications. You have existing in-house applications. You have applications you are in the process of writing from scratch. Now your CIO wants to know how all these applications are going to start leveraging this "SOA" that's been in all the papers.
Ah yes, S-O-A, the elusive Service Oriented Architecture. You've read the analyst reports. You've watched some online webinars. You even have a fancy poster in your office. It all sounds good, but you're not quite sure how it applies to your environment. 数据挖掘研究院
The bottom line is:
1. SOA is relevant even if you're not focused strictly on building applications.
2. You need the right infrastructure.
3. You must consider the provenance of your applications to take the best approach to enable them for SOA.
数据挖掘实验室
The remainder of this article will illustrate how the application of these basic concepts can help you evolve your current IT landscape to one that takes advantage of the opportunities offered by an SOA. But before we get too deep into the details, let's clarify what we're referring to as an SOA and look at how this can be interpreted to maximize its benefits.
数据挖掘工具
SOA OK
An SOA is typically described as an approach to building applications based on well-defined, loosely coupled processes or "services." This design approach has been appreciated as a theoretical model for years, but the advent of standards for Web Services has recently allowed SOA to gain a significant foothold in the industry. A full discussion of SOA and Web Services standards is beyond the scope of this article. Interested readers are encouraged to review back issues of this publication for a variety of pieces on these subjects. For now, we will merely point out that Web Service standards enable SOA in a manner which is language-neutral, platform-independent, and based on well-established Internet standards.
数据挖掘论坛
To Serve IT
SOA and Web Services have historically been discussed in the context of software development, when an application is built from the ground up. Application development is also where SOA and Web Services have gained real traction, for example, with software vendors and IT shops where business requirements are met with custom applications. 数据挖掘研究院
Today, however, many IT shops no longer develop software as a core competency. New capability is primarily provided via the acquisition of commercial off-the-shelf (COTS) software or by modifying previously developed applications. These previously developed legacy applications either pre-date the adoption of a COTS strategy or were deployed to achieve some competitive advantage.
The value these shops deliver in the provisioning of new functionality therefore centers on the integration of independently designed COTS, legacy, and occasionally newly developed applications. Differentiation is driven by this mix and by how well these systems work together. In such shops it may not be obvious how this newfangled SOA applies.
数据挖掘论坛
However, as some integration architects have recognized, SOA leverages the same principles and offers the same advantages as those associated with Enterprise Application Integration (EAI) approaches. The basic difference between EAI and SOA is that SOA is usually discussed in terms of a particular application whereas EAI applies at the application portfolio level. For example, the loosely coupled SOA approach to application assembly is analogous to the loosely coupled EAI approach to application integration. 数据挖掘实验室
What's All This Then?
It all sounds very interesting but what does any of this mean in practice for "buy and integrate" IT shops? What implication does the SOA model have for these organizations? Do Web Services play a role in meeting day-to-day requirements? One way to answer these questions is to consider the roles systems can play in an SOA and the application model they follow. 数据挖掘工具
The basic roles in an SOA are the service provider and the service consumer. The first role is taken by the application that presents services. The second role is taken by the application that exercises services to accomplish some business objective. In reality, services are often combined or composed into more complex processes, but conclusions drawn from the simpler interactions can be extrapolated to these more sophisticated scenarios. 数据挖掘交友
The application models - new custom applications, legacy, and COTS - should be familiar to most readers. For the uninitiated, the sidebar provides a brief primer. 数据挖掘论坛
For service-based integration to be viable service producers must possess a service presentation capability and they must present services relevant to integration requirements. Service consumers must have a service consumption capability and must be able to invoke services at points relevant to integration requirements in a manner supported by the available services. 数据挖掘实验室
One other consideration is an integration infrastructure, specifically what is commonly referred to as an ESB, described in the sidebar.
数据挖掘实验室
For each application model, we recommend SOA enablement strategies in the context of service provider and service consumer roles. Aside from using native service capabilities, two basic approaches are discussed: applying ESB technology and invasive application modification.
数据挖掘工具
Table 1 summarizes the recommendations for COTS, legacy, and custom development scenarios using a familiar stoplight metaphor. These are the three faces of SOA.
数据挖掘交友
COTS - It Is What It Is
Ultimately, whether a COTS application is service-enabled is at the discretion of the vendor. Note that most vendors are taking an SOA approach to the construction of these applications because of the advantages of this approach from an application build standpoint. Of course, for many implementation teams, the internal COTS architecture is obscured inside a black box. So this application of SOA in and of itself has little impact. 数据挖掘实验室
However, when SOA is the internal build approach, it's also likely to be an external integration approach. That is, service-based interfaces, usually following Web Services standards, are likely to be available, at least as an option. 数据挖掘研究院
The only real point of influence customers have therefore is the extent to which these capabilities are considered in purchase decisions. Ironically, even this influence is limited because COTS application selection is usually based largely on business priorities.
数据挖掘工具
The Service Provider Role
Where integration requirements can be supported by COTS services and the applications to be integrated are capable of consuming such services, they should do so. Service-based interfaces are likely to represent the most robust, longest-lived interface approach. The loosely coupled nature of these interfaces will also make integration based on these interfaces more flexible in the face of application upgrades to either the COTS application or the applications to which it is integrated. 数据挖掘论坛
Where a COTS application has relevant integration points but does not have a service presentation capability, an ESB may allow a COTS application to still play the role of a service provider. Where a COTS application doesn't have relevant outbound integration points, you must compromise requirements, develop a workaround, or take on the unsavory task of modifying the COTS code. This last option can be realized in-house, by the vendor, or even a third party, but it defeats some of the advantages of a COTS strategy and many IT organizations are therefore reticent to pursue it.
The Service Consumer Role
The consumption of services by a COTS application will hinge primarily on two factors. First, does the vendor provide the capability to exercise services at the required integration points? Second, do these services exist in the applications to which the COTS application needs to integrate? As in the service provider scenario, where these stars align, a services-based approach is a good strategy. Moreover, to the extent that these integration requirements are present and the COTS applications can consume services, this can actually drive build requirements for new development or legacy modifications. That is, if you are going to build or modify an interface anyway, you might as well present it as a service when the calling application can consume it as such. 数据挖掘研究院
When the COTS application has a relevant integration point but does not have a service consumption capability, you can consider an ESB service consumption strategy. For example, many COTS applications have proprietary inbound interfaces - say, based on interface tables - that can be managed via an external agent such as an ESB.
数据挖掘工具
When a COTS application doesn't have needed inbound integration points, these requirements can be addressed with approaches similar to those employed when a COTS application doesn't have desired outbound integration points.
Legacy Applications - Wrapper's Delight?
The fact of the matter is, it's often not any easier to meet legacy integration requirements with services than it is with any other integration approach. Sometimes we are considering applications whose designers never contemplated such requirements. The fundamental architecture of the application may impose obstacles to integration based on underlying data models or processing assumptions. Or, there can be an impedance mismatch with the typical service-based request-reply integration pattern and the native integration mechanism of the application.
This is why the frequently offered suggestion that you can just "wrap" legacy systems with services and be on your way is a hoax.
The Service Provider Role
For presenting services, you need, first and foremost, to expose the appropriate integration point. To the extent that existing systems have object-oriented foundations or their designers considered similar requirements, you may have an easier time of it; that is, if you happen to have the appropriate interface already exposed in a service-like manner, converting it to conform to Web Service standards may not be too challenging. You can even leverage an ESB to do much of the work. However, where this is not the case, plenty of heavy lifting may be required. 数据挖掘交友
Unlike a COTS scenario though, it's perfectly reasonable to take an invasive approach to add service-based interfaces to legacy applications. That is, modifying the application to provide relevant integration points may be perfectly feasible. It's just important to recognize that building services is a more significant undertaking than simply service-enabling existing outbound interfaces. 数据挖掘实验室
The Service Consumer Role
As far as legacy applications invoking services go, there are three considerations. First, this approach is only worth considering where relevant services are present. Then, you need to consider the capability of the legacy application to technically consume these services, again typically Web Services. This capability is often based on the development toolset and/or runtime environment of the legacy application. Finally, you have the same basic application architecture issues involved with presenting services. That is, can you crack open the legacy application in such a manner that it can take advantage of any services that might be available? When relevant legacy consumption integration points exist, an ESB can often be layered on top of them to invoke services where they are present.
数据挖掘论坛
If these integration points aren't present, as with service provisioning, you may need to modify the application directly. 数据挖掘研究院
New Development - The Final Frontier
While new development may be increasingly rare in many IT shops, when it occurs, you have ultimate control since these applications are effectively "under construction" as requirements are captured. 数据挖掘工具
The Service Provider Role
The recommendation for service presentation would be to take the same approach that most COTS vendors are taking - use Web Services. One caveat though is that while IT professionals are adept at abstracting and generalizing functionality for known requirements, you can't predictably build reuse beyond this point because any additional requirements are, well, unknown. No technology or architecture will address this issue. Technology like those based on Web Services standards will allow for integration to unanticipated platforms, but not in unanticipated patterns or for unanticipated purposes. 数据挖掘交友
The Service Consumer Role
The extent to which new applications can consume Web Services will make them easier to integrate as time marches on. This is because the integration mechanisms of the systems to which these new applications will need to integrate should be moving towards Web Services standards themselves. So where complementary services exist, this should be the integration strategy. Moreover, even if the applications with which you need to integrate use non-service-based approaches, it can still make sense to build service-based interfaces and then implement them using an ESB. That way, you have a migration path towards a future, more fully service-enabled integration world.
Again, this advantage is only at the platform level, not the application behavior level. Still, the good news is that since you're building from scratch, just as with the presentation of services, you can insert the application integration points in the appropriate location and craft them to follow appropriate integration patterns. 数据挖掘交友
Also, while you don't need an ESB to service-enable integration points that you are building as services, you may still want to leverage other useful ESB features such as orchestration or processes monitoring. By the way, this last point applies to COTS and legacy application models as well. 数据挖掘交友
I Hear New Trends a Comin', They're Rollin' Round the Bend
One final note on an ESB is that it also supports a co-existence strategy along the road to full application portfolio service-enablement. That is, you are never going to be able to "flip the switch" on an SOA for all your applications en masse. So you're going to need a way for your new service-enabled applications to co-exist with the traditional integration architectures of applications waiting in the wings for their service-enablement makeover.
数据挖掘实验室
Besides, even though this may be a noble goal, it may not be practicable or justified. Therefore a co-existence strategy is going to be a requirement for the foreseeable future, especially because as far as integration innovations go, this is just the latest. As soon as you get close to your SOA utopia, the target will move. Some other clever strategy will be bandied about there promising the next quantum leap in IT effectiveness. An ESB can then provide a bridge between your SOA-based application set and whatever comes next. 数据挖掘研究院
Let's Go Servin' Now, Everybody's Learning How
These are the three faces of SOA: COTS, legacy, and new development. By recognizing these faces and the approaches they imply, you can deliver a more effective SOA. You can elevate your SOA from an application construction tactic to an enterprise application integration strategy, with a commensurate elevation in returns. And in the end, that's probably what your CIO wants anyway.
