Types of Deployment (Re: Thoughts about .jws deployment)

[Yuhichi Nakamura <NA...@jp.ibm.com>]

Folks,
I am wondering how many ways of deployments we should consider.
1. Use AdminClient + Java classes
2. Use AdminClient + jws files
I am not sure if they are real deployments.  How Java classes and jws files
are deployed?  I am also concerd with the jws approach in some case.
It may compile jws on the file, so a permission should be given the user to
write the class file on the server.  This would cause some security
problem.
I coudl imagine the following appoach:
3.Create a war (or ear) file which includes Java classes (and jws files)
and
deployment descriptor.
I don't know why we do not have the third one.  This is most portable, and
simplest.  1 and 2 are more advanced.
Is there any other way for deployment?
Best regards,

Yuhichi Nakamura
IBM Tokyo Research Laboratory
Tel: +81-462-73-4668


From: "Glen Daniels" <gd...@macromedia.com> on 2001/05/27 07:38

Please respond to axis-dev@xml.apache.org

To:   <ax...@xml.apache.org>
cc:
Subject:  Thoughts about .jws deployment




The current system we have for dropping *.jws files into the web space to
deploy services is very cool, but could be better.  One of the nice things
that the .NET equivalent of this (*.asmx files) can do, because they
control
the compiler technology, is insert various deployment "hints" into the asmx
file.  For instance, they can specify which methods are "WebMethods" and
which ones are not exposed to the web service engine.

I'd like to see the ability to "tweak" the deployment of a jws service in
this way, and perhaps in other ways as well (for instance, custom
typemappings).  I see two possible techniques for doing this:

1) Use a preprocessor to embed deployment hints directly in the java file,
in comments.  This would be sweet, but would potentially be a bunch of
work.

2) Have the server look for a companion "*.jwd" (java web deployment) file
in the same directory as the .jws file.  This file, if it exists, would be
an XML file containing some deployment config/options for the service.

Example -

Foo.jws:
public class Foo {
   public String method1()
   { return "Hi, I'm method 1!"; }

   public String method2(int seekrit_number)
   { return "The seekrit number was " + seekrit_number; }
}

Foo.jwd:
<deploy>
 <method>method1</method>
</deploy>

This would only allow remote SOAP access to method1.

Thoughts?

--Glen

Re: Types of Deployment (Re: Thoughts about .jws deployment)

[Sam Ruby <ru...@nc.rr.com>]

Yuhichi Nakamura wrote:
>
> Folks,
> I am wondering how many ways of deployments we should consider.
> 1. Use AdminClient + Java classes
> 2. Use AdminClient + jws files
> I am not sure if they are real deployments.  How Java classes and jws
files
> are deployed?  I am also concerd with the jws approach in some case.
> It may compile jws on the file, so a permission should be given the user
to
> write the class file on the server.  This would cause some security
> problem.

Do you consider JSP a security problem?

Re: Types of Deployment (Re: Thoughts about .jws deployment)

[Glen Daniels <gd...@macromedia.com>]

Hi Yuichi!

> Folks,
> I am wondering how many ways of deployments we should consider.
> 1. Use AdminClient + Java classes
> 2. Use AdminClient + jws files
> I am not sure if they are real deployments.  How Java classes and jws
files
> are deployed?  I am also concerd with the jws approach in some case.
> It may compile jws on the file, so a permission should be given the user
to
> write the class file on the server.  This would cause some security
> problem.

Not any more so than deploying any other backend.  Even if I can't directly
write new classes, I might be able to expose methods on "System" as a web
service....(speaking of which, we may want to have a way to restrict which
classes can be deployed)  You need to secure the admin service in any case.

> I coudl imagine the following appoach:
> 3.Create a war (or ear) file which includes Java classes (and jws files)
> and
> deployment descriptor.
> I don't know why we do not have the third one.  This is most portable, and
> simplest.  1 and 2 are more advanced.

This is in our requirements doc, and also the to-do list.  I think we'll
definitely want something like this.

> Is there any other way for deployment?

There will likely be other tools which will use the back-end APIs to deploy
services from GUIs, web infrastructures, etc.

--Glen