Topics

Featured in Development

Peter Alvaro talks about the reasons one should engage in language design and why many of us would (or should) do something so perverse as to design a language that no one will ever use. He shares some of the extreme and sometimes obnoxious opinions that guided his design process.

Featured in AI, ML & Data Engineering

Today on The InfoQ Podcast, Wes talks with Katharine Jarmul about privacy and fairness in machine learning algorithms. Jarul discusses what’s meant by Ethical Machine Learning and some things to consider when working towards achieving fairness. Jarmul is the co-founder at KIProtect a machine learning security and privacy firm based in Germany and is one of the three keynote speakers at QCon.ai.

Featured in Culture & Methods

Organizations struggle to scale their agility. While every organization is different, common patterns explain the major challenges that most organizations face: organizational design, trying to copy others, “one-size-fits-all” scaling, scaling in siloes, and neglecting engineering practices. This article explains why, what to do about it, and how the three leading scaling frameworks compare.

... the new programming model for creating Java components is a fundamentally important part of SCA. Because it provides a simpler and more service-oriented approach to building business logic, developers can use it instead of EJB, JAX-WS, and perhaps other parts of Java EE 5.

David believes that the Java programming model does not get the attention it deserves, equating it's importance in SCA to what WCF did for .NET:

Just as Microsoft's Windows Communication Foundation (WCF) provides a unified approach to the problems addressed by .NET's Enterprise Services, .NET Remoting, and ASPX, the SCA programming model covers the great majority of the useful scenarios currently addressed by EJB, Java RMI, and JAX-WS. Business logic built on SCA's new programming model can still use JSPs, JPA and other aspects of Java EE 5--SCA doesn't replace all of the enterprise Java APIs.

Now Eric, as a representative of IONA one of the SCA authors (and leaders of the Eclipse SOA Tools Platform effort), disagrees. He believes that it is the service assembly model that is key and also thinks the WCF comparison is not necessarily a good one:

I was at Tech Ed '03 when WCF was announced, and I remember clearly hearing the objections to some of the developers in attendance when they discovered that Microsoft was asking them to change how they developed their Web services.

In comments to Eric's piece, David does clarify some of his statements:

... my view is that SCA's assembly model is important, too; I just think its Java SCA component model is more important. ... Defining how components should be assembled into applications is certainly a useful thing, and this part of SCA seems likely to get broad support. Still, just as the complaining Windows developers you mention came to understand why WCF was a good thing, enterprise Java developers should understand the value of a unified programming model for service-oriented applications.

But as Eric then points out:

One difference between the Microsoft world and the Java world is that there are already ways to create services - some more complex than others, granted - but one of the things I've always said about the SCA Java programming approach was the danger of exchanging one complexity for another. I am not sure the SCA programming model significantly reduces complexity compared to things like JAX-WS or Spring..

So the question remains: what is the most important aspect of SCA? Maybe this will remain a vendor-specific answer. But if that is the case, what will this do for the perceived over complexity around SCA?

The problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

Steve Bellovin of AT&T Labs once said: "Any software problem can be solved by adding another layer of indirection." That is exactly what SCA aims to do (layering over EJB, RMI, JAXWS). But as the Kesselman Correction points out: "The two software problems that can never be solved by adding another layer of indirection are that of providing adequate performance or minimal resource usage.".

I'd like to add another correction (the Fremantle Correction?) - which is that "Another software problem that can never be solved by adding another layer of indirection is providing a simple, transparent and easy-to-use code".

Building distributed systems is hard enough, which is why EJBs, RMI, WS and even REST aren't simple. Unfortunately, adding a layer of indirection doesn't help. It might make is seem simpler for a while, but in fact you end up with three problems: 1. Its harder to understand what is going on: As we've seen with the move towards REST, programmers like to see the relation between their code and the wire. They like to understand what happens when they code a line of Java (or C or PHP or JavaScript).2. Its harder to debug: because its harder to trace back from the low levels through the layers of indirection.3. Its harder to really understand - to grok, to know inside out: the layers of indirection don't remove the difficulties of the problem, they just hide them. So predicting what will happen in difficult situations becomes harder.

