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
