Discussions

XML & Web services: EJB's and WebServices - Best Practice Architecture

  1. Our current client already has a extensive EAI architecture built using Weblogic (Lots of EJBs housing business logic, connections to legacy middleware systems, etc)

    We are now tasked with extensive integration with external vendors, and need to wrap many of these EAI components with Webservices. After extensive hunting there seems very little information about Webservice best practices - particularly around implementing them in a fashion on EJB containers so that they are still open and generic enough for other systems, such as DOTNET:

    Some quesitons:
    - Should we build our Webservices to use the new WS-E standards? Are these standards too young ... are they easy enough to implement, without the external interfacer needing to know how how to adhere to ws-e as well!
    - Do we map our Webservices tightly onto the EJBs? Or do we build an abstraction layer (a service access component, and business object delegate component) which the webservice needs to pass through first
    - If the answer to the above it the latter; then there is the problem of what generic-type each of these delegates should accept. The coder which tries to call one of the Business objects, is separated by the abstraction layer; thus losing a lot of type checking and intellisense?
    - How granular do you make your Webservice Methods? We could have one PROCESS method which accepts the whole Object Model; or lots of tiny methods - thus trusting the caller does the correct message decomposition on his side?

    Any input will be appreciated

    thanks
    Xen
  2. Since you're on Weblogic, have you looked at Weblogic Integration (WLI)? I've used it for many of the tasks you describe and it greatly simplifies everything.
  3. Do we map our Webservices tightly onto the EJBs? Or do we build an abstraction layer (a service access component, and business object delegate component) which the webservice needs to pass through first
    It depends on how your EJB layer is written. Your WS should follow the general rules for EJB clients (e.g. do not call Entities directly, only Session Facades). If your Session EJB already have a service-orientation, mapping to them directly may work. If not, you will need some kind of abstraction layer.
    If the answer to the above it the latter; then there is the problem of what generic-type each of these delegates should accept. The coder which tries to call one of the Business objects, is separated by the abstraction layer; thus losing a lot of type checking and intellisense?
    If your Session EJB are exposing data as DTO (Data Transfer Objects), you can probably reuse these DTO for your web services as well. Most DTO are implemented at JavaBeans, which Java-based WS frameworks convert to XML nicely.

    If your Session EJB are not using DTO, or your DTO are not JavaBeans, you will probably need to covert to DTO in your abstraction layer.
    How granular do you make your Webservice Methods? We could have one PROCESS method which accepts the whole Object Model; or lots of tiny methods - thus trusting the caller does the correct message decomposition on his side?
    Any kind of distributed computing framework should be built around cross-grained operations. Otherwise your network traffic is too ugly. This is double true for Web Services, which already have a lot of overhead.