Hi, Raymond: Thanks for your quick response and detailed explainations. Many confusions in my mind has been solved.
For the client implementation, I am thinking we will use a non-Tuscany client to connect to the SCA domain by web services. It is more closer to our technical background. BTW, you mention that we can model the client as a SCA component. Is that possible for an environment where clients can be plug in/out very frequently? How the other components in the SCA domain locate a specific client? And how the service components react when some notifications want to send to a client while it has gone offline? From this point of view, I have the image that SCA domain best filled with always-online services. Is that feeling right? Thanks, Yang Sun 2008/6/1 Raymond Feng <[EMAIL PROTECTED]>: > Hi, > > Thank you for your interests and good comments about Tuscany. Please see my > comments in line below. > > Raymond > -------------------------------------------------- > From: "Sun Yang" <[EMAIL PROTECTED]> > Sent: Saturday, May 31, 2008 4:57 AM > To: <tuscany-user@ws.apache.org> > Subject: [Help] Two questions on Tuscany SCA > > Hi, all: >> >> Our project want to use Tuscany as the integration middleware, and we do >> some investigation on SCA topics. We still have some confusions on SCA, >> pls >> help us to check whether we are on the right track. >> >> Currently, we are thinking the following deployment models: >> 1. put all services in a single Tuscany domain; >> 2. make some services as front controllers (and exposes them as web >> services) for client to connect; >> 3. non-tuscany client connects to the exposed web-services to access >> business functions. >> > > Your ideas make sense to me. Keep in mind, the SCA domain is a logical > collection of composites and it's the boundary of wiring and management. > Simply speaking, SCA domain is a metadata manager and it manages the > following entities: > > * Contributions: Physical packages that contains artifacts such as Java > classes, WSDL/XSDs, composite files, BPEL scripts. They can be physically > distributed and the SCA domain basically has the knowledge of the URLs. > * Composites: Logical assembly/composition of the service components. > Deployable composites can be declared in contributions or it can generated > at deployment time. > * Nodes: physical runtimes that can run the resolved deployable composites > (Thinking of an image that contains the deployment composite file and the > required contribution URLs). > > How it maps to a physical network of computers depends on the runtime > support. On the boundary of a SCA domain, SCA communicates with external > clients and services using various bindings which represent protocols such > as RMI/IIOP, Web Services and JSONRPC. > > >> Qustions we have: >> 1. Can we join the client to Tuscany domain? Or shall we keep using >> web-services to connect the client to the domain? >> > > The term of "client" is a bit vague :-). If you model/implement a client as > a SCA component, then it can be part of the SCA domain. All the service > composite/components can be physically run on nodes which are hosted by > different machines on the network. We can also model some business function > units as components (for example, implementation.widget or > implementation.ejb) and these components can be run in a container without > SCA. > > The reason for this question is that I cannot find an example in samples >> directory that demonstrate a standard java client startup and join a >> established domain. Did I miss something? >> > > I assume we are talking about a node joining the SCA domain. There are > multiple ways depending on how it's implemented. For example, if we use a > centralized repo to represent a SCA domain, then accessing the repo is > "joining" the domain. If we have a DomainController, then connecting to the > controller and pull images to run is "joining" the domain. If we use > discovery-based approach, then the node broadcasts its presence and > "joining" means it's accepted by the group. > > In Tuscany today, we already have the domain admin application. It can be > used to manage the SCA domain, such as Add/Remove contributions, Add/Remove > deployable composites to SCA domain composite, Add/Remove nodes, Start/Stop > the nodes. Please see the store tutorial: > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/tutorial/. > > >> 2. If stick to the way that non-tuscany client connect to Tuscany domain >> using web-services, we are not sure whether the following solution for >> authentication is correct. The scenario is that we need to do a series of >> communication with the front controller. We don't want to have every ws >> communication with username/password specified. After reading the spec, we >> have the idea of using "conversation scope". pls help us to check whether >> it >> is the standard way to do this kind of authentication job. >> 1) call login(username, password) web services which defines as >> "Conversational" and has the scope of "Conversation". The result will be >> stored in some private variable; >> 2) client calls following business services without attaching the auth >> information (because the auth info is in the conversation scope); >> 3) client calls business services with "endConversation"(such as logout) >> annotation to stop the conversation and exit. >> I am not sure if that is the standard way to do authentication and cache >> the >> result. Could you help us verify it? >> > > I'm not an expert in this area. On the surface, your proposal makes sense > to me. So basically, you want to associate some state (auth data) with the > HTTP session. You can probably use the Conversation-scoped component to keep > the HTTP session. > > >> Tuscany is a really good product. And I really appreciate your help in the >> past few months. >> > > We'll try our best. Helping you out is helping the project itself and the > community. > > >> Best Regards, >> Yang Sun >> >>
