[Building Sakai] cleaning up the Sakai web services
Noah Botimer
botimer at umich.edu
Sun Mar 7 17:06:11 PST 2010
Excellent, Steve. Thanks again for taking on this work carefully.
Thanks,
-Noah
On Mar 7, 2010, at 4:55 PM, Steve Swinsburg wrote:
> Hi Noah,
>
> Yes I understand the scenarios and that it may impact some
> institutions more than others, and in different ways depending on
> their practices. I am particularly aware of the "one man that also
> does a hundred other things" scenario, as at both UNE and ANU, I
> have been in this position.
>
> That being said, in the integrations I've done (UNE, SakaiAdminX,
> ANU) they have only touched the main two: SakaiLogin and SakaiScript.
>
> So the main ones I am now seeking info on are:
> SakaiPortalLogin.jws
> SakaiSession.jws
> SakaiSite.jws
> WSContent.jws
> WSSession.jws
>
> Most of the above ones only have one or two services in them and
> some seem to duplicate existing functionality.
>
> To ease the burden, the services that are still required will be
> migrated as-is (ie no extra parameters), to a more maintainable
> location. They will also stay as Axis 1, so the only thing that
> changes is the service location. No services that are actively
> being used will be going away, which is why I put this call out, to
> get that usage information.
>
> I'll also look at testing and QA'ing the ContentHosting services
> for promotion since they have been around for some time and would
> be a valuable addition. Anyone using these will need to move them
> into the main location anyway, so there would be no change there
> either.
>
> So in summary, I am aware that this may impact some users and in
> different ways. The process will be an easy migration, will be
> clearly communicated, well documented and will not be rushed
> through. I feel that targeting 2.8.0 is a reasonable timeframe to
> implement this change.
>
> As part of the Sakai Maintenance Team, I also want to push
> maintenance costs down, and I believe that once this cleanup is
> done, the ongoing maintenance and testing of the web services will
> be much easier. External applications relying on these services may
> require a minor update, but I would contend that many will not be
> affected at all.
>
> Thanks for your valuable input Noah, I'll add this discussion to
> the JIRA ticket for posterity.
>
> regards,
> Steve
>
>
> On Mon, Mar 8, 2010 at 12:03 AM, Noah Botimer <botimer at umich.edu>
> wrote:
> Steve,
>
> This sounds reasonable but I do want to make a finer point.
>
> Consider an institution with a single admin/hacker running Sakai
> and 100 other things as admin/hackers often do. He doesn't have a
> replicated environment for testing. He often makes riskier moves
> than the large, very experienced shops, working on live wires
> occasionally because of resource constraints. He has some scripts
> he runs when certain kinds of requests come in, to create a site a
> special way, add a list of people (he hasn't implemented a Group
> Provider), and who knows what else. His scripts point at the
> production instance and he tests them in production sample sites.
> Mostly he's "just fine" and "surviving".
>
> Now, consider the same admin in two situations:
>
> 1. Part of some version upgrade is "Update your scripts to point
> here, there, and the other. Call this method differently. The
> signature for addFoo() now includes one more parameter."
>
> 2. Part of some version upgrade is "You should now call these
> things differently because they're going to go away in the next
> version."
>
> My point is that, in situation one (as you suggest), the system
> upgrade and the script upgrades are coupled. He can't port web
> service consumers while the system is running and test them live.
> He has to build this into the (functional) downtime for the upgrade
> in a big bang transition. Sure, he could go pull stuff from trunk
> and drop it in, but he's not sure of what all changed or if there
> is a subtle service dependency difference. Frankly, he doesn't have
> time to track it down and run experiments.
>
> In scenario two, he reads the first version notes and says, "OK.
> I'll have to work on moving those over. I'll probably do it in the
> last two weeks before the next upgrade with the system live and
> I'll get the kinks worked out then.". Because this is a technical
> deprecation where the layers move asynchronously, he can inch
> forward in preparation, and have confidence that he's ready before
> the second upgrade is in the moment.
>
> I'm sorry to belabor this, but we should strive to make work we do
> on Sakai 2.x push maintenance costs down. Synchronized, coupled
> conversions raise costs and make upgrading harder. I'm not going to
> try to say "no, you can't do that", but I will ask you to consider
> this and will trust your judgment. You are, after all, doing the work.
>
> Thanks,
> -Noah
>
>
> On Mar 6, 2010, at 8:12 PM, Steve Swinsburg wrote:
>
> Hi Noah,
>
> The plan was to mark anything I don't receive information about as
> deprecated, and update them to add some logging about them being
> deprecated (maybe even include this logging in 2.7 to give adequate
> notice).
>
> Then, at some point in the 2.8 cycle, move them into an 'archived'
> or 'deprecated' directory. Services that are being used would be
> migrated and documented and implementors would have quite some time
> to update their applications to look at the new location (from now
> until 2.8.0).
>
> So it would be two upgrades away (2.8.0).
>
> cheers,
> Steve
>
>
>
>
>
>
>
>
> On 07/03/2010, at 3:50 AM, Noah Botimer wrote:
>
> Hi Steve,
>
> I think it's great that you're looking to take inventory and give a
> single, consistent place for people to look.
>
> However; I have to urge that nothing be moved/removed in one shot.
> These are part of an external contract that people write their
> tools and scripts against. Copying methods and marking the
> originals as deprecated with a full cycle to port would be fine.
> Making the very next upgrade contingent on porting stuff for
> cleanliness is probably too far, causing unnecessary admin/
> development stress. If I can port things a la carte over a whole
> generation, I'm much happier.
>
> An important point here is that there are no internal consumers of
> these services where we need to make exclusive changes for a fix,
> enhancement, or refactoring. And we can't find/test the consumers.
> I suppose I might say "it ain't broke; improve it but don't break it".
>
> SakaiSigning is definitely used for verification of LinkTool
> launches. See linktool.txt in the top level of the module source.
>
> Your interest and energy here are much appreciated.
>
> Thanks,
> -Noah
>
> On Mar 6, 2010, at 8:46 AM, Steve Swinsburg
> <steve.swinsburg at gmail.com> wrote:
>
> Hi all,
>
> I am looking to cleanup and consolidate the current suite of web
> services, but have a few queries about some of the JWS files that
> are in there.
>
> The main web service sets are:
>
> SakaiLogin - remote login/logout functionality
> SakaiScript - the main set of administrative functions
> Portfolio - portfolio functions
>
> However, there are a number of others which are undocumented and
> sometimes duplicate existing functionality in the main ones above.
> In particular, I would like some information about the following:
>
> SakaiPortalLogin.jws
> SakaiSession.jws
> SakaiSigning.jws - I believe this is used by the LinkTool, but in
> what capacity? I can't find any working reference to it in the code.
> SakaiSite.jws
> WSContent.jws
> WSSession.jws
>
> Are these being used? It seems reasonable that the functionality
> from these could be rolled into either SakaiLogin or SakaiScript,
> which will make maintenance and testing easier, and might bring
> some useful functionality to the general population, or remove them
> entirely, if they are not being maintained/used.
>
> So if you have any information about the state of the above web
> service sets, or are dependent on these locally, can you please let
> me know.
>
> See also: http://jira.sakaiproject.org/browse/SAK-18136
>
> thanks,
> Steve
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-
> unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20100307/15148686/attachment.html
More information about the sakai-dev
mailing list