Thanks Stefan,
It's always encouraging to know that others are struggling with the
same issue. It's remarkable though, that there has been written so many
books and articles about service-orientation and yet there is no
consensus about a detailed model of service oriented concepts.
// Dennis
Stefan Tilkov wrote:
On Jun 21, 2006, at 2:27 PM, Dennis Djenfer wrote:
Hi.
I'm also in the progress of creating a SOA Reference Architecture.
It's not an easy task, but I have used the OASIS Reference Model as
a starting point. There is many issues I'm looking into, and some
of them are:
A more detailed model of a service that makes it possible to use a
common langauge, i.e. relationships between messages, operations,
interface, ports, service and service provider. Seems like an easy
task, but I'm not able to construct a model that satisfies
everybody. E.g should there be a 1-1 relationship between a service
and a service interface (there could be many ports into the same
service, but they all use the same interface) or should a service
be able to implement many interfaces?
These are exactly the kind of questions I face in every single
customer project. The first step is to define a model (or metamodel,
if you prefer) of SOA concepts. For example, there is no right or
wrong when it comes to questions such as whether a "service" contains
"operations" (or whether operations *are* services), whether "service
interface", "service", and "service implementations" are distinct
concepts ... I have created several incompatible such models by now
to incorporate specific customers' pre-existing terminology.
This is also what I would hoped for the OASIS SOA reference model to
provide, instead of high-level statements that are so consensus-
driven that they are almost meaningless.
I'm using the above model to create UML 2.0 notation for a service
(I have looked at the UML-profile from Rational / IBM for services
but I'm not found of it).
I agree.
A taxonomy for service, i.e. a service layer model and descriptions
of different kinds of services.
I agree that you should have a taxonomy, i.e. different kinds of
services. I'm not very fond of the layer approach, though -- that's
much too one-dimensional for my taste.
Principles for services
Patterns for services
The biggest problem, as I see it, is the question about how to
apply the principle of autonomy for services. If you apply this
principle you will get really big services that comes very close to
systems in their own right. It does not fit very well with my
layered approach that has the following layers:
process layer
activity layer
base layer
utility layer
application layer
infrastructure layer
If you agree on layers (or any other kind of taxonomy), I believe the
set principles you agree on will apply differently to services of
different kinds.
Stefan
--
Stefan Tilkov, http://www.innoq.com/blog/st/
The most important layer is the base layer where services like
products, customers e.t.c will be. If those services should be
autonomy they will be very big, with lots of business logic and
maybe even some process logic. There will not be many services in
the activity layer (we have not identified any services in this
layer yet). The process layer will have have processes that span
the big base services. I'm not sure if this is the right approach.
Feedback is appreciated!
Dennis
Brian Mikesell wrote:
Jason, I'm tasked with the same thing you are, and we, too, are
largely an IBM shop, so maybe we can help each other out on this
task. The approach I'm taking is to define at a very high level
what our most common use cases are. These come down to pretty
simple message exchange patterns such as request/reply, one way,
notification, etc. Out of those patterns, request/reply is our
most common, so that's where I'll focus first. A reference
architecture must satisfy your major use cases and your non-
functional requirements, so I try to define a logical component
model that satisfies these requirements. Major architectural
elements (such as an enterprise service bus) emerge as you look
harder at the non-functionals. Once you get to a certain level of
maturity with your component model, run your use cases through the
component diagram. I'm taking an iterative approach, so I get to a
certain point, run use cases through, review that with a larger
group, and make appropriate changes. Let me know if that's in-line
with your approach. I'm interested in other ideas. Brian --- In
[email protected], Jason Lenhart
<[EMAIL PROTECTED]> wrote:
Hello and thank you for starting such a wonderful group, I am
tasked with creating a SOA Reference Architecture for my
organization. In reading the OASIS 'Reference Model for Service
Oriented Architecture' has the concept I really latched onto
about 8 months ago (prior to me receiving this assignment).
Essentially that a Ref. Arch is to identify abstract solutions to
the problem domains in my organization. That being said - I work
in a very large organization and we have a ton of problem domains
(but I suppose they can be derived easily down to architectural
patterns). I was wondering if anyone had any direction on this. I
also believe that the intent of this is to outline how our
current suites/toolsets will align (we are an IBM shop). Any
direction is appreciated. Thank you in advance, Jason
__________________________________________________ Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
------------------------ Yahoo! Groups Sponsor --------------------
~--> Yahoo! Groups gets a make over. See the new email design.
http://us.click.yahoo.com/XISQkA/lOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~
To unsubscribe from this group, send an email to: service-
------------------------ Yahoo! Groups Sponsor --------------------~-->
Something is new at Yahoo! Groups. Check out the enhanced email design.
http://us.click.yahoo.com/SISQkA/gOaOAA/yQLSAA/NhFolB/TM
--------------------------------------------------------------------~->
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/service-orientated-architecture/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
__._,_.___
![]()
SPONSORED LINKS
YAHOO! GROUPS LINKS
__,_._,___
|
