RE: Beginner Question - Deploying components on the fly.

["Miles, Chris" <ch...@spsa.pnn.police.uk>]

Hi, thanks very much for a response. I will try explain this better.

In a traditional J2EE application like many I have worked on in the past
the way I would normally develop them in a EJB sense is: Firstly I would
develop my DAO components - EJB Entity beans for example. I would then
develop my business layer components - EJB Session beans for example. I
would then develop a web application which using JNDI would be able to
look up the beans and use them. If I made a change to just one of the
DAO components all I would need to do is drop it into the server's
(JBoss) deploy directory and the container would load the bean and make
it available to my business layer, and indeed any other business layer
components which would use it.

Trying to go for more lightweight development, I am making a transition
away from EJBs (more so Entity beans) as the development and
maintainability of them is too high. At the moment I am using a lot of
lightweight Hibernate DAOs, but I am building and deploying my entire
source tree as one task. 

I would like to break these various parts back down into components
which I can freely change about required. So for example I would like to
have my Hibernate DAO implementations as components which implement a
specific interface, likewise I may have plain JDBC DAO implementations. 

The way I see this is as follows (broken into a very simple example): 

I have two web applications: "WebApp1" and completely separate
"WebApp2", and I want both of them to be able to use the same component.
The two web apps are contained within their own war/ear etc. How do I
start implementing a shared component which both of the web applications
can use?

I hope that makes a little more sense.

Thanks

Chris

RE: Beginner Question - Deploying components on the fly.

["Miles, Chris" <ch...@spsa.pnn.police.uk>]

Thanks again,

By including all of the Tuscany jars do you mean the runtime jars or the
component jars (i.e. the web app and components need to be packaged
together)

Chris

Re: Beginner Question - Deploying components on the fly.

[Simon Laws <si...@googlemail.com>]

Hi Crhis

snip...

>
>
> I can see how the samples are working, as Tuscany has automatic access
> to the files required as they are included within the same jars, but
> assume I have a DAO component which implements a service
> HibernateProductDAO which provides a Hibernate specific implementation
> of the ProductDAO interface. If our full application is deployed in a
> component oriented fashion, then ideally I would like to be able to
> say... ok this single component needs a bug fix. Fix the bug and
> repackage this single component and redeploy.


At the moment our deployment granularity is at the composite level rather
than the component level. As long as you build a composite with just the
HibernateProductDAO component in it you will be able to deploy this
component in isolation. You are not restricted to any particular number of
composites in your application. Components from one composite can reference
components in another composite, composites can be included in other
composites, composites can be assembled recursively using
implementation.composite.



> So say
> HibernateProductDAO_1.5.jar is sitting with component contained within
> (and a composite mapping?) and I would like to get this into my
> application. Would it be as simple as dropping it within the shared
> lib/classpath of the webcontainer and will Tuscany be able to find it?


Replacing a component with a bug fixed implementation implies stopping and
restarting the component. As your component is wrapped in a single composite
this can be as simple as stopping and restarting the node that is running
the composite that holds the HibernateProductDAO component. This will work
today if you are running Tuscany from some command line launcher. It may
even work if you are deploying as a webapp. The deep integration isn't done
yet so the webapp will have to include all of the Tuscany jars.


>
>
> Thanks again
>
> Chris
>

I think we should start to get a little more specific...

A) We might have a composite for the DAO...

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"
    xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
    targetNamespace="http://test"
    xmlns:test="http://test"
    name="dao">

    <component name="ProductDAO">
        <implementation.java class="product.impl.HibernateProductDAOImpl" />
        <service name="ProductInfo">
            <interface.java interface="product.ProductDAO"/>
            <tuscany:binding.jsonrpc uri="http://myhost:8080//ProductInfo"/>
        </service>
    </component>
</composite>

B) And another composite for the client app

<composite    xmlns="http://www.osoa.org/xmlns/sca/1.0"
        xmlns:tuscany="http://tuscany.apache.org/xmlns/sca/1.0"
        targetNamespace="http://test"
        name="client">

    <component name="Products">
        <tuscany:implementation.widget location="uiservices/product.html"/>
        <service name="Widget">
            <tuscany:binding.http uri="/ui"/>
        </service>
        <reference name="productDAO">
             <tuscany:binding.jsonrpc uri="http://myhost:8080//ProductInfo">
         </reference>
    </component>
</composite>

C) And some javascriptin the browser which exercises this

<html>
<head>
<title>Store</title>

<script type="text/javascript" src="products.js"></script>

<script language="JavaScript">

    //@Reference
    var products= new Reference("productDAO");

etc..


I haven't actually run this so there may be typos but let me explain...

