News: J2EE Connector Architecture or Web Services for Integration?

  1. An odd but common question that tends to come up now and then is, "What is the difference between J2EE Connector Architecture and Web services?" Web services and JCA both are standards to help with integration, but they certainly don't compete. In an recent article on BEA's Developer 2 Developer portal, Tyler Jewell provides insight into this question.

    Read Which Integration Approach is Best? J2EE CA or Web Services?.

    Threaded Messages (25)

  2. I've actually had a number of different comments about the article since it was posted. I want to try and summarize the major additions here, if possible.

    BEA's product management pointed out that their biggest difference is not intrusion, rather, the coupling of the services. JCA is a very tightly coupled solution targeted wholly at the developer. Web Services employs a loosely coupled architecture that conceivably would allow a business analyst to leverage a legacy system through a BPM product or other Web Service access technology.

    A number of people noted that tight coupling provides a more reliable deliver of messages as opposed to loose coupling.

    John Bossons of rogers.com also noted that the security models between the two have to be completely different: "a whole new security architecture is required (at least for B2B apps) because security has to be message-based (and potentially even attachment-based in a multi-source, multi-attachment message) rather than channel-based, as in the standard csiv2 architecture."

  3. I'll second what Tyler said. JCA allows a software company to provide a standard interface to an app server such that developers can use J2EE technology to work with "data sources" that are not necessarily JDBC drivers. Personal example: We use JCA so that the app server (e.g. WL7.0) transaction manager calls our JTA interface for our clustered transactional cache. In other words, JCA is about exposing data sources for tight integration into the app server, and thus making them available for easy use (easy, as in as easy as EJB) to the developer.


    Cameron Purdy
    Tangosol, Inc.
  4. The whole article talks from the data integration point of view thus overshadowing Webservices. Webservices is all about exposing a service(which is nothing but a business component serving some functionality)to the external world. So it will be very useful when it comes to functional/application integration. When we talk about data integration from a legacy system, as you rightly said,both JCA and webservices will be involved in the integration. In such a case, a component using JCA can be used as a webservice.
     Also the existing integrated custom applications need not be rewritten just for the sake of webservice enabling, unless there is a business process integration with external entities, which in future calls for a standardised communication using soap and xml.

  5. A good decision making criteria is to analysis weather the integration is Access Integration vs. Application itegration. There is a big difference in integrating a business process vs integration access to data. This is where the decision may take place. Furthermore, there are cases where you can use both technologies, together, to solve issues.

    Your Web Service would wrap a Session Bean wich uses a combination of Connectors, JMS, JDBC, and/or Entity Beans to solve a business problem.
  6. I would completely agree with you. Actually, there's no conflict at all between these two technologies. JCA gives a uniform client access just like JMS or JDBC. Just like JMS removes the need for a Middleware client, JCA removes the need for a EAI client. For example, you don't need to have a SAP client or Siebel client. All you need is a JCA client.

    Webservices on the other hand, is meant for exposing a service. For example, if you need to expose a service of your Enterprise product, be it Siebel or SAP, you can do that using Webservices. This exposure doesn't depend on the implementation of JCA.
  7. From my brief experience in developing JCA adapters during the past 6 months, I'd say that if the EIS or sub-system is internal (behind the firewall) and supports connection pooling or requires native code access - JCA is pretty good, at least with WLS 7.0 implementation which has some nice connection management features.

    Some of the stuff such as transactions and security are nice additions, but not one of the propriety and legacy systems I've come across so far either supports XA transactions or has required the user's identify.

    What I've found to be a more useful feature though is native code access. Wrapping a small native API in a minimal JCA implementation and deploying it inside the EAR file gives your EJBs free access to native code - without breaking restrictions imposed by the container, or the specification.

    I've lost count of all the new XML and Web Service based APIs released recently, but I can't say I've seen any that address basic plumbing and integration issues such as connection pooling and language interoperability.

  8. I loved the comment:

    "For those enterprises that commit to .NET, they will be forced to purchase an EAI server (WebLogic Server is a good choice) to intercept Web services requests and then use an EAI-specific technology such as JCA to do the integration."

    Nothing like having to buy the competition to get the job done and spend twice as much in doing so.
  9. "In other words, a Web services native binding would have to be created for the legacy system (and this isn’t very likely)."

    You must be taking heavy hits off your hooka.

    ALL the major packaged application vendors are adding this stuff to their products -- there is pressure from their customers to get this functionality in there, as it enables end to end integration WITHOUT forcing them to rely on proprietary middleware technologies (like Tibco or SeeBeyond or Vitria or ...).

    This is THE way ingration will take place in the future... pretty much everything will be accessible via Web Services, and competition for integration will boil down to a "which product can integrate/transform/etc. these services and provide the best QOS or the fastest integration for the best price." Nobody who has an integration problem wants to code this stuff from the JCA level up -- they want the packaged app vendors themselves to provide them with this. Building their own adapter to SAP via JCA? That's like asking them to sleep with their mom.

  10. I think it's a chicken and egg problem. I agree that there is enormous demand for app vendors to have native web services bindings. And, for those companies that extend apps from these products that already have Web Services binding, they will reap the rewards.

    But, what about all of those existing applications and legacy systems that are in maintenance mode? We've found that a number of companies aren't willing to migrate to a new version, implementation, or modification just to get a Web Services stack.

    I think that if you are a new company and your enterprise is based upon Web Services from the get-go, you will see the great ROI everyone is talking about. However, for companies that already have a large installed base, migrating all of these systems to native Web Services stacks is not the right answer -- they'll laugh us out the door. For these companies, a Web Services bridge that uses an underlying JCA or proprietary adapter will be the way to go.
  11. Recall, just about ALL the packaged app vendors have committed to having this.

    As for existing applications, there are a number of products whose goal is to let you "expose" existing applications as web services. You can have "plain old Java", J2EE, CORBA, or some other way of getting into it -- then you need not graft an application server to this old application to manage it.

    I know of a couple products which do this already -- IONA's XMLBUS and Cape Clear's CapeConnect, for a couple. These make integration a "build" proposition versus a "buy" decision (as you noted in your article -- JCA is focused at the developer) which is much more attractive to customers doing integration.

    Remember, CORBA has been able to do much of what JCA does now for about 8 years, but it didn't get much traction because it requires you to build your own adapters on top of APIs, rather than giving you pre-built adapters which you just expose to a workflow and routing engine. People in charge of integration products require the latter.

  12. I wouldn't position it as an integration vendor or app server vendor proposition. MSFT, IBM, ORCL, and BEAS are all positioning themselves as infrastructure providers that will be able to do what IONA / CapeClear do, only as part of the standard platform.

    If most of these companies are going to standardize on a platform infrastructure, they'll expect the integration (either loosely coupled integration through Web Services or tight coupled integration through JCA) to be there. I don't think in the long run, companies will want to have different vendors do integration and application development.

    Part of the platform story has to be an end-to-end solution, which means that an integration provider has to have a tightly coupled AND loosely-coupled integration story. MSFT is ONLY pitching a loosely-coupled story through Web Services. IONA pitches a loosely coupled story through Web Services and tight coupling through CORBA. BEAS pitches a loosely coupled story through Web Services and tight coupling through JCA, CORBA, JAM, and eLink. Etc, etc.
  13. I agree with Tyler on this one. Having actually led a team in JCA implementations for a large number of "legacy" systems including SAP, Oracle ERP, Siebel, terminal adapters (TN5250/3270), JD Edwards, and so on. Mark, if you remember SAGA, that's the background I come from.

    The entire JCA vs. Web Services idea was thrown around our office as well. Probably one of the biggest misconceptions that I see about Web Services is that it's the new "integration platform". Sure, and XML will let every application speak with every other application through a common document model. ;-)

    I think of WS and JCA as being components of a bigger solution. Tyler is correct in saying that most customers are not always willing to switch to a newer version of a software application just to get some new features. What's more appealing, hearing that you have to upgrade SAP and Siebel to get Web Services in order to integrate them, or to purchase an "EAI" solution (possibly based on WS and JCA) instead?

    WS are like XML, a little overhyped. I've heard the same companies claim to have native XML support, but they don't always deliver on their claims. Remember, JCA, WS, XML, CORBA, etc., are all aimed at developers, not the big-money decision makers who only care if it works or not. If you doubt me, try asking the CEO of a multi-million dollar org. to see if he cares if an integration solution that uses WS or JCA is better. He or she will ask which one works, then he or she will ask which one costs less. It's not always the answer people are looking for, but then again the truth isn't always easy to swallow.

    John - Software Architect
  14. WS and JCA are likely to become part of a bigger solution indeed. The loosely coupled model is not replacing the tightly coupled model. The lines between application development and application integration are blurring. What customers want is to develop applications that are ready for integration and integrate applications that are ready for further development, so to speak. This calls for further evolution of the application infrastructure platform and the corresponding programming/component model. For example, JSR 159 (JPC) is signalling a move at this direction.

    A similar commercial implementation you can download and evaluate to address the above (supporting Java, JCA, JMS, EJB, WS/SOAP both sync and async) is an orchestration container empowered with the ScenarioBean abstraction. It's available at http://www.collaxa.com
  15. I think Tyler made a very good point on "intrusion." Most web services evangelists paint a picture where in some piece of legacy can just be exposed as a "service" so that it is immediately available to every computing device out there.

    The reality is that, most of such legacy code is written with certain assumptions suitable for certain kinds of clients and environments. In order to expose such code as a "service" means removing/normalizing those assumptions. This is definitely intrusive, and I don't think there is any magic solution for this.

    But I've to disagree on the "code binding" argument. Whether it is expressed in Java, or XML, or even hand-signals, binding is essential for meaningful communication. The "typing" issue gets complicated with XML since programming languages that we use in practive do not handle XML "types". But that does not mean that the binding is dynamic. The binding is still there in the code. Secondly, in most implementations of web services, WLDL lookup and code-generation is done at compile-time - just like it is done with other RPC techniques.

    The same goes for the "data binding" argument. Even if all intermediaries agree to expose data as XML, there could still be loss of data due native-to-XML data conversions. Again, this is unavoidable.

  16. The comment I would have is that web services span a wider area of integration than JCA. I wish the whole world is using java and J2EE, and that simply is not true.

    If you are integrating two legacy applications, why have JCA in between?.

    So, web services may actually be a thorn in app server vendor's market place. The value proposition for application servers is diminishing, IMO. Web services may actually help integration companies such as web methods.
  17. If I need to expose a service to various people (to divisions in my large company, or to partners) then
    Web Services can make sense. If I am tying in my application to the "legacy system" then I can use JCA adapter. I wouldn't want to use Web Services to access my database (which is an EIS system itself). It depends on what you want to do, how fine-grained you are, who you are talking too, etc. I don't think one isn't better than another.
  18. Tyler's got some excellent points in this article, which I generally I agree with.

    I've been teaching a lot of .NET seminars lately, so my perspective on the differences is more about wire protocols.

    JCA solution: Use the right wire protocol for the job. Leverage a common interface through java.

    Web services: Use XML. Build an XML parser on every platform. Leverage whatever runtime toolkit(s) you want.

    The former is, as Tyler says, less intrusive than the second model. The former also allows to use traditional QoS and security mechanisms, whereas we're still rebuilding all the basic infrastructure in the web services world. Conversations, authentication, authorization are all works in progress.

    JCA recognizes the disparity in the intent of various protocols, but abstracts all of that into the Common Client Interface and the RAR format. It's a good approach, and probably complementary to web services.
  19. For an API Provider with a sound multi tier architecture it shouldn't be a big problem to both expose an API as a web service, a JCA or whatever comes tomorrow, should it ? For the people who are about to use the API, the question is more difficult, of course.

  20. > For an API Provider with a sound multi tier architecture it
    > shouldn't be a big problem to both expose an API as a web
    > service, a JCA or whatever comes tomorrow, should it ? For

    Even on the provider-side, this assertion is far-fetched. Interestingly, for the abstractions that a layer provides to be useful, the API can't possibly abstract every conceivable scenario - although we all want to think of such a possibility. The reality is that assumptions leak between layers (not necessarily due to bad design/implementation).

  21. Agree partly. IMO the Web Service and JCA shall be used together probably and each has its own place in big picture, though all the pieces have to be developed before that. Conceptually If I am a service provider and have legacy data, I will use an Application server to expose my service as Web Service. The Application server will do customer management and business process logic related to the service. JCA will be used to get the data from legacy to Application Server, because I can afford tight coupling here. And a customer who wants to use my service will be Web Service client, because he does not want to be coupled with my offerings and wants to keep option of using another service from another provider. If the customer wants to be my partner and needs integration with my application, he has the option of B2B, which is another story.

  22. One of the fundamental assumptions that Tyler's article and much of the discussion stemming from it seem to make is that you have to choose between tight coupling, via something like JCA, or loose coupling, via something like Web Services. In the real world of integration, neither approach is sufficient, and both approaches are necessary. Application servers are good for some things, and integration brokers are good for other things, and neither can do it all. Taking a "best of breed" approach doesn't work either, because in the end, how do you integrate all the "best of breed" components you've chosen? If you're forced into a single technology like JCA or Web Services, your chosen vendor may win, but ultimately you lose because you haven't really solved your integration problems. That's precisely why IONA's Orbix E2A products cover the whole integration space, everything from CORBA to J2EE to EAI to Web Services to B2B. The key here is that Orbix E2A is all one integration platform, supporting tight and loose coupling, supporting everything from fine-grained objects to coarse-grained business processes, security, transactions, systems management, all on our enterprise-class Adaptive Runtime Technology (ART) infrastructure, and all based on fanatical adherence to open standards. Real-world integration requires the application of a continuum of technologies, not a "one size fits all" approach.
  23. Steve, Steve, Steve. I had done such a good job of keeping vendor perspectives out of the article and thread. Honestly, why do you think I wrote the article in the first place? It's because BEA WebLogic Platform 7.0 does everything that you describe, everything in the article, and then some. But, I didn't point that out. If you want to start talking about product differentiators, we can, but don't make accusations that IONA's product is doing something that other products are not.

    In fact, IBM and Sun are also aggressively working towards similar solutions, not to mention Vitria, WebMethods, TIBCO, etc.

    Let's keep this discussion about the technology and not products.

    Tyler Jewell
    Director, Technical Evangelism
    BEA Systems, Inc.
  24. Tyler, Tyler, Tyler. :-)

    I mentioned our perspective for a couple of reasons. One, in one of your postings you mentioned IONA in a CORBA-only context, and I felt I had to correct that misperception by stating that our products cover the entire integration spectrum. Two, others had mentioned their products in this thread, so I didn't see the harm in also doing so.

    Others have already pointed out other technical issues with your article, such as the fact that platform vendors are already building Web Services support into their products (contrary to what your article says), and that JCA suffers from problems related to impedance mismatch and inappropriate abstractions.

    Despite your opinion, in my previous posting I actually was talking technology, not product. Let me say it again, and I won't mention Orbix E2A this time. :-)

    Your article makes it seem like you have to choose either tight or loose coupling. I'm saying that you don't. So many technologists get caught up in the religious wars of tight vs. loose coupling, RPC vs. asynch messaging, EAI vs. Web Services, J2EE vs. .NET, are mainframes really dead?, etc., etc., ad nauseum. While these arguments may help pass the time if you're too geeky to get a date, they're ultimately useless arguments, because all of the above, and then some, are part of real-world enterprise systems, and real-world integration products for those systems better cover all of the above in a consistent and coherent fashion. Taking an app server and slapping Web Services on the side of it just to cover a customer checkbox does not an integrated product make. Taking an EAI product and sticking a SOAP stack in the box does not do the job either. Customers win when integration products provide support for multiple technologies and approaches, all in an integrated, coherent, and consistent fashion, rather than forcing the customer to "pick their poison."

    Steve Vinoski
    Chief Architect, VP Platform Technologies, Application Server Platform Technical Director, and IONA Fellow
    IONA Technologies
  25. "Real-world integration requires the application of a continuum of technologies, not a "one size fits all" approach."

    I am not at all certain that Tyler suggested that you need to make a choice between tight-coupling to loose-coupling. It's becoming rather clear that the lines between application development and integration are getting blurred. Developing an application that cannot integrate (i.e. becomes legacy) is bad. Integrating existing applications without being able to develop new additional functionality is just as bad.

    The notion of providing a continuum of technologies is a useful one but without sacrificing things like: application manageability, developer effectiveness (skill utilization) and the ability of the vendor product(s) to evolve.

    In the world of J2EE and Web Services, the relevant design concepts are (1) abstraction and (2) container. What is an effective abstraction for dealing with both tightly-coupled Java logic (e.g. EJB, JCA) and loosely-coupled JMS and XML Web Services? What are the repeating and consistent infrastructure requirements that need to be addressed when building applications that utilize both tightly-coupled and loosely-coupled components/services? Can this infrastructure be packaged in a form of a container where complexities are hidden from developers?

    I have an answer and it's called Web Service Orchestration(but then you'll quickly realize that I work for Collaxa... the premier provider of a Web Service Orchestration Server).

  26. I'm new to JCA and wonder if a JCA adapter can be plugged into every J2EE compliant container. I would like to use JCA to build a messaging system (hub) for different ERP systems using a SOAP engine.

    JCA seems to be fine for tight coupling with a good support for transaction management, security and connection pooling. Also I know there are some projects outside which try to define such things for web services (which are great for loose coupling and exposing interfaces to the outside world) as well. I think it will take a long way to have such higher level features as a standard for web services.

    Turning JCA in an framework to establish loose coupling on the web is also not real option.