I think the complexity of the SCA specifications backs up this point completely. Something that was designed to simplify and unify programming models should have a simple description. Unfortunately, because of the above reasons, that just isn't possible.

The problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

If you can't describe the solution, you don't understand the problem well enough.Thats all I need to know. I won't be taking a look at SCA. The same gut feeling kept me away from EJB, and it turned out to be right.

Help me understand...

Your message is awaiting moderation. Thank you for participating in the discussion.

Can someone supply some example use cases/applications where SCA really adds value or simplifies things over existing technologies? I roughly grasp the idea of composites, components, domains, etc - but I have yet to see where my life is really simplified.

I'm sure this will betray my complete ignorance about SCA, but from what little I know it seems like a glorified Spring specific to developing services. But why wouldn't I just use Spring to begin with?

Re: The problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

This "complexity" of SCA due to layering is a paper tiger.

SCA describes a very simple model for the programmer. Effectively, it says to the programmer, in any langauge, all you do for your service components is to offer services through a well defined interface and make use of other services through well defined interfaces - and keep all the middleware plumbing out of your code.

This is VERY close the philosophy of Spring. Indeed, Spring Beans make an EXCELLENT way of building service components in Java.

What the SCA Assembly model then brings to the party is a organized and standard way of describing how the different components in your (distributed) system are linked together to build a particular application.

When, for example, you want the service offered by your component offered as a Web service - you simply say that - apply binding.ws and you're done. When you want your component to connect to another component which is supplying a service you need, you simply say that - reference name="fred" target="componentFoo"

And so on. Nothing complex about that. Its the SEPARATION of the structuring and linkage from the code that is important - since this enables reuse of the code in new contexts without having to hack the code.

"Complexities" creep in only when you want to use advanced function, which explains the length of the SCA specifications. Once you get into Security functions, once you get to deal with details of Web services, then there are plenty of variations to describe. Even there, SCA provides simplification. Want encryption on your service? Say requires="confidentiality". Done.

You're right that developers like to see the consequences of their actions - but the answer to that are effective tools that allow them to trace the messages flowing to and from services (and, with luck, make sense of them). On the other hand - you don't want all that gorp in your code.

Re: The problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

My 2 cents:SCA is to distributed services what Spring is to in-process components.And JBI is to distributed services what OSGi (the plugins part) is to in-process components.So if you understand Spring and OSGi you're done.

Re: The problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

My 2 cents:SCA is to distributed services what Spring is to in-process components.And JBI is to distributed services what OSGi (the plugins part) is to in-process components.So if you understand Spring and OSGi you're done.

Problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

I have read and re-read the SCA assembly specification and the Java component programming model and maybe it's just mere mortals like myself but the assembly spec is not easy to digest at all. I sort of get the idea that SCA is trying to simplify assembling components out of existing services that may have been written using different languages, technologies etc and to that end I also feel the assembly specification is more important because The Java programming model is really about additional annotations containing information that will ultimately be used to facilitate the component assembly - it's by no means a replacement for service implementation techniques such as JAX-WS or even EJBs in the Java world. However what makes me uncomfortable is for a specification that tries to take a language, technology agnostic view about services, it introduces constructs and ideas that are clearly more applicable to certain technologies than others (i.e., the idea of injectable properties, references etc. - not sure what their analogues would be in a 'COBOL component' ). It also freely mixes language and framework constructs ( A Java component and a Spring ApplicationContext can both serve as a 'component implementation') and promotes them to first-class concepts in the SCA world. And finally, I still struggle with the entire notion of the Composite - couldn't a component itself support recursive composition - why do we need this extra construct of a composite at all?

Bottomline is, my admittedly incomplete understanding at this point makes me feel SCA seems like a well-intentioned, albeit hodge-podge of ideas that might take some effort to understand but not sure how much value it will ultimately deliver.

Re: The problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

My 2 cents:SCA is to distributed services what Spring is to in-process components.And JBI is to distributed services what OSGi (the plugins part) is to in-process components.So if you understand Spring and OSGi you're done.

I fail to see what could stamp Spring as more for in-proc components and less for remote components. A POJOs could be any java objects, either real "in-proc" objects or local stubs delegating remote SOAP server objects. With a suitable remote object framework (e.g. JAX-WS or JAX-RPC) the remote-ness of POJOs is orthogonal and transparent to Spring.

