Hi Steve,

Can you be more specific on the question? Do you mean referencing from one composite the classes defined in another composite? If this is the case, you need to specify a dependency, either by jboss-deployment-descriptor or in MANIFESF.MF.

In the multiApp quickstart you have an example. See maven-jar-plugin definition for order-consumer.

Hope it helps.

Steve Leach escribió:

 

I'll have a proper look tomorrow, but from an initial quick glance the pattern is to share Java classes, WSDLs etc. using Maven dependency management, yes?

 

Out of interest, doesn't that lead to more tightly-coupled service consumers & providers than is desirable in a SOA/SCA environment?

As it is a dependency, you have to declare in you final artifact (service application, jar, war or ear) the dependency. Since it is a dependency in a provided by you artifact (what it is called dynamic module) you have to declare it in the MANIFEST.MF or with jboss-deployment file. Maven only helps you assemble the final artifact, but the dependency is managed at runtime in one of the specified ways.

And yes, it leads to a more tightly-coupled, but there are not many other options, or?

You will only share classes/wsdls if you need to define these in more than one composite application, and if they are calling from one to the other, they should be using SCA binding, so wsdl probably is not of use, but it is the classes (at least the Java interface defining these service), so in this case, an because of the dependency, maybe packaging everything together in an ear is a good option, so all of the dependencies goes though the same lifecycle and there are never unresolved dependencies if you undeploy the "interfaces" jar (module) while maintaining the services.

Ahhh, thanks. MultiApp looks promising - I hadn't spotted the demos folder for some reason.

The ear-deployment quickstart also demonstrates how multiple applications can be deployed with shared resources:

quickstarts/ear-deployment at master · jboss-switchyard/quickstarts · GitHub

I'll have a proper look tomorrow, but from an initial quick glance the pattern is to share Java classes, WSDLs etc. using Maven dependency management, yes?

There are actually two considerations here:

1) How shared resources are resolved at project development/build-time.  That would be handled via Maven.

2) How shared resources are packaged when deployed to the runtime.  In general, the recommendation is to isolate shared resources and deploy them independently as a separate deployment (multiApp) or in the lib/ directory of an EAR.  Each approach has advantages/disadvantages.

Out of interest, doesn't that lead to more tightly-coupled service consumers & providers than is desirable in a SOA/SCA environment?

Can you elaborate a bit on this point?  If multiple applications share a dependency, we are recommending that the dependency is isolated in a distinct module and shared instead of including multiple copies of it in your applications.  Consumers and providers in SOA interact through contracts, so agreement on a shared contract is a necessary prerequisite.  Now, you have the freedom to choose whether that contract is Java, WSDL, or something else and the details of the contract (operation granularity, message types, etc.) can have a large impact on the level of coupling.

Good discussion. :-)

Well, in SOA you generally want the interface between two services to be defined as much as possible by the service contract. For SOAP services that is a WSDL file published over HTTP. That should be all you need to consume the service. For example, with plain old JAX-WS you publish the service interface WSDL from one app (WAR/EAR), then import that WSDL (using an HTTP URL) into another project and it generates a client stub which you use in your code. You might have a slightly different mechanism for publishing/consuming the WSDL, but the model is essentially the same.

Absolutely you want the interaction to be described completely by the contract.  I disagree that JAX-WS provides a level of decoupling at all since you need to compile the client against generated Java stubs.  In all scenarios, you are relying on the fact that the WSDL does not change incompatibly, which means both consumer and provider rely on an identical (I could bend this to equivalent for corner cases) WSDL definition.  Since we recognize that both applications require access to the contract, then it simply becomes a choice of how that contract is accessed at development and runtime.  If you are dealing with WSDL contracts, there's no harm in packaging multiple copies, but it's a brittle choice in the face of change (ditto for generated JAX-WS client stubs).  Having multiple copies of Java interfaces and data objects is a bad idea from a class loading perspective in addition to these concerns.

 

In the MultiApp demo, however, the WSDL is published through a Maven dependency, which is fair enough I suppose, but so are the Java classes and interfaces. This feels like tighter-coupling than the JAX-WS model to me. One of the key drivers behind SOAP Web Services (and things like CORBA before that) was to get away from shipping code between projects when loose coupling is desirable.

