Home » Archived » Service Oriented Architecture Tools Platform (STP) » Purpose of SCA
| Purpose of SCA [message #618672] |
Tue, 02 September 2008 09:33  |
Eclipse User |
|
|
|
Originally posted by: michael.gebhart.googlemail.com
Hi,
I have one question concerning the SCA. For me SCA is not easy to
clutch. When I've designed my business processes with the BPMN editor,
with the Intermediate Model I get an elementary SCA diagram,
representing my SOA architecture.
But is SCA really representing my SOA architecture? Isn't anything
missing? What about infrastructure components like UDDI, ESB etc?
SCA only shows which services I have and how they depend on each other.
Is this already a complete SOA architecture?
My problem is that I see SCA more as a programming paradigm than an
architecture language.
With SCA I easily can wire services together and connect components with
implementations etc. It is a paradigm to write applications in a service
oriented way. As we can see, there are bindings for java, C, php etc.
(but not .net)
Is this the same as designing the architecture for a SOA? In my view,
SCA is more on a lower level for developing applications than for upper
level work like designing the architecture.
Maybe an UML component diagram which doesn't contain implementation
details and bindings details is more suitable for this job?
Because SCA contains a lot of lets say platform specific information.
Greetings
Michael
|
|
|
| Re: Purpose of SCA [message #618673 is a reply to message #618672] |
Tue, 02 September 2008 12:25  |
| Eclipse User |
|
|
|
Originally posted by: ohurley.iona.com
Michael Gebhart wrote:
> But is SCA really representing my SOA architecture? Isn't anything
> missing? What about infrastructure components like UDDI, ESB etc?
> SCA only shows which services I have and how they depend on each other.
> Is this already a complete SOA architecture?
I think the answer to this question is - it might be, for a certain
value of 'complete'. But in most cases that are in the real world,
a SOA will need to enlist other services beyond the ones that
you have created. The SCA defines the concept of an 'external'
service for this this purpose.
Infrastructure components are an important element of an
operational system, which may have been constructed using
SOA guidelines. But the SOA viewpoint is independent of
the infrastructural planning, since in execution the latter is
very much IT policy dependent, and technology dependent,
and performance dependent. You don't need an ESB to do
SOA, although one can be handy. You don't need a registry
to do SOA, but it's pretty useful when you want to find and
bind services in a dynamic way.
> My problem is that I see SCA more as a programming paradigm than an
> architecture language.
There's a number of opinions about SCA that are worth
investigating. The first is that SCA is a way to model services
that have policies and properties, that have dependency
relationships, and then clump those services together into
components that are some kind of logical grouping. People
who have looked at OSGi find this a very familiar set of
concepts, where the service 'clumps' reflect a neat mapping
to a set of bundles in an OSGi container.
The second is that SCA is a set of new programming
approaches. During the development of the SCA standard,
there was a lot of discussion on this topic. Primarily this
discussion centered on the need to define a new Java
programming model, when we already had things like
Spring, and OSGi, and JAX-WS, and others. Personally,
I feel that there is little value in having a new programming
model in Java, except to the market-makers that are looking
to grab on to new Java developers and build developer
mindshare towards what could be considered a level-up from
the JEE application servers of the past.
That being said, I *do* see some value in the other language
programming models, like C, C++ and COBOL. I'll
welcome a correction here, but it looks like these languages
have had no services programming model standards applied
since the CORBA specifications in the 90s.
The third opinion is that SCA was a cynical attempt by the
incumbents of the enterprise software industry to inject
some life into a now-distrustful marketplace. But that's
a cynical opinion in it's own right, and I include it for
completeness only ;)
<snip>
> Is this the same as designing the architecture for a SOA? In my view,
> SCA is more on a lower level for developing applications than for upper
> level work like designing the architecture.
I personally don't think SOA == SCA, but there is a connection
where SOA > SCA. Here we are again down the question of how
is the word 'architecture' used within your environment. I also
think that 'Architecture' > SOA > SCA, and that by just having
a SOA, you have not solved all your issues about rolling out a
system. But you may have solved some of them, by parcelling up
reusable (and chargeable?) function as services, allowing you
to reduce the pain of comprehending the distributed system
in its entirety.
> Maybe an UML component diagram which doesn't contain implementation
> details and bindings details is more suitable for this job?
Whatever way you want to model it depends on how effective
the model is for communication within your target environment.
Some corporations love UML, some don't. It's whatever can get
your ideas across most effectively.
> Because SCA contains a lot of lets say platform specific information.
It does, and in this way it's a lot like WSDL. At first it seemed
interesting to have the binding expressible in that way, but I
think that on mature reflection we may have been better off
by not depending on having binding information in the same
document (yes, I know about includes, it's still the same doc
if you use them) and instead gone down the road of doing
interface versioning.
Well, that turned out to be a long post :)
cheers
--oh
|
|
|
| Re: Purpose of SCA [message #618674 is a reply to message #618673] |
Tue, 02 September 2008 13:13 |
| Eclipse User |
|
|
|
Originally posted by: michael.gebhart.googlemail.com
Hi Oisin,
first, thanks for your very interesting post. You have mentioned some
good points like the missing definition of architecture or the
separation of designing SOA and the operational view containing the
infrastructure components and so on.
If I were supposed to write down the purpose of SCA without platform
specific details in one sentence it would be: A SCA assembly diagram
shows the new services I need within my SOA including their dependencies
and dependencies with existing services.
That's it? Thus it would be more a service model instead of a service
component model. Don't see the component artifact needed for my SOA
design. The component part imho is more a platform specific part.
So in my opinion a SCA model is far away from a runnable SOA. But this
again requires the definition of a SOA. (If an UDDI is part of a SOA etc.)
Can I assume that the creation of a SCA model is a easy task? For each
process I create one component which requires a service for each task
within the process. Is this all I have to care about?
And then I have my SCA model and connect it with existing services or
implement the new, needed services.
Do you know any case, when a SCA assembly diagram becomes complex?
(Besides a thousand services). Or is the transformation of a business
processes into the SCA model more complex than I imagine?
Greetings
Michael
|
|
|
| Re: Purpose of SCA [message #618675 is a reply to message #618674] |
Wed, 03 September 2008 09:10 |
| Eclipse User |
|
|
|
Originally posted by: ohurley.iona.com
Michael Gebhart wrote:
> If I were supposed to write down the purpose of SCA without platform
> specific details in one sentence it would be: A SCA assembly diagram
> shows the new services I need within my SOA including their dependencies
> and dependencies with existing services.
I think that is accurate, but I think you need to add the application
of properties and policies too - they don't have to be platform
specific.
> That's it? Thus it would be more a service model instead of a service
> component model. Don't see the component artifact needed for my SOA
> design. The component part imho is more a platform specific part.
I agree with you - I don't think that you need the component
part to design your SOA, although it might be useful when you
get to talk about rolling out your system, or deciding where you
have charging boundaries. So there is definitely some usefulness
there.
> So in my opinion a SCA model is far away from a runnable SOA. But this
> again requires the definition of a SOA. (If an UDDI is part of a SOA etc.)
> Can I assume that the creation of a SCA model is a easy task? For each
> process I create one component which requires a service for each task
> within the process. Is this all I have to care about?
I think the best way to answer this question is to go out
there and try out the SCA modeler! See the instructions
on creating composites at
http://wiki.eclipse.org/STP/SCA_Component
If you have questions, the team should be able to answer them on
the stp.sca-tools newsgroup
http://www.eclipse.org/newsportal/thread.php?group=eclipse.s tp.sca-tools
<snip>
> Do you know any case, when a SCA assembly diagram becomes complex?
> (Besides a thousand services). Or is the transformation of a business
> processes into the SCA model more complex than I imagine?
I haven't seen any huge SCA assemblies yet, if anyone else reading
this has, please let us know!
I know from an earlier thread that you have already looked at the STP
Intermediate Model. I would think that this would be a better candidate
for modeling your SOA, without the constraints of platform-specific
binding elements (although these can be included in the IM).
What are your thoughts on the Intermediate Model?
best regards
Oisin
|
|
|
| Re: Purpose of SCA [message #618996 is a reply to message #618672] |
Wed, 03 September 2008 10:30 |
|
Hello,
I have used SCA for small use cases in a research project called
SCOrWare (www.scorware.org), and here are some conclusions we shared
with several partners:
SCA is not SOA. SOA is an architecture of System of Informations,
whereas SCA is a framework to design applications.
SCA is a technology that allows to create applications easily in
conformance with SOA principles. Indeed, it facilitates and encourages
the use and the publication of services.
For me, SCA is like Spring: it is an XML-based language that describes
an *application*, but it also includes technologies, principles and
vocabulary related to SOA.
If you use SCA, then you have a good (IMHO currently the best) tool to
create a System of Information which takes advantages of SOA (agility,
scalability, reuse...). Moreover, my experiences with SCA has shown me
that this framework is quite simple and pleasant to use for developers
(this remark is probably too personal).
However, SCA is *not intended to become a middleware*. It is a
*framework*. You mustn't think that SCA is enough to get full SOA. SCA
can show you advantages of SOA in the scope of one application that uses
and promotes some services, but SOA it much more than that: it is an
architecture, a plan, some rules, strictness... which scope a whole SI.
I hope that my elan on this topic did not make me talk nonsense.
Regards,
Mickael
Michael Gebhart a écrit :
> Hi,
>
> I have one question concerning the SCA. For me SCA is not easy to
> clutch. When I've designed my business processes with the BPMN editor,
> with the Intermediate Model I get an elementary SCA diagram,
> representing my SOA architecture.
>
> But is SCA really representing my SOA architecture? Isn't anything
> missing? What about infrastructure components like UDDI, ESB etc?
>
> SCA only shows which services I have and how they depend on each other.
> Is this already a complete SOA architecture?
>
> My problem is that I see SCA more as a programming paradigm than an
> architecture language.
>
> With SCA I easily can wire services together and connect components with
> implementations etc. It is a paradigm to write applications in a service
> oriented way. As we can see, there are bindings for java, C, php etc.
> (but not .net)
>
> Is this the same as designing the architecture for a SOA? In my view,
> SCA is more on a lower level for developing applications than for upper
> level work like designing the architecture.
>
> Maybe an UML component diagram which doesn't contain implementation
> details and bindings details is more suitable for this job?
>
> Because SCA contains a lot of lets say platform specific information.
>
> Greetings
>
> Michael
|
|
|
Goto Forum:
Current Time: Fri Apr 26 19:48:46 GMT 2024
Powered by FUDForum. Page generated in 0.03834 seconds |
] 
Search
Help
Register
Login
Home
