Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Web services (SOA) from a Web Application

Reply
Thread Tools

Web services (SOA) from a Web Application

 
 
richardsosborn@gmail.com
Guest
Posts: n/a
 
      11-02-2006

Manish Pandit wrote:
> Hi!
>
> SOA brings a new paradigm of business awareness. Along with looking at
> the technology, make sure you consider the cross-functional business
> processes. Under the hood, SOA is essentially
> identify->assemble->deploy cycle, where in you identify common
> cross-functional tasks, model them as services, assemble multiple
> services (tasks) to achieve a coarse grained functionality (process),
> and deploy it. The core focus should be granularity and reusability -
> the code can be EJBs, Spring Components or a mainframe sitting
> somewhere. This brings in the whole Enterprise Integration scenario,
> where in you might end up integrating some legacy systems via messaging
> or something similar. Normally, businesses do not prefer "rewrite the
> whole thing" idea, so there is always going to be some wrapping.
> Speaking of technology, start with very common utilities that can be
> reused across applications (like audit/logging/service invocation...)
> so that you will have a framework to begin with. Along with identifying
> services, focus on message specs (input/output XML schemas), security
> etc. Implementing SOA is a pretty big effort, given the
> cross-functional and multi-tiered nature of business applications.
>
> Best of luck and do keep us posted!
>
> -cheers,
> Manish



our business processes and business design are all laid out. in this
project, next phase is software design and implementation. assuming we
can integrate web applications and SOA services fine, re-use of part of
all of any particular service should be no problem. that motivation is
actually driving some of the software design. how do we design to
easily re-leverage part or all of an existing service? how do we
design to allow this to happen quickly and simply? it looks like,
apart from vendor's docs and best practices, we're on our own.

 
Reply With Quote
 
 
 
 
Tom Forsmo
Guest
Posts: n/a
 
      11-03-2006


http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
>
> right now, we're in design talks. the design calls for web
> applications to connect to an enterprise service bus. this could
> deliver both web service and jms message calls.
> with the web framework being the client, it shouldn't really matter.
> i'm looking for the nuts and bolts of how these will talk to each
> other. i'm assuming you'd have to call from the business or service
> layer of your web framework, do a lookup, start the transaction, and
> call the service on the ESB.
>
> spring seems to have it's own framework for accessing services. from
> what i read
> it is transactional. i would simply do a lookup on the ESB, start
> spring's transaction, then
> pass my web service query. j2ee also allows exposing an ejb as a web
> service. i'm not sure how easily this could be rolled to work in the
> SOA paradigm. i could also easily just write a stateless session bean
> (ejb) and have it access the ESB. it could start off the transaction,
> do the lookup on the ESB and pass the query. using spring seems the
> most simple.
>
> my last resort is to mimic a "data access object" pattern to create a
> "service object
> access" pattern. like dao, i would have high level objects for the
> general services.
> they would do the lookup against the ESB, began a JTA transaction. i
> would then have finer grained classes represent the queries which will
> be passed to the jms queues or web services.
>
> i wasn't sure if anyone had done any of this before and had best
> practices to share for all of us. i'm sure we'll be going through
> iterations of trial and testing. i'll gladly share the results.
> (except to arne).


I think I better understand what you are looking for now.

To respond to your request, if I understand you correctly. I think the
way to do it is to use an integration tier at the client side. The
integration tier would be responsible for presenting an abstract
interface of the operations the ESB provides which the web app requires.
A tier below the integration tier would be the actual communication
mechanism used, e.g. jms, esb, web services etch.

This would give you a three tiered client (webapp/integration/comm) that
would allow you to create the desired technology mix in the client. E.g.
all tiers could use spring or the webapp could use struts and the other
two tiers could use spring and so on. Features such as transactions is
handled at the communication tier by way of signal from the integration
tier, i.e. implicit in method or by an argument.
Depending on how the communication is designed in the system, you could
possibly use an enterprise message format which travels from the client
integration tier to the service integration tier instead of an explicit
service interface.

This solution, though, is architecture independent, the reason for this
is that I am not a great believer in SOA and ESB. I would love, though,
to hear what you choose to do and how you solve the issues, as there are
not many actually doing SOA in real life.

(Sorry, the following explanation is quite long, but it is not easy to
condense)

In any case, as terms, SOA and ESB, are just "syntactic sugar"/business
terms for the age-old business component model (corba, dcom etc) of the
nineties. Its using the well know concept of service brokering to
present an idea of component/service/utility computing. I don't think
the component model works at a business level, mainly because business
processes are specialised processes for a special case in a business
that management creates to give their business an "competitive edge".

