New Article on XML Business Delegate Pattern Posted on TSS


News: New Article on XML Business Delegate Pattern Posted on TSS

  1. A new article, by Paulo Caroli, looks at the 'XML Business Delegate' pattern, which provides a solution to facilitate a mapping from an object-oriented system to a service-oriented one. This article shows you how you can combine J2EE Design Patterns, such as the Business Delegate, the Session Facade, and the DTO, with XML, to make your EJB application ready for Web services.

    Read 'Making your J2EE Application Web Services Ready' by Paulo Caroli

    Threaded Messages (16)

  2. 80% of this article seems to just cover patterns that are widely discussed in various books. When i started reading this article i thought that this would be some in depth discusssion of using XML in a web servive scenario. Only the last paragraph seems to talk a little bit about web services. Everything else in this article was just covering what DTO means, session facade means, business delegate means.

    I liked the view of Matin fowler to web services . He was relating web service to just another UI layer like JSP and swing. So anything we do in design before the UI layer would seem irrelevant and web services to me is just another UI layer.
  3. I agree with the previous comment--there isn't much new here. It's largely a rehash of material from Core J2EE Patterns: the Gospel according to Sun. For example, the article doesn't discuss why you would automatically want to use EJB to back web services. DTOs are an unpleasant necessity in distributed applications. Unless you really need a distributed application, you don't always need them.

    I think it's usually better to keep XML at the boundaries of an application, and I don't like the idea of DTOs including toXML and fromXML methods. What if a different XML format is required? The Visitor design pattern and on-the-fly reflection can be used to generate XML from domain objects that don't need any knowledge of XML.

    Rod Johnson, author of Expert One-on-One J2EE Design and Development. Pages 238-245 discuss use of XML within and at the boundaries of J2EE applications.
  4. I liked the view of Matin fowler to web services . He was >relating web service to just another UI layer like JSP and >swing.

    WS are cores grained application to application, distributed interactions over HTTP using XML. I don't think JSP are same as WS because

    A. JSP has lot of fine-grained interactions; that is it there is many method calls to fill one JSP page.
    B. WS are stateless where as JSP may need state on server.
    C. JSP is not an application-to-application interaction tool.

    In my opinion, WS is more similar to RMI than JSP.
  5. Use of Web services in RPC style is not nearly as interesting or useful as their use in asynchronous interactions among applications (aka business flows).

    For this to happen in the J2EE world, a new more elaborate abstraction is needed, not addressed by any of the existing design patterns. What I'm talking about is a way for Java programmers to describe long-running, multi-step interactions among Web services (As well as JMS messaging and manual tasks, through JSP, email, etc). This abstraction will require orchestration facilities to be available, which can be delivered in a form of a J2EE-based orchestration container. Like JSP, the abstraction used to encode orchestration logic, should be easy to learn by Java developers.


  6. Jill,
        You're talking workflow and there are quite a few workflow engines out there.
  7. Suez, can you recommend one (a book on workflow that is...). Thanks!
  8. Why not just use JAX-RPC as the mechanism to make your J2EE (or EJB for the case of this article) application Web services ready?

    In fact in EJB2.1, you can already define an EJB as a Web Service endpoint...

    Therefore the business delegate which operates more on the client side can either use JAX-RPC stubs to invoke the procedures or manually send and receive SOAP messages based on the WSDL to the JAX-RPC or EJB endpoint.

    ps: should the business delegate not be on the client side (i.e. Service Requestor's side) rather than on the Service Provider's side in Figure 12?
  9. Please ignore my previous message.. was badly worded...

    Here is the more correctly worded message:

    Why not just use JAX-RPC as the mechanism to make your J2EE (or EJB for the case of this article) application Web services ready?

    In fact in EJB2.1, you can already define a stateless session EJB as a Web Service endpoint...

    Therefore, all clients have to do is to send and receive SOAP messages to and from these endpoints (JAX-RPC or EJB endpoints) based on the corresponding WSDLs of the services defined by these endpoints. For the case of JAX-RPC, the client can even use JAX-RPC stubs if they have access to them.

    Since the conversion of the SOAP message to corresponding Java objects and server side method is already handled by the application server, your application code only needs to work with the corresponding Java objects. Seems simpler, more open and robust than having to have your own code to convert JTOs to and from XML.

  10. Lawrence, I agree. Some app servers (like WebLogic) already support web services endpoints for EJB. And as I suggested, not ever web service needs to be implemented using EJB.

  11. Can you name one workflow engine that is developer-friendly and uses an abstraction ala JSP that can be learned within a day or two by Java developers to program orchestration logic?


  12. Use of Web services in RPC style is not nearly as interesting or useful as their use >in asynchronous interactions among applications (aka business flows)


    I think that B2B is not quite about RPC and WS model mentions that talking about “document” model. WS should be considered and used (if necessary) with emphasis on “document” model. So, I guess WS is something about some standardized document processing and should not be used for implementing RPC between systems. The difference between “document” view and RPC view is almost unnoticeable (and even may not exist technically), but it is here. We may notice that if we will consider architectural aspects and nature of B2B communications( they are workwlows, not a stateless standalone transactions).

    I would try to draw a separation line: if we want to map an incoming document to a programming language structure and use that structure programmatically, then we should not use WS/XML-RPC (even UDDI and WSDL allows us to do that easy). If we are going to process incoming data as XML document, lets say transform it into another text document, then, most likely, we are dealing with “document” oriented model and WS will be good enough. But actually in the case we should not worry how that XML document was delivered. We may even recall that SOAP does not define delivery protocol (well, except http that I consider to be a foreign inclusion).

     What is my point?

    Just a voice against WS hype, which is profitable for vendors but might be a dead-end for users. WS could lead to the same outcome as VB (or scripting languages): easy to start with but impossible to scale up to a certain level.
  13. Aside from use of J2EE patterns, one should also look at the problem of composition of asynchronous Web Services into process-centric applications (i.e. business processes, workflow and long-running transactions). Web services orchestration is an emerging category which addresses this implementation domain, empowered by standards such as BPEL4WS and WS-T.
  14. Can you give a sample for the use of Web Services orchestration?

    Best Regards, Paulo
  15. Orchestration is somewhat of a loaded term at the moment.
    Some companies refer to it as routing of messages (like Sonic), some refer to it as the top layer of an EAI product suite (like MS BizTalk) and then some (like Collaxa) refer to it as a controller in charge of conducting and managing interactions among loosely-coupled asynchronous components. That piece of infrastructure software is what we call an orchestration server (which happens to sit on top of J2EE).
    A good example for the use of orchestration is in enterprise portals. If you want to extend a portal to enable users to be plugged into processes, workflows or transactions within the organization (aka process-centric apps), you can use an orchestration server to do that easily. The orchestration server includes all the plumbing that you'd normally have to build yourself as a developer, like - java to XML mapping, tracking and persisting state of long-running multi-step processes, correlating message conversation IDs within asynchronous exchanges, coordinating business transactions (WS-T), generating
    audit trail, monitoring transactions status, etc.

    You can see real-world scenarios (travel agent, loan procurement, distributed debt collection, etc) implemented through orchestration here:
  16. I've found an (apparently hidden) orchestration sample on Collaxa's site.


  17. SAAJ object as DTO[ Go to top ]

    What are your thoughts on using a SAAJ object as the DTO presented in this article? I guess that the 'BusinessDelegate' would get handed the SAAJ object by the SOAP engine and would pass that on to the SessionFacade.

    What are the pros/cons for creating an additional DTO for the EJB layer vs. continuing working with the SAAJ object?