[Design of JBoss Web Services] - Re: RM Sender/Receiver as High Available (HA) Components
by richard.opalka＠jboss.com
"richard.opalka(a)jboss.com" wrote : First identified problem is HA itself. Imagine the following usecase:
|
| Client sends WS-RM message to a webservice endpoint that is not available.
|
| The default AS behaviour in such case is 404 (resource N/A).
|
| To overcome this problem here are the potential solutions that comes into my mind:
|
| 1) Deploy a special servlet that would do the following steps:
| * will match all http(s) requests that would result in 404 on running AS instance (is it doable?)
| * will ignore all http(s) POST requests that wouldn't contain SOAP envelope with WS-RM 1.0/1.1 protocol elements (quite performance issue but realizable)
|
| 2) Deploy a special servlet that would do the following steps:
| * will reside on /wsrm/* web context
| * all "GET WSDL" http(s) requests would return a modified WSDL document to reference the endpoint using /wsrm prefix for web context. (Of course only if such WSDL exists - otherwise it would return 404.)
|
| Example:
| |
| | client request GET .../wsrm/ctx/endpoint?wsdl
| | special servlet request GET .../ctx/endpoint?wsdl
| | RETURN modified WSDL or 404 (if above WSDL isn't available)
| |
| * will ignore all http(s) POST requests that wouldn't contain SOAP envelope with WS-RM 1.0/1.1 protocol elements (quite performance issue but realizable)
|
| For both above approaches it is supposed to use ServletContext.getContext() method to gain access to the context for various parts of the server, and as needed obtain RequestDispatcher objects from the context.
We (JBossWS team) brainstormed new and better HA solution ;)
The solution is the following:
Server side:
* we will provide two types of RMProxy (secured/unsecured)
* this RMProxy will implement Provider and MBean
* the secured RMProxy will have WS-Security handler in the handlers chain
* each RMEnabled endpoint must register itself to the RMProxy (using JMX)
* RMProxy will handle only registered endpoints
* RMProxy will use RMReceiver internally to ensure HA and QoS
* RMReceiver will forward endpoint invocations to RMEndpointInvoker
* RMEndpointInvoker will do endpoint invocations according to message addr. headers
Client side:
* WS-Security will move to the transport layer
* WS-RM handler will move to the transport layer
Both server and client side will survive and recover from restarts in next RM versions.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4135553#4135553
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4135553
18 years
Re: DIME support on JBoss EAP 4.3
by Thomas Diesler
The WS part of their application would have to be migrated to JAX-WS,
which is a general investment into the future. Note, that I am not
saying to JBossWS. A migration to a standard is the investment.
How much it will eventually cost, I cannot say. Their WS expert could do
a sample migration of one or two endpoints to get an estimate.
cheers
-thomas
Lucas Ponce wrote:
> Hello again Thomas,
>
> Any thoughts about how costly we can forward to customer in a migration
> from DIME to SwA with JBoss-WS.
>
> Thanks a lot !
>
> Lucas
>
> Lucas Ponce escribió:
>> Thanks Thomas,
>>
>> I'm not very expert in Web Services, your comments are very helpful
>> for me.
>>
>> A hypothetical migration from DIME to SwA and XOP/MTOM, according with
>> your experience, it will be more manual or automatic ? I would like to
>> give them some feedback in term of how costly will be if the decide to
>> move from AXIS to JBossWS.
>>
>>
>> Cheers,
>>
>> Lucas
>>
>>
>> Thomas Diesler escribió:
>>> Hi Lucas,
>>>
>>> we do not support DIME and, which is also not on our roadmap. Instead
>>> we support SOAP with Atachments (SwA) and XOP/MTOM.
>>>
>>> Direct Internet Message Encapsulation (DIME) is a Microsoft-proposed
>>> internet standard for the transfer of binary and other encapsulated
>>> data over SOAP.
>>>
>>> According to the IETF web site, the standard has been withdrawn and
>>> never made RFC status.
>>>
>>> http://en.wikipedia.org/wiki/Direct_Internet_Message_Encapsulation
>>>
>>> Axis (especially 1.x), because of its numerous inherent problems, not
>>> standardized API, poor support for document literal is not supported
>>> in JBoss. A migration to standard J2EE web services (i.e. JAX-WS)
>>> should be considered.
>>>
>>> cheers
>>> -thomas
>>>
>>> Lucas Ponce wrote:
>>>> Hello Thomas,
>>>>
>>>> My name is Lucas Ponce, JBoss Solution Architect, we are doing a
>>>> important Proof of Concept in ING Spain in order to compare us with
>>>> JBoss WebSphere.
>>>>
>>>> JEAP has integrated JBossWS 2.0.1 SP2, please could you confirm me
>>>> if this version support DIME or not ?
>>>>
>>>> This customer uses AXIS 1.4 and they want to reuse this WS engine
>>>> instead of JBossWS.
>>>>
>>>> Thanks a lot,
>>>>
>>>
>>
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
18 years
Re: DIME support on JBoss EAP 4.3
by Thomas Diesler
Hi Lucas,
we do not support DIME and, which is also not on our roadmap. Instead we
support SOAP with Atachments (SwA) and XOP/MTOM.
Direct Internet Message Encapsulation (DIME) is a Microsoft-proposed
internet standard for the transfer of binary and other encapsulated data
over SOAP.
According to the IETF web site, the standard has been withdrawn and
never made RFC status.
http://en.wikipedia.org/wiki/Direct_Internet_Message_Encapsulation
Axis (especially 1.x), because of its numerous inherent problems, not
standardized API, poor support for document literal is not supported in
JBoss. A migration to standard J2EE web services (i.e. JAX-WS) should be
considered.
cheers
-thomas
Lucas Ponce wrote:
> Hello Thomas,
>
> My name is Lucas Ponce, JBoss Solution Architect, we are doing a
> important Proof of Concept in ING Spain in order to compare us with
> JBoss WebSphere.
>
> JEAP has integrated JBossWS 2.0.1 SP2, please could you confirm me if
> this version support DIME or not ?
>
> This customer uses AXIS 1.4 and they want to reuse this WS engine
> instead of JBossWS.
>
> Thanks a lot,
>
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
Web Service Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
18 years