Re: Workflow impasse? and more
Thanks Martin. Time permitting I would still like to bore you with my ha'penny's worth! I hope to post my ideas on both Workflow and Security in the next few days - I managed to put aside some time yesterday for reading the specs properly and as soon as I have cemented my ideas I'll let everyone know ;) Nic - Original Message - From: "Martin Cooper" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 26, 2001 5:29 AM Subject: Re: Workflow impasse? and more > Nic, > > I've removed your name from the to-do sections per your request. However, I > hope we'll still see your comments and suggestions in these areas as they > develop. > > Regarding workflow, I look forward to hearing your thoughts on handling > multi-page forms, and how this might relate to a more general workflow > solution. > > -- > Martin Cooper > > _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
Re: Workflow impasse? and more
Nic, I've removed your name from the to-do sections per your request. However, I hope we'll still see your comments and suggestions in these areas as they develop. Regarding workflow, I look forward to hearing your thoughts on handling multi-page forms, and how this might relate to a more general workflow solution. -- Martin Cooper - Original Message - From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, July 25, 2001 2:23 AM Subject: Re: Workflow impasse? and more > > Hi All, > > Well I've finally got around to moving my struts subscriptions to a > different address so I can setup rules etc to manage the number of mails on > the lists! Moving them away from my work mail address is a good thing... > > So why am I telling you all this? Well I , like Craig T, signed up for > several areas on the 1.1 Todo list a while back and like Craig have been > busy with work and being away on holiday and training. So keeping up with > the volume of mail has been difficult let alone contributing anything > constructive. So I, like Craig, am going to have to cut down what I am > involved in to make it fair to others and be able to contribute properly > without spreading myself too thin. So I am going to back out of the > following areas for the following reasons: > > Standard Validations & Client Side Validations - because I have not > done the work I expected to in this area and therefore feel I probably > shouldn't buttin on these! > EJB Design Patterns - for similar reasons. Although I have been > working with EJBs I think there are others who are better qualified to lead > this piece. > > > I will of course contribute where possible to these areas but feel I > am unable to lead them or take a direct role in designing/writing these. > > > Which leaves the following: > Multi-page form support - I think this really may tie in with the > Workflow processing > Workflow processing - I am working on workflow at the moment from > a 'backend' perspective i.e. at the EJB layer which I hope will help cement >my ideas for the Struts workflow. More on this later. > Role-based Action Execution - I have been looking at JAAS and > security in general and need to look into the specs a bit more to > understand what _must_ be supported by containers and what > _tends_ to be supported before we make a decision on exactly where to go > withthis. Again more later. > > I hope this will enable to contribute more than I have in the past and get > things moving. Apologies for anyone expecting me to take the others areas > through to completion. > > So on to Workflow. > As Ted suggests I also believe the fundamentals are there in the > framework already. There have been several discussions about exactly what > the workflow piece is but I think Ted's implications are the best. I don't > think we are trying to design something that is a GUI nor are we trying to > make something that conforms to standards which are in their infancy. This > is not to say that support for products ( I think Visio for instance was > suggested) should not come later but I think this is in addition to the > underlying functionality which is to link Actions together to form a > business process with pre- and post-requirements. This is where the thought > on the multi-page forms comes in. I have been thinking about this a lot > lately and have a few ways of doing this which when I cement them a little > more will post here. > > I think we need to get down a solid set of requirements ( I think Ted's are > a good start) and be clear what we are trying to achieve (I have tried to > outline my view above) before we can proceed and I will take a proper look > at the code examples Ted outlines in his mail. Much of the discussion so > far has been on several tracks all under the global term 'workflow'. > (Please don't take any of this as criticism - I am aware I haven't > contributed much up until now - just observations and an attempt to get > this going). So any comments on what we are trying to achieve and how? (and > I am waiting for the slap too... ;) > > And then the security thing > > I have been primarily working with BEA Weblogic and working on a banking > system so security has been key. We have had various discussions with BEA > and finally got some answers so I have a clear idea of how BEA do things > and how we may be able to fit this in to struts. What is currently not > clear and Craig M has alluded to before is that the specs aren't really > explicit in this area and each application server ten
Re: Workflow impasse? and more
Hi All, Well I've finally got around to moving my struts subscriptions to a different address so I can setup rules etc to manage the number of mails on the lists! Moving them away from my work mail address is a good thing... So why am I telling you all this? Well I , like Craig T, signed up for several areas on the 1.1 Todo list a while back and like Craig have been busy with work and being away on holiday and training. So keeping up with the volume of mail has been difficult let alone contributing anything constructive. So I, like Craig, am going to have to cut down what I am involved in to make it fair to others and be able to contribute properly without spreading myself too thin. So I am going to back out of the following areas for the following reasons: Standard Validations & Client Side Validations - because I have not done the work I expected to in this area and therefore feel I probably shouldn't buttin on these! EJB Design Patterns - for similar reasons. Although I have been working with EJBs I think there are others who are better qualified to lead this piece. I will of course contribute where possible to these areas but feel I am unable to lead them or take a direct role in designing/writing these. Which leaves the following: Multi-page form support - I think this really may tie in with the Workflow processing Workflow processing - I am working on workflow at the moment from a 'backend' perspective i.e. at the EJB layer which I hope will help cement my ideas for the Struts workflow. More on this later. Role-based Action Execution - I have been looking at JAAS and security in general and need to look into the specs a bit more to understand what _must_ be supported by containers and what _tends_ to be supported before we make a decision on exactly where to go withthis. Again more later. I hope this will enable to contribute more than I have in the past and get things moving. Apologies for anyone expecting me to take the others areas through to completion. So on to Workflow. As Ted suggests I also believe the fundamentals are there in the framework already. There have been several discussions about exactly what the workflow piece is but I think Ted's implications are the best. I don't think we are trying to design something that is a GUI nor are we trying to make something that conforms to standards which are in their infancy. This is not to say that support for products ( I think Visio for instance was suggested) should not come later but I think this is in addition to the underlying functionality which is to link Actions together to form a business process with pre- and post-requirements. This is where the thought on the multi-page forms comes in. I have been thinking about this a lot lately and have a few ways of doing this which when I cement them a little more will post here. I think we need to get down a solid set of requirements ( I think Ted's are a good start) and be clear what we are trying to achieve (I have tried to outline my view above) before we can proceed and I will take a proper look at the code examples Ted outlines in his mail. Much of the discussion so far has been on several tracks all under the global term 'workflow'. (Please don't take any of this as criticism - I am aware I haven't contributed much up until now - just observations and an attempt to get this going). So any comments on what we are trying to achieve and how? (and I am waiting for the slap too... ;) And then the security thing I have been primarily working with BEA Weblogic and working on a banking system so security has been key. We have had various discussions with BEA and finally got some answers so I have a clear idea of how BEA do things and how we may be able to fit this in to struts. What is currently not clear and Craig M has alluded to before is that the specs aren't really explicit in this area and each application server tends to do things in its own way. So I intend to look at the specs a little more to see what they should at least all support and then work on whether we want to link something into that or produce a struts specific implementation ( which obviously should abstract things so that people can plug in their app server specific stuff if necessary, although Struts is unlikely, at least at this stage, to support this 'out-of-the-box'.) As the saying goes...I'll be back... I hope I haven't stepped on anyone's toes here and I hope I can contribute properly in the future which I haven't been able to up until now due to other commitments. Could I ask someone who has commiter privs to remove me from the areas above on the todo list? Many thanks, Kind regards and keep up the good work! Nic Ted Husted
