Hi Ricky,
Apparently, my approach is strongly discouraged by all the gurus.
Probably I'm an OO nut :-). I should really put more thoughts to this problem.
Delegation to each account from one single webservice is probably a better solution.
I really appreciate comments from all of you guys.
Cheers,
Tuan
-----Original Message-----
From: Ricky Ho [mailto:[EMAIL PROTECTED]]
Sent: 2002/10/01 (火) 23:53
To: [EMAIL PROTECTED]
Cc:
Subject: RE: Dynamic publishing
Your suggested approach is in fact very "heavy-weight" because of the life
cycle management of millions of service instances behind each URL. Passing
along the account id (or any business data for correlation) is a better way
to handle this.
I've observed a pure OO thought is in many times a pitfall for designing
distributed system. OO encourage a fine-grain model which is contradictory
to the coarse-grain model that web services advocating.
Best regards,
Ricky
At 06:42 PM 10/1/2002 +0700, Tuan Le Viet wrote:
>Hi Dug,
>
>I totally agree with you that Axis should just worry about SOAP
>processing, back-end system should deal with other issues.
>My idea is that BankAccount user wouldn't have to pass account ID
>everytime, it would be nicer if account ID will be supplied only once to
>get the reference to Account object (in this case reference is just a
>URL), then during the entire session, user wouldn't have to pass along
>account ID whenever deposit/withdraw/checkBalance is invoked. Account
>object is just a proxy to back-end system though, so it should be
>light-weight.
>
>I reckon this approach is a bit more OO, and doesn't SOAP stand for Simple
>OBJECT Access Protocol?
>
>Cheers,
>
>Tuan Le
>
> -----Original Message-----
> From: Doug Davis [mailto:[EMAIL PROTECTED]]
> Sent: 2002/10/01 (ç«) 18:06
> To: [EMAIL PROTECTED]
> Cc:
> Subject: RE: Dynamic publishing
>
>
>
>
>
>
>
>
> Just my opinion of course, but a couple of things immediately come
to
> mind...lets say you have thousands and thousands of bank accounts
> you're
> looking at having Axis manage a ton of services - which as of now
> I doubt
> it would be really good at. At a minimum you'd need to create a new
> configuration plug-in that should store its list in something
> like a DB -
> something that wouldn't require the entire list to be in memory
> (like I
> believe the current one does). And on the topic of memory - you
> would be
> looking at have Axis create a new instance of each bank account
> object -
> depending on how well the garbage collection is that could be a
> memory hog
> as well. I think it would be a much cleaner approach to just
> have one bank
> account object, and as long as it is thread safe, you can reuse it a
> million times w/o any memory problems. Then just have it look at
> some
> other piece of data (like soap header, rpc param, or
> url(?account=xxxx)) to
> get the actual account number. Let your real back-end system that's
> managing the accounts deal with all of the performance problems of
> thousands of records - let Axis worry about what its supposed to:
> SOAP
> processing. Think of it this way - let's say you were going to
> provide a
> web/html interface for your customers, would you consider a new
> servlet for
> each account? Modifying web.xml everytime a new customer were
> created? I
> doubt (or hope) not. So, why treat web services any differently?
> -Dug
>
>
>
> "Tuan Le Viet" <[EMAIL PROTECTED]> on 09/30/2002 11:48:39 PM
>
> Please respond to [EMAIL PROTECTED]
>
> To: <[EMAIL PROTECTED]>
> cc:
> Subject: RE: Dynamic publishing
>
>
>
> Dug,
>
> My idea was to have a more OO approach. I'll have a manager which
> manages
> lifetime of Account service. Each service will be published when
> necessary
> and unpublished when it's no longer needed.
> This would not be a nightmore for scalability right?
>
> Cheers,
>
> Tuan
>
> -----Original Message-----
> From: Doug Davis [mailto:[EMAIL PROTECTED]]
> Sent: 2002/10/01 (ç«) 8:16
> To: [EMAIL PROTECTED]
> Cc:
> Subject: RE: Dynamic publishing
>
>
>
>
>
>
>
>
> Sorry - missed that, but why would you really want to
> deploy one
> service
> per account? That's going to be a scalability
> nightmare. Why not
> just
> have the account number in a soap header, as a param on an
> rpc call
> or even
> in the URL (ie.
>
>http://localhost:8080/axis/services/BankServices?account=12345 - to
> the
> client the URL is just a string so adding on ?account=12345
> should be
> no
> big deal).
> -Dug
>
>
> "Tuan Le Viet" <[EMAIL PROTECTED]> on 09/30/2002
> 08:17:30 PM
>
> Please respond to [EMAIL PROTECTED]
>
> To: <[EMAIL PROTECTED]>
> cc:
> Subject: RE: Dynamic publishing
>
>
>
> As I understand, jws is just a java source file. Axis will
> publish
> this
> java class as web service automatically.
>
> However, this wouldn't solve my problem as my intention is
> to create
> a web
> service for each instance of the same class.
>
> Cheers,
>
> Tuan
>
> -----Original Message-----
> From: Doug Davis [mailto:[EMAIL PROTECTED]]
> Sent: 2002/10/01 (ç«) 7:06
> To: [EMAIL PROTECTED]
> Cc:
> Subject: RE: Dynamic publishing
>
>
>
>
>
>
>
>
> What about deploying (dropping) a jws file - Aixs
> processes
> that
> dynamically.
> -Dug
>
>
> "Tuan Le Viet" <[EMAIL PROTECTED]> on
> 09/30/2002 07:59:17
> PM
>
> Please respond to [EMAIL PROTECTED]
>
> To: <[EMAIL PROTECTED]>
> cc:
> Subject: RE: Dynamic publishing
>
>
>
> Grant,
>
> It's obviously your solution is a feasible work-around.
> However, as
> you
> stated, it's really a big mess.
>
> Now I consider switching to GLUE which supports dynamic
> publishing
> from the
> beginning. If you're interested, take a look at
> http://www.themindelectric.com
>
> However, I really do hope that there is a clean
> solution using
> Axis.
> Probably in near future.
>
> Cheers,
>
> Tuan
>
> -----Original Message-----
> From: Grant Echols (JanusLogix)
> [mailto:[EMAIL PROTECTED]]
> Sent: 2002/09/30 (月) 22:09
> To: [EMAIL PROTECTED]
> Cc:
> Subject: Re: Dynamic publishing
>
>
>
> Tuan,
>
> I have a similar need but for a totally
> different reason.
> We
> have a
> services
> framework and want to dynamically publish
> public 'service
> entry
> points' at
> runtime through Axis SOAP. We only have a Java
> class file
> and
> an
> associated
> interface as parameters so we have to make up
> the rest of
> the
> difference.
> Right now we're spawning Java2WSDL and
> WSDL2Java back to
> back
> so I
> can get a
> .WSDD file and then call the AdminClient to
> deploy the
> deploy.wsdd
> file. Its
> a mess and I wish there was a better way to do
> this. At
> this
> point we
> were
> too unsure of the deploy.wsdd file format to
> generate it
> ourselves.
> Perhaps
> even having this documented, or having a class
> that we
> could
> instantiate and
> call instead of actually spawning the wsdl...
> utilities
> would
> be
> better. But
> for now, its working...:-(
>
> I'm hoping someone has a better way and will
> respond, but
> if
> you're
> still
> stuck you could possibly consider this route as an
> interim
> solution.
>
> Grant
>
> ----- Original Message -----
> From: "Tuan Le Viet" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Thursday, September 26, 2002 11:13 PM
> Subject: Dynamic publishing
>
>
> > Hi there,
> >
> > Does Axis support "dynamic publishing"?
> >
> > My intention:
> >
> > +I have a class called BankAccount with 3
> methods:
> >
> > +void deposit(int amount)
> >
> > +void withdraw(int amount)
> >
> > +int checkBalance()
> >
> > +I have a class Bank, which have 1 method:
String
> getAccount(String
> accountNo).
> >
> > +I statically publish it as Web service,
> users will
> call
> getAccount
> method
> to get the URL to BankAccount web service, for
> example:
> if user
> called
> getAccount("12345"), URL returned is:
> http://somehost/axis/services/account12345
> >
> > +users then interact with this BankAccount
> webservice
> to
> deposit,
> withdraw, checkBalance.
> >
> > +In order to achieve this, it's required to
> dynamically
> publish
> each
> BankAccount instance as a web service.
> >
> > Is this possible with Axis?
> >
> > I would really appreciate any pointers.
> >
> > Cheers,
> >
> > Tuan
> >
> >
> >
> >
> >
> >
>
>
>
<<winmail.dat>>