A) is deployed as a stand-alone contribution to some runtime (could be
webapp or could be standalone). The result of running up the "dao" composite
is an a live service at the endpoint http://myhost:8080//ProductInfo. This
endpoint will respone to JSONRPC requests.

B) and C) are wrapped together into a war contribution (along with all of
the Tuscany jars) and deployed to a webapp container. When the webapp starts
up you can point you browser at
http://myhost:8080/mywebapp/uiservices/product.html. This will return
javascript C) and, on the fly, build the javascript "products.js" which
contains the references for the Products component from B). The reference in
B) happens to refer to our ProductDOA componenent service that is running
elsewhere. Hence the javascript in the browser can talk directly to the
ProductsDOA service.

If we chose to stop and restart the runtime running the "dao" composite. Say
if we wanted upgrade it. We could do that without affecting the client
component as long as the resulting service comes back with the endpoint
http://myhost:8080//ProductInfo.

The same pattern works for any component that references another component.
I used a fairly complicated widget component implementation here that we use
for creating web2.0 type applications where the browser talks directly to
back end services. You can of course have server side UI generating
component doing the same job.

make any sense?

Regards

Simon

RE: Beginner Question - Deploying components on the fly.

["Miles, Chris" <ch...@spsa.pnn.police.uk>]

Hi,

Thanks again for the reply. I think we are nearly reaching a point of
agreement on this; however I am still unsure of how some of the
intricacies will work. 

I can see how the samples are working, as Tuscany has automatic access
to the files required as they are included within the same jars, but
assume I have a DAO component which implements a service
HibernateProductDAO which provides a Hibernate specific implementation
of the ProductDAO interface. If our full application is deployed in a
component oriented fashion, then ideally I would like to be able to
say... ok this single component needs a bug fix. Fix the bug and
repackage this single component and redeploy. So say
HibernateProductDAO_1.5.jar is sitting with component contained within
(and a composite mapping?) and I would like to get this into my
application. Would it be as simple as dropping it within the shared
lib/classpath of the webcontainer and will Tuscany be able to find it? 

Thanks again

Chris

Re: Beginner Question - Deploying components on the fly.

[Simon Laws <si...@googlemail.com>]

Hi Chris

Some more thoughts and some comments in line..

A service is defined by a contract/interface and collects together a set of
related operations. A service may provide an endpoint through which remote
clients can access it over the network
A component provides the implementation for one or more services and in
doing so can define references to other services
A composite assembles together components into a working application by
wiring references to services
A contribution is the deployment packaging for a composite and can collect
together the composite and all of the artifacts it requires to run, e.g.
.java, .xml, .xsd. wsdl files etc.

A contribution in SCA can be any hierarchical mechanism the we use today for
collecting artifacts together, e.g. a directory on a file system, a zip, jar
or war etc. A contribution does not define a new format for storing
artifacts.

Hope this helps

Simon


On Fri, Jun 6, 2008 at 4:29 PM, Miles, Chris <ch...@spsa.pnn.police.uk>
wrote:

> Simon,
>
> Thanks for the response again.
>
> I understand a little better now; however some parts of it still leave
> me a little stumped. How these physical units would be packaged and
> moved around.


They should be packaged in whatever schemes you are familiar with today for
collecting together application artifacts for deployment. The exact
mechanism chosen will depend on which container is going to run the SCA
application. E.g. if its going to run in a web app container the
contribution is likely to be a war. If its going to be run using a command
line based Tuscany runtime then the contribution could well be a directory
structure or a jar.


>
>
> If I have a webapp with JSP, Servlets and the other usual bits and bobs.
> This would be packaged in it's normal war and deployed to the server
> (which happens to be OC4J just now).
>

Yep


>
> I then want a business layer as a component. If this was being deployed
> somewhere there would need to be some sort of intelligent process which
> picks it up and registers it somewhere. I suppose a quartz job or a
> timertask running checks against the file system could do something to
> this effect, but it feels I would then be adding extra layers of
> complexity to my application.


Are you suggesting here that components are deployed and activated in the
same way that  wars are activated,  for example, in Tomcat by dropping the
war into the tomcat/webapps directory.

There are two approaches.

1. add the Tuscany and dependency jars to the war itself. This should work
today. See samples/calculator-webapp
2. do some deep integration with the web app container so that the Tuscany
and dependency jars don't have to be added to the war. Ant is looking at
this for Tomcat at the moment but it's not done yet.

It's not the only way of working with Tuscany though. For example, you can
just run Tuscany from the command line and ask it to run up a named
composite, This works because if Tuscany is not running within a webapp
container it will fire up its own web server (tomcat or jetty) to service
web service style requests. See samples/calculator for our most basic sample
and samples/helloworld-ws-service and samples/helloworld-ws-reference for a
reference that talks to a service remotely over web services.



