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