Java interfaces are a choice, not a requirement.  They provide a lot of convenience in certain scenarios.  You could use WSDL in the same app if you really wanted to use XML for all consumer-provider interactions across application boundaries.  I have been down the road where everyone is forced to use WSDL and it ends in tears and anguish. ;-)

I'm not sure I understand the point about choosing whether contracts are Java or WSDL, etc. Haven't we always had this choice?

Yes, of course.  My point is that the type of contract itself, no matter how it's resolved by consumers/providers, has a great impact on coupling.  If I have a Java contract, for example, then I'm assuming Java data objects and Java clients.  If I use WSDL, then it's XML which opens up the service to non-Java clients.  To be extra clear on this point - using an @WebService with JAX-WS is not equivalent to a Java contract for a service.  WSDL is generated from that, which is the actual contract that consumers will see.  In SwitchYard, you can define a component-level (which is private to the application) contract of Java and then simply generate WSDL which is used for the composite (public) service consumed by external clients.

Hi Steve,

Since I haven't done the quickstarts I can not really answer, but I guess that it was built with JBDS as it is the easiest way.

The process can be very simple, but depends on how you want to expose your service.

If you want your service to be exposed in an SCA binding, then promoting the service interface as Java is the way to go.

On the other hand, if you want your service exposed with a SOAP binding, then you should promote your interface as wsdl, add the transformers (if needed) and that's it.

There are very nice videos in vimeo from Keith (the master here): http://vimeo.com/search?q=switchyard+ep

And there is some labs with information on github: https://github.com/jboss-switchyard/learning

As to mention about the other discussion, SCA is not SOA. SCA applications can run in the same container, so artifacts can be shared as a dependency. Of course your services are coupled in some ways, even in SOA. Loosely coupling in SOA can be achieved by having a BUS in the middle that let service contracts evolve, but in this scenario, the ESB will be coupled with every service provider. Interfaces must match.

In SCA, and SCA calls, because these services are called from within the same container, these interface definition can be shared (for reusability) but services are still coupled.

In the scenario that you talk, where services are discovered, stubs dynamically generated, and so, there is one important drawback, which is "performance", so that's why most of the service (consumers/providers) provide the stubs for the calls, and these stubs are coupled to the interface, and thus, can be shared between services that use that interface.

Every quickstart I create is done using SY tooling because:

(1) I want to test the tooling

(2) The tooling makes me more productive, which means I spend less time building the example

Each contributor to the project has their own preferences though, so I can't say that every quickstart was created in JBDS.  I created the multiApp quickstart and I can confirm it was done using SY tooling.

 

 

What I was hoping for is something like...

1. Create Project SY1, add a Java component with a Java interface (hello world or something)
2. Promote the Java component interface as a WSDL composite interface, with a SOAP binding
3. Create Project SY2
4. Import the WSDL from SY1 as a composite reference, with a Java interface
5. Create a Java component with a component reference to the composite reference from above
6. Test this new component

 

The MultiApp quickstart has obviously gone through this process, but I can't figure out how they did step 4.

 

Two things with step 4 above:

1) Importing a WSDL from a URL is not supported right now, but it's a very desirable feature.  This means you'll have to save the WSDL locally and import it into your project by adding it directly to the project or resolving it via a dependency.

2) The composite reference contract would be WSDL, not Java.  The component reference, which belongs to the service logic which is invoking the service, can certainly be Java though.

After all, If you're going to share a classloading context anyway, why bother with SOAP at all?

Because there can be many consumers of an application's services.  Some consumers could be deployed in separate applications, but produced by the same team with the knowledge that they will always be deployed in the same container.  That's a choice that's really up to the developers.  In the case of multiApp, both approaches are demonstrated - the applications talk to one another via binding.sca but also expose services to the outside world via binding.soap.

Keith Babo escribió:

 

1) Importing a WSDL from a URL is not supported right now, but it's a very desirable feature.

Hi,

As far as I know, the wsdl must be accessible for the configuration to be able to deploy the service to the binding as well as for the sca:interface, right now, but it would be nice if it could get it from thee S-RAMP repo via an S-RAMP query at deploy time.

Cheers,