Re: The problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

I fail to see what could stamp Spring as more for in-proc components and less for remote components. A POJOs could be any java objects, either real "in-proc" objects or local stubs delegating remote SOAP server objects. With a suitable remote object framework (e.g. JAX-WS or JAX-RPC) the remote-ness of POJOs is orthogonal and transparent to Spring.

POJOs are first class citizens of Spring, remote services are the first class citizens of SCA.

Re: The problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

I fail to see what could stamp Spring as more for in-proc components and less for remote components. A POJOs could be any java objects, either real "in-proc" objects or local stubs delegating remote SOAP server objects. With a suitable remote object framework (e.g. JAX-WS or JAX-RPC) the remote-ness of POJOs is orthogonal and transparent to Spring.

POJOs are first class citizens of Spring, remote services are the first class citizens of SCA.

The programming objects of so-called "remote-services" in SCA are either their client stubs (for client applications) or server skeletons (for server applications). Both of these classes are merely special cases of POJOs.

As the matter of fact, the so-called SCA assembly model is merely a DSL (domain specific language) that can easily be realized on top of Spring or any decent POJO IoC containers, with few hundreds lines of code and half day of work.

Re: The problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

As the matter of fact, the so-called SCA assembly model is merely a DSL (domain specific language) that can easily be realized on top of Spring or any decent POJO IoC containers, with few hundreds lines of code and half day of work.

So I'm not the only one who thinks this! I reread the SCA assembly spec when this article came out and that only reaffirmed my opinion.

Re: The problem with SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

As the matter of fact, the so-called SCA assembly model is merely a DSL (domain specific language) that can easily be realized on top of Spring or any decent POJO IoC containers, with few hundreds lines of code and half day of work.

Spring (and DI) normally helps to build any application, and of course you can build an SCA container with Spring (and a EJB3 container too). But SCA is a "standard" where remote services are the SpringBeans.

Re: Help me understand...

Your message is awaiting moderation. Thank you for participating in the discussion.

Hi Dan,Paul:+2

Yep. I think most of us agree with David Chappell that a unified programming model is good, and the simplest way to achieve it today would be to use a IOC container like Spring and program using interfaces. We are using Spring to achieve this transparency on the client side and are trying to support EJB-RMI, SOAP WS, JINI as remoting mechanisms. Spring makes this possible with the least amount of fuss.

However, if you intend to build intelligent context aware services (with graceful degradation), can anyone recommend best practices to implement context propagation that can work irrespective of the programming model or hosting model used? I am talking about applciation level context as opposed to infrastructure context (security, transaction).

For the time being we intend to use the low-tech wrapper technique. Our interfaces have two end points:- f(x) and f(x,ctx). On the client side, as developers call f(x), we use interceptors to transparently call f(x,ctx), where ctx (context) is transparently propagated. On the server side, the service implementation f(x, ctx) delegates to f(x). This is piece of cake in Spring (or when you are using any IOC container, but it is easier with Spring).

WSDL & BPEL greatly benefit from SCA

Your message is awaiting moderation. Thank you for participating in the discussion.

I found that two arguments were missing from this discussion.

First, WSDL has a design flaw: bindings cannot be defined for outbound operations, even though outbound operations can be explicitely declared as part of the interface. The problem is of course that as you design the service interface, you cannot establish a contract with any consumer just yet, let alone support multiple consumers.

The flaw was plugged elegantly by WS-I by making outbound operations outlawed, in effect, reifying service orientation behind object orientation.

Unfortunately this really does not help the construction of Service Oriented Architectures. SOA is really about coordinating the performance of n services (n>1). Whatever coordnation mechanism you use, one or more service is required to manage the context of the activity. BPEL is a great coordination technology for managing this context and, as you know, most often exposes outbound operations (like any coordinator)

The assembly mechanism enables the injection of service references at deployment time (which is the right wy to do it). The short cut that was taken 6 or 7 years ago to associate bindings in WSDL was not a great decision. It made things simpler for sure, but it didn't make them simple.

So, IMHO, SCA is a true expression of what SOA is about, it fixes the WSDL flaw, and it brings BPEL in a full programming model.