Requires Free Membership to View
I trust by "real-time" you are not referring to "hard" real-time systems. Hard real-time systems cannot tolerate the latencies inherent in most middleware systems. I assume you are referring to "live" integration with running applications.
Conceptually, the SCA component model provides an abstraction layer between service components and the protocols they use to communicate. Conceivably, an SCA component could interact with a legacy application using the legacy application's native protocol (assuming the SCA container provides a binding for the legacy protocol). But the reality is still a little short of the concept. Few SCA implementations exist, and the ones that do typically support a very limited set of protocol bindings (e.g., SOAP, RMI, and JMS; one implementation supports Jini).
The usual approach taken to enable "live" integration with legacy applications is to build a proxy service that encapsulates the legacy application. The proxy service exposes the capabilities of the legacy application through a standards-based interface, and its implementation uses whatever means available to communicate with the legacy application. If the legacy application exposes an API (e.g., programmable Java or .NET API, MQ API, JCA, or a proprietary API), you can wrap the API using your favorite service framework. If the legacy application only enables communications via an online user interface (e.g., 3270, HLLAPI, VT220, etc) you can use a screen scraping technology to create the proxy service. Many ESB vendors provide adapter frameworks that make it fairly trivial to create proxy services.
The proxy service can be configured as an SCA component, and therefore can be assembled into an SCA composite just like any other service.
This was first published in April 2008
Join the conversationComment
Share
Comments
Results
Contribute to the conversation