Senaka Fernando wrote:
Senaka Fernando wrote:
Hi Samisa, Manjula, and Milinda,
Yes, this is what we should be doing. But, we do have users who use
Axis2/C server side with .NET or Java client side. Just within the last
week only I replied to two people on the user list. Their concern is
about
using the C service with say a .NET client.
These users are beginners when it comes to WS. They need wsdl files to
be
there so that they can access our services from clients in other
languages. I think we must be helpful to such people too.
This doesn't mean we need the static WSDLs deployed per service. But, at
least a WSDL file for each service. That is my concern.
How does having wsdls for all services solve that problem? I think it
would not solve the situation.
What they want is writing a service with a WSDL, and they can use the
WSDL2C tool to do that. And all that we need to have is a single sample
to show how to do that. Bloating all samples with WSDLs does not solve
the problem.
I agree to this fact. But, the intention is to assist a user who wants to
try to the Axis2/C server side using a .NET or Java client.
According to the present situation, users are either forced to first write
a .NET/Java service and generate a wsdl, or else to use some popular wsdl
available online.
So the single sample with the WSDL solves that problem. At the same
time, if you want to write a real service with Axis2/C, users need to
learn that they have to generate a WSDL. Providing a WSDL with samples
is not going to solve that problem.
I think we must not make things so complicated for someone who's a
beginner. At least the three services, echo, mtom and notify, do need
WSDLs.
That is my exact point as well. The stuff as it is now are simple enough
and adhere to the seperation of concerns principle. The WSDL sample will
serve the idea of working with WSDL.
This is crucial, especially for folks who need to tryout Axis2/C and make
a choice whether they could use Axis2/C as the server side.
Also, this scenario here is not writing a service out of a WSDL but,
rather trying out our server side with another client. On the other hand,
it is a known fact that Axis2/Java is also required to get the codegen
tool running.
The WSDL sample will serve that problem. Also, the echo sample is
written in such a manner that it will work with the Java client out of
the box.
Therefore, once we get the default WSDL location scenario working, I
believe that we can make WSDLs for popular sample services such as echo,
mtom, and notify and have them deployed too, without much of a hassle.
I would not rather add a WSDL to the simple samples. When the echo
sample servers a WSDL, people would come to he incorrect understanding
that we have WSDL generation. The fact that echo will not serve a WSDL
would bring them to know that we do not have C2WSDL. Then they will look
around why no WSDL, then they will learn the reality. So in my view,
current model is ideal and educating, and will not fool the user to
features that we do not have.
So current samples as they are serve the purpose - first they help the
user to run the first client and service. Then they learn that they need
to do more, come to know the limitations and then get to know how to do
that.
Samisa...
Regards,
Senaka
Samisa...
Regards,
Senaka
On Fri, 2008-03-07 at 12:52 +0530, Samisa Abeysinghe wrote:
People just want to try the wsdl serving and know how to do that with
a
service. I do not think it is a good idea to add more features to
existing samples and take away the key message out of the samples. As
an
example so SOAP 1.1 we have a seperate sample, so does rest. We can
easily add those to one sample and make is a "one stop shop" sample.
However the idea is to "KISS", and not to clutter the samples with
overloaded information.
Samples are for absolute beginners, not to those who want to do more.
For those who want to d more, there are docs and header files to
figure
things out.
Absolutely +1 .
Samisa...
Senaka Fernando wrote:
Hi Samisa,
We have the necessary resources to get started with the Calculator
sample.
I will change the wsdl location etc. and get this organized.
Afterwards, I
will document this on the Axis2/C Manual.
But, I strongly believe that it would be better to have WSDLs for
atleast
these samples,
1. Echo (this is the most primitive "does it work well?" test)
2. Mtom (to test interoperability users may need this)
3. Notify (the only OUT-ONLY sample we have)
math/sg_math may not be necessary, but, they are the only services
left out.
Regards,
Senaka
It is a good idea to have a sample that shows how to do that.
However, I
do not think that we have to demo this for all samples. We can just
have
one sample that shows hot to do that.
Samisa...
Senaka Fernando wrote:
Hi devs,
Axis2/C supports contract first approach IIRC. Thus, it would be
better
if
we could provide WSDLs for each sample service. This is necessary
as
there
are users who use Axis2/C server side with various other clients.
It
also
will broaden our capabilities in interop testing.
Once this is done, we have to make sure that we provide the static
.wsdl
path for each sample in the corresponding services.xml. This should
be
more or less similar to how we setup the policy files of the
secpolicy
samples in Rampart/C if you are familiar.
I'm looking forward to document the use of a static .wsdl file for
each
service sample, and before that could be done it is better if we
could
make $subject available.
Hope to see these before the next release.
Regards,
Senaka
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Samisa Abeysinghe
Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Samisa Abeysinghe
Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Samisa Abeysinghe
Software Architect; WSO2 Inc.
http://www.wso2.com/ - "Oxygenating the Web Service Platform."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