>
> The way I feel something like this should work for my purposes is a
> standalone daemon running which manages services and components etc (I
> am not completely understanding of the exact difference in definition
> between components, service and contributions I will be honest).


See above:-)

The standalone daemon I think is catered for by running Tuscany from the
command line. This doesn't support the hot deploy options (although again
there has been some work on this in the past). You basically run Tuscany
given the composite when you want to start a composite application and the
stop the program when you want to stop the application.

This
> daemon would be have a store of components which it loads when it runs
> or they are hot deployed and then any other application or web
> application through the use of the Tuscany library can then start
> creating objects which this server will provide. This standalone server


"Start using services" is probably a better phrase that "start creating
objects".  Using a service may or may now involve creating new objects. This
depends on the scope of the component and the type of processing the
component does. In the case where you are reading business object from a
database I can imagine that the business object we be created when you make
a request for information. The component instance may or may not be created
afresh depending on whether you want the component to display some stateful
behaviour, for example, so that you can hold a conversation with it.


> may be some other application which could be deployed to the web
> container/sever instead of a separate running process.


Yes, once you have  defined your composite application you should be able to
deploy it either as a web app or using Tuscany running from the command
line.


>
> If I am way off the mark on the merits of SCA then please let me know,
> but all I know is I am trying to get a more lightweight version of the
> old JNDI lookup of beans within my web container. :)


Doesn't sound like you are way off. I think we need to convince ourselves we
are talking the same language;-)


>
> Any other ideas or suggestions would be greatly appreciated.
>
> Thanks again
>
> Chris
>

RE: Beginner Question - Deploying components on the fly.

["Miles, Chris" <ch...@spsa.pnn.police.uk>]

Simon,

Thanks for the response again.

I understand a little better now; however some parts of it still leave
me a little stumped. How these physical units would be packaged and
moved around.

If I have a webapp with JSP, Servlets and the other usual bits and bobs.
This would be packaged in it's normal war and deployed to the server
(which happens to be OC4J just now).

I then want a business layer as a component. If this was being deployed
somewhere there would need to be some sort of intelligent process which
picks it up and registers it somewhere. I suppose a quartz job or a
timertask running checks against the file system could do something to
this effect, but it feels I would then be adding extra layers of
complexity to my application.

The way I feel something like this should work for my purposes is a
standalone daemon running which manages services and components etc (I
am not completely understanding of the exact difference in definition
between components, service and contributions I will be honest). This
daemon would be have a store of components which it loads when it runs
or they are hot deployed and then any other application or web
application through the use of the Tuscany library can then start
creating objects which this server will provide. This standalone server
may be some other application which could be deployed to the web
container/sever instead of a separate running process. 

If I am way off the mark on the merits of SCA then please let me know,
but all I know is I am trying to get a more lightweight version of the
old JNDI lookup of beans within my web container. :)

Any other ideas or suggestions would be greatly appreciated.

Thanks again

Chris

Re: Beginner Question - Deploying components on the fly.

[ant elder <an...@gmail.com>]

On Fri, Jun 6, 2008 at 3:51 PM, Simon Laws <si...@googlemail.com>
wrote:

