Home » Archived » Service Oriented Architecture Tools Platform (STP) » Comments on the proposal
| Comments on the proposal [message #560467] |
Fri, 30 September 2005 20:04 |
Eclipse User |
|
|
|
Originally posted by: carl.trieloff.iona.com
Post of mail thread
comments in-line to start, fire back with anything I don't explain clearly
Regards
Carl.
-----Original Message-----
From: Daniel Berg [mailto:danberg@us.ibm.com]
Sent: Wednesday, September 28, 2005 11:08 AM
To: Trieloff, Carl
Subject: SOA Tools proposal question
Hi Carl,
In the architecture section of the proposal there is a description of the
runtime extensions.
Typically service contract get bound to an implementation. An extensible
layer will be provided to plug-in support for various runtimes, to create
executable entities, either Service Consumers or Service Providers.
Attributes of the runtime component will need to be exposed to provide the
editor the ability to generate/create artifacts for specific
implementations, as an Eclipse plugin. The services that extension for
runtime support element will bring are:
a. Generators to create starting point application code that the
developer can complete out. Test / Debug environments to be able to properly
test their development activities
b. Management Screens to look at the deployed solution, start / stop
/ pause services etc.
If I am reading this correctly it states that a service contract (is this
the WSDL only or something more?) is bound to an implementation. This is
done using the Contract Design and Development layer with its
extensions...correct?
[Trieloff, Carl]
Yes, and by implementation I mean POJO or JAX-B or JAX-WS etc, not the
runtime container. that is a step that is
delegated to later in the process as the implementation should not be tied
to the runtime container but rather connected to an implementation
methodology/standard.
Now with the runtime extensions is it true that a specific runtime will
generate a set of application entities that will support a service. It says
here that this is a starting point. Is it the assumption that the user
would be required to manage this generated code and they would be allowed
(required?) to edit this generated code? I would assume that this means
that each runtime may provide tooling to edit their generated entities?
[Trieloff, Carl]
So the starting point and code editing is to "add/ create" the behavior of a
client/service not "code" the implementation
[Trieloff, Carl] to the runtime container. The deployment or
container/runtime deployment artifacts should be 100 % generated or config
Let's look at a random example
- I generate a JAX-B 2.0 server,
- I then go and write the service implementation
[Trieloff, Carl] - I then update the contract (add a new method)
- the tool code merges in the new method into the implementation
[Trieloff, Carl] - I write the implementation
ok, now I have a service , not connected to anything.
- I set the policies etc for the service
- I select a container/runtime
- I deploy, which might ask one or two more questions and it creates the
deployment artifacts for that runtime.
Is there any thought around an integrated test/debug environment at the
abstract service layer?
[Trieloff, Carl]
[Trieloff, Carl] yes
It appears that the proposal is indicating that each runtime is
responsible for providing their own tooling around test and debug.
[Trieloff, Carl] Partially true, so some test and debug is generic, but some
is runtime specific. An example of runtime specific is if it supports Tivoli
or BMC etc and setting up that config. However, the creation of management
stats is not
necessarily RT specific as this can be a service and policy based
So if a user has multiple services that are deployed to different runtimes
they will have completely different test, debug, and management
capabilities.
[Trieloff, Carl] no, any piece that is deployed as a service will be common,
any part that link vendor specific products
has to be runtime specific
Would your solution to this problem be to try to target a single runtime as
much as possible?
[Trieloff, Carl]
I would say it would be better to open up the common services, than to try
support one runtime only. For example
[Trieloff, Carl] it is easier to create a stats collector and have all
publish to it, and then bind it to multiple management consols, than to get
the world to agree to a single runtime. (don't know if this is the best
example)
On a separate note can I get a clearer picture of the abstract service
concepts? From what I gathered on our call I have the following picture in
my mind. Is this correct? If not (and I assume it is not) what is missing
or what is wrong?
[Trieloff, Carl]
At a high level this modeling is good. one layer down the addition of
configuration, implementation and deployments artifacts needs to be added
and the ralationship to projects. should I do so for you? Need to work out
how to post UML to news group
Carl.
Thanks,
Dan
Attachment: uml.bmp
(Size: 226.64KB, Downloaded 209 times)
|
|
|
Goto Forum:
Current Time: Thu Apr 25 15:39:18 GMT 2024
Powered by FUDForum. Page generated in 0.03318 seconds |
] 
Search
Help
Register
Login
Home