What I mean by this is that any business process/step is usually so
specialised, that it in most cases it can not be made into a general
components (or as termed in SOA: service/utility etc). The principle of
business components is easy to accept, but the reality is not. Any
business process steps requires specialised input/processing/output that
can not easily be generalised and reused in a service chain of other
processes or contexts without adaptation, this making it less generalised.

I will explain in detail how I see it, if I have missed something, I
trust you will share your experience.

For example, lets say you have a telco which has a business process
called "New ADSL customer", which consists of the following simplified
steps

1) gather customer data
2) check existence of customer
2b) create new customer
3) check credit rating
4) check availability
5) order service personel/date
6) set subscription and details
7) activate subscription in exchange

The general description of the steps in this process seems fair enough
and could possibly make you think it can be turned into components. But
the details of each step, what they require as arguments and what they
produce as output are different for each type of "service" used. What 1)
receives is dependent on the product being bought. 2) might need
different arguments depending on the product or system it need to talk
with, which 1 might not have gathered. what information 2b) requires to
register a new customer depends on the product and 2). There might also
be steps in 2b that have to be performed in the middle of 1 to perform
correctly which are only required by 1 in certain products. 3),4) and 5)
could possibly be components, but it depends. 6) depends on 1 and the
product type. Finally 7) depends on the specific information about the
product type, the type of exchange and so on. So there are a lot of
dependencies on the product which would suggest that you actually need
specialised steps for each product type, which it how its done normally.

Regarding an ESB I don't agree on the need. Any communication can be
performed by exposing any enterprise systems through the systems SOAP
interface. A few operations, in a few systems, will probably be reused
by many systems, but mostly there will be an 1-on-1 integration between
a client and a service. By using SOAP, the communication layer is
independent. And by designing the interfaces as an organic interface
(i.e. an xml document where arguments and operations are specified so
that it can be changed without breaking backwards compatibility or
future expansions), one can change implementations/technologies in the
client or service without the system breaking.

But as I said, I am quite curious as to how you see it an how you choose
to solve it. So please let me know.

tom
 
Reply With Quote
 
 
 
 
richardsosborn@gmail.com
Guest
Posts: n/a
 
      11-07-2006
> What I mean by this is that any business process/step is usually so
> specialised, that it in most cases it can not be made into a general
> components (or as termed in SOA: service/utility etc). The principle of
> business components is easy to accept, but the reality is not. Any
> business process steps requires specialised input/processing/output that
> can not easily be generalised and reused in a service chain of other
> processes or contexts without adaptation, this making it less generalised.
>
> I will explain in detail how I see it, if I have missed something, I
> trust you will share your experience.
>
> For example, lets say you have a telco which has a business process
> called "New ADSL customer", which consists of the following simplified
> steps
>
> 1) gather customer data
> 2) check existence of customer
> 2b) create new customer
> 3) check credit rating
> 4) check availability
> 5) order service personel/date
> 6) set subscription and details
> 7) activate subscription in exchange
>
> The general description of the steps in this process seems fair enough
> and could possibly make you think it can be turned into components. But
> the details of each step, what they require as arguments and what they
> produce as output are different for each type of "service" used. What 1)
> receives is dependent on the product being bought. 2) might need
> different arguments depending on the product or system it need to talk
> with, which 1 might not have gathered. what information 2b) requires to
> register a new customer depends on the product and 2). There might also
> be steps in 2b that have to be performed in the middle of 1 to perform
> correctly which are only required by 1 in certain products. 3),4) and 5)
> could possibly be components, but it depends. 6) depends on 1 and the
> product type. Finally 7) depends on the specific information about the
> product type, the type of exchange and so on. So there are a lot of
> dependencies on the product which would suggest that you actually need
> specialised steps for each product type, which it how its done normally.
>
> Regarding an ESB I don't agree on the need. Any communication can be
> performed by exposing any enterprise systems through the systems SOAP
> interface. A few operations, in a few systems, will probably be reused
> by many systems, but mostly there will be an 1-on-1 integration between
> a client and a service. By using SOAP, the communication layer is
> independent. And by designing the interfaces as an organic interface
> (i.e. an xml document where arguments and operations are specified so
> that it can be changed without breaking backwards compatibility or
> future expansions), one can change implementations/technologies in the
> client or service without the system breaking.
>
> But as I said, I am quite curious as to how you see it an how you choose
> to solve it. So please let me know.
>
> tom


thanks for all of the input. like i've said, i'm very familiar with
EAI design and
concepts and usage in SOA. i come from a 90's background in it.
this sounds very similar to the design i'm preparing for presentation
prior to
moving into development.

