Hello Doug,
Thank you very much for your response.
Things are becoming clearer in my head thank God. So JAX-RPC is good if you're doing synchronous messaging - whether RPC-oriented or document-oriented. We want to develop a Web service interface for our CRM product. The Web service would be a synchronous service, but there may be parts of it that are more RPC-oriented and parts of it that are more document-oriented. I am investigating possible architecture choices. JAXM is good for asynchronous messaging but that isn't a requirement for our CRM Web service project. Although we want to make sure we choose an architecture that gives us the flexibility to write document-oriented services as well as RPC-oriented services. Also we do not want to use an architecture that requires the use of EJBs. So far I feel that using JSR-109 which enbodies JAX-RPC as part of it seems to be the appropriate architecture.
An additional question that I have is about JSR-109 and EJBs. What are the advantages and disadvantages of using EJBs for a new web services project that doesn't need to make use of pre-existing EJBs? I am not that knowledgable of EJBs but I've been told by several collegues to stay away from them. I understand the argument for using EJB-based web services when there is an already existing application architecture based on an EJB architecture. But for a totally new web services project, why would I want to use EJBs?
Regards,
Mete
---------- Original Message ----------------------------------
From: Doug Kohlert <Doug.Kohlert_at_Sun.COM>
Reply-To: users_at_jax-rpc.dev.java.net
Date: Wed, 04 Feb 2004 08:42:51 -0800
>Mete,
>If you use JAXRPC you can have handlers.
>
>If you have a messaging provider with a certain level of quality of service,
>or if you are doing workflow-like processing, with potentially long pauses
>between execution steps, JAXM is a better choice.
>
>With JAXM, you can take advantage of the power of asynchronous messaging
>(possibly with complex messaging profiles).
>
>Mete Kural wrote:
>
>> Hello Doug,
>>
>> Thanks for your comment.
>>
>>
>>>In general what you said is true, however in JAXRPC 1.1 it is possible to turn
>>>off data binding, thus exposing the XML (SOAPElement) to the endpoints.
>>>Therefore JAXRPC can be used for Document style services directly.
>>
>>
>> Is using JAX-RPC that way for developing document-oriented web services just as good as using JAXM? What are the advantages and disadvantages of using JAX-RPC in the manner you described (turning off data binding) to using just JAXM?
>>
>> Thanks,
>> Mete
>>
>> ---------- Original Message ----------------------------------
>> From: Doug Kohlert <Doug.Kohlert_at_Sun.COM>
>> Reply-To: users_at_jax-rpc.dev.java.net
>> Date: Fri, 30 Jan 2004 12:22:43 -0800
>>
>>
>>>Anne,
>>>In general what you said is true, however in JAXRPC 1.1 it is possible to turn
>>>off data binding, thus exposing the XML (SOAPElement) to the endpoints.
>>>Therefore JAXRPC can be used for Document style services directly.
>>>
>>>Anne Thomas Manes wrote:
>>>
>>>
>>>>JAX-RPC and JSR-109 support both RPC and Document style services, but
>>>>both APIs are designed to support an RMI-style programming interface --
>>>>meaning that the JAX-RPC runtime performs automatic marshalling and
>>>>unmarshalling of SOAP messages -- automatically converting Java objects
>>>>to XML and vice versa. If you prefer to build XML-oriented applications
>>>>then you probably want to use JAXM rather than JAX-RPC.
>>>>
>>>>Anne
>>>>
>>>>At 04:55 AM 1/23/2004, you wrote:
>>>>
>>>>
>>>>>Thanks for the information Anne. Now I get a better idea of what
>>>>>JSR-109 is. It seems like a pretty useful specification.
>>>>>
>>>>>I understand that JSR-109 doesn't force you to use EJBs, you can have
>>>>>a servlet implementation or an EJB implementation in a JSR-109 web
>>>>>service, which is great. But I still get the impression that it forces
>>>>>you to use a procedure-oriented model for building web services. Is it
>>>>>possible to build document-oriented web services using JSR-109?
>>>>>
>>>>>Thanks,
>>>>>Mete
>>>>>
>>>>>---------- Original Message ----------------------------------
>>>>>From: Anne Thomas Manes <anne_at_manes.net>
>>>>>Reply-To: users_at_jax-rpc.dev.java.net
>>>>>Date: Fri, 23 Jan 2004 18:12:56 +0100
>>>>>
>>>>>
>>>>>>Mete,
>>>>>>
>>>>>>The JAX-RPC spec defines a framework for Web services that can work in a
>>>>>>variety of Java environments -- including J2SE, Servlet engines, and
>>>>>
>>>>>J2EE.
>>>>>
>>>>>>But it provides a complete specification only for the servlet-based
>>>>>>environment. JSR-109 provides the complete specification for JAX-RPC
>>>>>
>>>>>in a
>>>>>
>>>>>>J2EE environment. It doesn't require that you use EJBs, but it does
>>>>>
>>>>>specify
>>>>>
>>>>>>how to map JAX-RPC to EJBs. I think that the most critical extra
>>>>>
>>>>>value of
>>>>>
>>>>>>JSR-109 over plain JAX-RPC is that it defines a standard deployment
>>>>>>descriptor for Web services.
>>>>>>
>>>>>>Anne
>>>>>>
>>>>>>At 10:36 AM 1/23/2004, you wrote:
>>>>>>
>>>>>>>Hello,
>>>>>>>
>>>>>>>I read the JSR-109 JSR page and I kind of get the impression that
>>>>>
>>>>>JSR-109
>>>>>
>>>>>>>suggests a framework for building web services. JAX-RPC is also a
>>>>>>>framework for building web services but I get the impression that
>>>>>
>>>>>Jsr-109
>>>>>
>>>>>>>is a superset of JAX-RPC. One thing that confuses me is whether JSR-109
>>>>>>>forces the use of EJBs. It is not clear from the JSR page. Can any
>>>>>
>>>>>of you
>>>>>
>>>>>>>help me with these questions.
>>>>>>>
>>>>>>>1) What really is JSR-109? Can someone give a better explanation
>>>>>
>>>>>than the
>>>>>
>>>>>>>one found on the JSR page?
>>>>>>>
>>>>>>>2) Does JSR-109 force the use of EJBs in web service development? Can I
>>>>>>>use JSR-109 without using EJBs?
>>>>>>>
>>>>>>>3) What are the advantages of using JSR-109 compared with just using
>>>>>>>JAX-RPC alone? What does JSR-109 buy me on top of JAX-RPC?
>>>>>>>
>>>>>>>Thanks,
>>>>>>>Mete
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>---------------------------------------------------------------------
>>>>>>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>>>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>>>>
>>>>>>
>>>>>>---------------------------------------------------------------------
>>>>>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>>>>
>>>>>>
>>>>>
>>>>>---------------------------------------------------------------------
>>>>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>>
>>>>
>>>>~~~~~~~~~~~~~~~~~~
>>>>Anne Thomas Manes
>>>>VP & Research Director
>>>>Burton Group
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>>
>>>>
>>>
>>>--
>>>Doug Kohlert
>>>Java Software Division
>>>Sun Microsystems, Inc.
>>>phone: 503 345-9806
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>>>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>> For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>>
>>
>
>--
>Doug Kohlert
>Java Software Division
>Sun Microsystems, Inc.
>phone: 503 345-9806
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
>For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-rpc.dev.java.net
For additional commands, e-mail: users-help_at_jax-rpc.dev.java.net