[WSM] Is it possible for a java interface to be a service endpoint interface ?

[wo...@yahoo.co.jp]

Hi there,

I've been thinking about the validate method of Jsr181TypeMetadataImpl.java 
to be better these days.
And one consideration came up with the service endpoing interface.

A java interface can be an endpoint interface with the current Jsr181TypeMetadataImpl class. 
In other words, the java interface is published by web service (WSDL).

A normal java interface , of course, cannot be instantiated by Axis so that 
if a client accesses the web service, Axis will throw an exception.

Why I mentioned a NORMAL java interface is that it makes sence if the endpoint 
interface is an EJB remote interface. Because the EJB container and Servlet container
 know the corresponding implementation bean ( EJB ) should be used by ejb-jar.xml, web.xml.

How is it supposed to be ?

My thought is as follows.
If the endpoint interface is a normal java interface, the validate method should throw 
an exception.
If the endpoint interface is an EJB remote interface, the validate method should let it go.

what do you guys think ?

Thanks in advance.

Wolfgang.

RE: [WSM] Is it possible for a java interface to be a service endpoint interface ?

[Ias <ia...@hotmail.com>]

FYI,

I'd like to sum up the current situations in Java standards regarding SEI.

1. JAX-RPC 1.1 (and 2.0)

SEI must extends java.rmi.Remote and each operation in SEI must throw
java.rmi.RemoteException

2. WSM 1.0

Quite interestingly, SEI in WSM doesn't require Remote features like
#1.(Even SEI itself is optional.)

3. EJB 3.0

I used JBoss EJB 3 (PR2) and found that there was no facility for web
services yet. It is said that still there needs to be more discussion on
integration between EJB 3.0 and WSM. Basically EJB 3.0 follows policies of
WSM 1.0 because it's designed to go along with WSM. In terms of EJB 2.1 with
EWS (JSR 109), you need to declare SEI apart from RI in order to expose a
session bean as a web service. The SEI concept of EJB 2.1 is the same with
that of JAX-RPC 1.1.

Therefore, we can think of the following scenarios: 

If a developer deploys a SIB (based on either servlet class or EJB session
bean) without SEI on a (WSM+JAX-RPC)-enabled server, the WSM processor
generates a JAX-RPC-compliant SEI corresponding to the SIB. 

If a developer deploys a SIB with a SEI (based on WSM 1.0 and EJB 3.0) on
the server, the WSM also generates a JAX-RPC-compliant SEI from the given
SEI.

By the way, I'm now writing an article on Beehive for a Korean programming
journal (Dec issue). Thanks you all for your great work so far. Especially,
1.0 alpha distribution helps me (and will help readers as well) a lot :-)

Ias

> -----Original Message-----
> From: wolfgang127us@yahoo.co.jp [mailto:wolfgang127us@yahoo.co.jp] 
> Sent: Friday, November 19, 2004 3:01 PM
> To: Beehive Developers
> Subject: [WSM] Is it possible for a java interface to be a 
> service endpoint interface ?
> 
> Hi there,
> 
> I've been thinking about the validate method of 
> Jsr181TypeMetadataImpl.java to be better these days.
> And one consideration came up with the service endpoing interface.
> 
> A java interface can be an endpoint interface with the 
> current Jsr181TypeMetadataImpl class. 
> In other words, the java interface is published by web service (WSDL).
> 
> A normal java interface , of course, cannot be instantiated 
> by Axis so that if a client accesses the web service, Axis 
> will throw an exception.
> 
> Why I mentioned a NORMAL java interface is that it makes 
> sence if the endpoint interface is an EJB remote interface. 
> Because the EJB container and Servlet container  know the 
> corresponding implementation bean ( EJB ) should be used by 
> ejb-jar.xml, web.xml.
> 
> How is it supposed to be ?
> 
> My thought is as follows.
> If the endpoint interface is a normal java interface, the 
> validate method should throw an exception.
> If the endpoint interface is an EJB remote interface, the 
> validate method should let it go.
> 
> what do you guys think ?
> 
> Thanks in advance.
> 
> Wolfgang.
> 
> 
> 
> 
>