i could agree ESB might be a little overkill, but from the large
integrations that could
take place enterprise-wide, i see some of their motivation.

we will be choosing and cross-sharing the services "ala carte" once we
have some in
place. we have most business operations abstracted to this level (IE
"enter content",
"evaluate content") and some are mapped by the role of the person using
them.
the thought is hopefully the web application client will "partake" of
some portions
of one service and some of another one. this is the motivation behind
SOA. we'll see if it works in practice. i'll keep the thread updated.

thanks again for the input.

 
Reply With Quote
 
Tom Forsmo
Guest
Posts: n/a
 
      11-07-2006


(E-Mail Removed) wrote:
> we will be choosing and cross-sharing the services "ala carte" once we
> have some in
> place. we have most business operations abstracted to this level (IE
> "enter content",
> "evaluate content")


This is the part I am curious about how you see it be done.
So I would like to explore it further and I hope you can share your
thoughts on how you see this so I can understand better.

- Are "enter content", "evaluate content" and other similar operations
the defined business operations made available by the ESB?
- Is this the level you see operations being made available in the SOA
architecture you are making? (in contrast to the more usual operations
"add customer", "delete customer" etc)

> and some are mapped by the role of the person using
> them.


Are you saying here some of the abstracted operation you have designed
are not machine operations but human operations?

> the thought is hopefully the web application client will "partake" of
> some portions
> of one service and some of another one.


Do I understand you correctly here if I say that to create an externally
available service (i.e. one used by clients of the SOA, say a web page),
the web app would use all of these business operations in t mix to
create the final webapp? For example made up by using BPEL, to design
the webapp?

> i'll keep the thread updated.


please do, I am very interested in how this turns out.

tom
 
Reply With Quote
 
richardsosborn@gmail.com
Guest
Posts: n/a
 
      11-08-2006

Tom Forsmo wrote:
> (E-Mail Removed) wrote:
> > we will be choosing and cross-sharing the services "ala carte" once we
> > have some in
> > place. we have most business operations abstracted to this level (IE
> > "enter content",
> > "evaluate content")

>
> This is the part I am curious about how you see it be done.
> So I would like to explore it further and I hope you can share your
> thoughts on how you see this so I can understand better.
>
> - Are "enter content", "evaluate content" and other similar operations
> the defined business operations made available by the ESB?
> - Is this the level you see operations being made available in the SOA
> architecture you are making? (in contrast to the more usual operations
> "add customer", "delete customer" etc)
>
> > and some are mapped by the role of the person using
> > them.

>
> Are you saying here some of the abstracted operation you have designed
> are not machine operations but human operations?
>
> > the thought is hopefully the web application client will "partake" of
> > some portions
> > of one service and some of another one.

>
> Do I understand you correctly here if I say that to create an externally
> available service (i.e. one used by clients of the SOA, say a web page),
> the web app would use all of these business operations in t mix to
> create the final webapp? For example made up by using BPEL, to design
> the webapp?
>
> > i'll keep the thread updated.

>
> please do, I am very interested in how this turns out.
>
> tom


you're exactly right. some of the operations we've set up are human
operations, i guess in a sense. they're not mapped to classes or
layers but business operations performed internally. the system
architect has abstracted the available services into chunks which
ideally will be re-usable, based on future needs. my concern is making
this as easy to do as possible. let me give an example.

he's designed "evaluate content", "enter content" etc into services.
if my coding layer to them is just as flexible, it should be possible
to re-leverage services and portions of services over and over. this
should be relatively easy. that's my concern.

i was hoping more people had done this, given the timestamp of some of
the earlier SOA messages. but we'll see how it goes. should be in
software design next week.

 
Reply With Quote
 
Tom Forsmo
Guest
Posts: n/a
 
      11-08-2006

(E-Mail Removed) wrote:
> you're exactly right. some of the operations we've set up are human
> operations, i guess in a sense. they're not mapped to classes or
> layers but business operations performed internally. the system
> architect has abstracted the available services into chunks which
> ideally will be re-usable, based on future needs. my concern is making
> this as easy to do as possible. let me give an example.
>
> he's designed "evaluate content", "enter content" etc into services.
> if my coding layer to them is just as flexible, it should be possible
> to re-leverage services and portions of services over and over. this
> should be relatively easy. that's my concern.


If that is the level of detail the design of the services are aimed at,
I have one serious concern. It will require an excessive amount of
network capacity, probably to the level that operations in full
production will be so slow that no one is going to use it in the end.
This is of course, if I the understand the design correctly.

