Nadia,
We see a lot of questions on this site that are essentially "tell me how to be a BA, because I know nothing". Your question is actually a very good one, so let's look it over.
Let's start with "JAD" which actually stands dfor "Joint Application Design". Is it really design that is the outcome of the workshop? Or is it Requirements? If that latter, I call that a Requirements Discovery Session.
When it is Requirements, no one from the IT team needs to attend if they are designers or coders or testers. (Sometimes facilitators are from IT too). The key people in the workshop are the Business Users, they are the source of Requirements. (Executive Sponsors are ther to kick-off the workshop, but they don't need to stick around after that.)
You are facilitating, and I assume the scribe is there for real-time documentation of the Requirements, or as close as you can get. In an effective Requirements Discovery Workshops, all the Requirements are captured right then. After you may need to clean up, resolve any outstanding issues, and get the same business users to review before anyone else sees them. Once they agree the requirements were captured correctly, it's done.
After that, the IT team can use the Requirements for estimating and design.
You do certainly do NOT want IT people in your workshop already telling the business users what is doable or not; that will limit what the users will say, and annoy them in some cases. The only exception I make is to allow IT people in the workshop as observers only; they may geniunely be interested in in hearing what goes on. BUT, if they start to participate, I kindly remind them that this workshop is about requirements, not solution, so hold your peace. I have had to ask a sponsor or PM to remove IT people who do not comply. It is tough to do, but necessaryfor the success of the workshop.