> On Fri, Jun 6, 2008 at 3:15 PM, Miles, Chris <
> chris.miles@spsa.pnn.police.uk>
> wrote:
>
> > Hi, thanks very much for a response. I will try explain this better.
> >
> > In a traditional J2EE application like many I have worked on in the past
> > the way I would normally develop them in a EJB sense is: Firstly I would
> > develop my DAO components - EJB Entity beans for example. I would then
> > develop my business layer components - EJB Session beans for example. I
> > would then develop a web application which using JNDI would be able to
> > look up the beans and use them. If I made a change to just one of the
> > DAO components all I would need to do is drop it into the server's
> > (JBoss) deploy directory and the container would load the bean and make
> > it available to my business layer, and indeed any other business layer
> > components which would use it.
> >
> > Trying to go for more lightweight development, I am making a transition
> > away from EJBs (more so Entity beans) as the development and
> > maintainability of them is too high. At the moment I am using a lot of
> > lightweight Hibernate DAOs, but I am building and deploying my entire
> > source tree as one task.
> >
> > I would like to break these various parts back down into components
> > which I can freely change about required. So for example I would like to
> > have my Hibernate DAO implementations as components which implement a
> > specific interface, likewise I may have plain JDBC DAO implementations.
> >
> > The way I see this is as follows (broken into a very simple example):
> >
> > I have two web applications: "WebApp1" and completely separate
> > "WebApp2", and I want both of them to be able to use the same component.
> > The two web apps are contained within their own war/ear etc. How do I
> > start implementing a shared component which both of the web applications
> > can use?
> >
> > I hope that makes a little more sense.
> >
> > Thanks
> >
> > Chris
>
>
> Hi Chris
>
> Yes, that helps me a lot. So in your example you have
>
> WebApp1
> WebApp2
> BusinessApp3
>
> Where WebApp1 and WebApp2 both use a component service provided by
> BusinessApp3
>
> Let's assume that these are 3 independent SCA contributions and that the
> WebApp1 and WebApp2 are going to communicate with BusinessApp3 over some
> remote binding such as binding.rmi.  There are a couple of ways that I
> believe you can make this work for you today with Tuscany.
>
> 1) Based on you knowledge of where you are going to deploy these as you
> develop them you can manually configure binding.rmi definitions in the
> composites in each of these contributions to so that the references can
> find
> the services. You can then deploy WebApp1, WebApp2 and BusinessApp3 and use
> the. You can of course stop and restart BusinessApp3 and expect WebApp1 and
> WebApp2 to still work assuming that the interface that service interfaces
> in
> BusinessApp3 haven't changed. This is a very static approach but should
> work.
>
> 2) Use our domain manager to handle the configuration for you. Exactly the
> same thing that you did in 1) will happen under the covers but the domain
> manager will set up the binding URIs for you.
>

and 3) use some sort of deep integration like runtime-tomcat or the
geronimo/tuscany integration so webapps can use a share an SCA domain. This
sounds similar to what was being asked for in
http://apache.markmail.org/message/ttssxoruzpndkado.

    ...ant

Re: Beginner Question - Deploying components on the fly.

[Simon Laws <si...@googlemail.com>]

On Fri, Jun 6, 2008 at 3:15 PM, Miles, Chris <ch...@spsa.pnn.police.uk>
wrote:

> Hi, thanks very much for a response. I will try explain this better.
>
> In a traditional J2EE application like many I have worked on in the past
> the way I would normally develop them in a EJB sense is: Firstly I would
> develop my DAO components - EJB Entity beans for example. I would then
> develop my business layer components - EJB Session beans for example. I
> would then develop a web application which using JNDI would be able to
> look up the beans and use them. If I made a change to just one of the
> DAO components all I would need to do is drop it into the server's
> (JBoss) deploy directory and the container would load the bean and make
> it available to my business layer, and indeed any other business layer
> components which would use it.
>
> Trying to go for more lightweight development, I am making a transition
> away from EJBs (more so Entity beans) as the development and
> maintainability of them is too high. At the moment I am using a lot of
> lightweight Hibernate DAOs, but I am building and deploying my entire
> source tree as one task.
>
> I would like to break these various parts back down into components
> which I can freely change about required. So for example I would like to
> have my Hibernate DAO implementations as components which implement a
> specific interface, likewise I may have plain JDBC DAO implementations.
>
> The way I see this is as follows (broken into a very simple example):
>
> I have two web applications: "WebApp1" and completely separate
> "WebApp2", and I want both of them to be able to use the same component.
> The two web apps are contained within their own war/ear etc. How do I
> start implementing a shared component which both of the web applications
> can use?
>
> I hope that makes a little more sense.
>
> Thanks
>
> Chris


Hi Chris

Yes, that helps me a lot. So in your example you have

WebApp1
WebApp2
BusinessApp3

Where WebApp1 and WebApp2 both use a component service provided by
BusinessApp3

Let's assume that these are 3 independent SCA contributions and that the
WebApp1 and WebApp2 are going to communicate with BusinessApp3 over some
remote binding such as binding.rmi.  There are a couple of ways that I
believe you can make this work for you today with Tuscany.

1) Based on you knowledge of where you are going to deploy these as you
develop them you can manually configure binding.rmi definitions in the
composites in each of these contributions to so that the references can find
the services. You can then deploy WebApp1, WebApp2 and BusinessApp3 and use
the. You can of course stop and restart BusinessApp3 and expect WebApp1 and
WebApp2 to still work assuming that the interface that service interfaces in
BusinessApp3 haven't changed. This is a very static approach but should
work.

2) Use our domain manager to handle the configuration for you. Exactly the
same thing that you did in 1) will happen under the covers but the domain
manager will set up the binding URIs for you.

I can imagine that you would want this to be a little more dynamic in the
future so welcome you input on how we need to improve Tuscany to make it
work in the way you expect it to.

This is an interesting scenario. It would be great to have a sample for
Tuscany to show how to make option 1) work to start with.

Regards

Simon