The problem I see is that all these services are made available on the
ESB. The number of services has to be quite large due to the small-size
design of each individual service. When designing an end service, with
f.ex BPEL, you are chaining lots of smaller services into a larger
end-service, which is going to have to communicate through the ESB. In a
more traditional system, most of that communication would happen within
a single server, i.e. in memory. Which is hundred, if not thousand,
times faster. With ESB, you have network latency and network speed which
affects the overall performance. So, add to this a full scale production
load. with smaller and larger operations running. There will be so many
messages going around on the ESB that the ESB will be overloaded. An
end-service might end up taking 10, 20 or 30 minutes to finish.

I worked in a an enterprise project some years ago where they did
something similar, they went for a object oriented design on how to
communicate with the DB. A single abstract "get customer dial plans"
operation took 20 minutes to complete, and that was with only a few
clients. So they changed the design, to have the DB return all data in
one request. Then it only took 10-20 seconds.

tom
 
Reply With Quote
 
richardsosborn@gmail.com
Guest
Posts: n/a
 
      11-09-2006

> If that is the level of detail the design of the services are aimed at,
> I have one serious concern. It will require an excessive amount of
> network capacity, probably to the level that operations in full
> production will be so slow that no one is going to use it in the end.
> This is of course, if I the understand the design correctly.
>
> The problem I see is that all these services are made available on the
> ESB. The number of services has to be quite large due to the small-size
> design of each individual service. When designing an end service, with
> f.ex BPEL, you are chaining lots of smaller services into a larger
> end-service, which is going to have to communicate through the ESB. In a
> more traditional system, most of that communication would happen within
> a single server, i.e. in memory. Which is hundred, if not thousand,
> times faster. With ESB, you have network latency and network speed which
> affects the overall performance. So, add to this a full scale production
> load. with smaller and larger operations running. There will be so many
> messages going around on the ESB that the ESB will be overloaded. An
> end-service might end up taking 10, 20 or 30 minutes to finish.
>
> I worked in a an enterprise project some years ago where they did
> something similar, they went for a object oriented design on how to
> communicate with the DB. A single abstract "get customer dial plans"
> operation took 20 minutes to complete, and that was with only a few
> clients. So they changed the design, to have the DB return all data in
> one request. Then it only took 10-20 seconds.
>
> tom


i think that drove the design of the "value object" design pattern.
i'm getting pretty low level, but another concern is transformation.
it eats CPU power grotesquely. converting all of the objects or
information
from one format to another is the most costly expense on a CPU.

for anyone interested, i found an ebook that directly relates to
integrating
within SOA. it's one of ibm's "redbooks" and it's called "patterns:
service-oriented
architecture and web services". it divides leveraged patterns into
groups depending
on the service it will expose.

 
Reply With Quote
 
richardsosborn@gmail.com
Guest
Posts: n/a
 
      12-14-2006

> i think that drove the design of the "value object" design pattern.
> i'm getting pretty low level, but another concern is transformation.
> it eats CPU power grotesquely. converting all of the objects or
> information
> from one format to another is the most costly expense on a CPU.
>
> for anyone interested, i found an ebook that directly relates to
> integrating
> within SOA. it's one of ibm's "redbooks" and it's called "patterns:
> service-oriented
> architecture and web services". it divides leveraged patterns into
> groups depending
> on the service it will expose.



i'll expand more on this since a few seem interested in it, and there
wasn't much discussion
previously. martin fowler's "patterns of enterprise architecture"
talks about a number of helps integrating enterprise services. one is
a "service layer", which i'm modeling up.

he speaks of using stateless session beans to interface web services or
whatever other remote service you might use. despite the serious
downplay of ejb lately, there are good uses for it. they are rare but
enterprise integration (which i believe they were designed for) is one
of them. it's nice to leverage the transaction support, exposure as
web services or a jms component. with ejb 3.0, the code is easier than
ever to write.

fowler's "data transfer object" and "domain model" are also good pieces
to use in your enterprise integration effort.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Web Services Restful Services imlakhani Java 1 12-16-2009 03:06 PM
Start Web services as Windows Services start Anup ASP .Net 1 05-09-2006 11:44 AM
How .NET web services client handles exceptions from Java web services? John ASP .Net Web Services 4 03-31-2006 10:13 PM
What is the difference between C# windows Services and web services in vs.net? Nick ASP .Net 1 09-12-2005 02:33 PM
how to implement Services Interface Tier (web services) Szymi MCSD 0 11-03-2003 10:50 AM



Advertisments