[Building Sakai] cleaning up the Sakai web services

Sun Mar 7 13:55:56 PST 2010

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/20100308/552492e6/attachment.html 