Spirit of service manages design and implementation of the applications to stay as close to the business service/process as possible. I believe, there are not many services and processes to share between different business domains in the enterprise; even in Account Payable and Account Receivable, there are many services that are not shared. It is better to keep them as services because Accounting evolves too.
BTW, what do you think about REDUNDANT services in SOA? I mean a scenario where one Service appears incapable to fulfill its Contract/SLA to the customer and the latter involves another Service (may be from another Provider) which can perform the same job as the initial one but is successful in it.
Thanks,
- Michael Poulin
Anne Thomas Manes <[EMAIL PROTECTED]> wrote:
A big +1 to Steve's comments.
Keep in mind that not everything needs to be a service. Only reusable functionality should be implemented as a service. Also keep in mind that integration is not the same thing as service-orientation.
Integration focuses on bridging application silos and, in the process, it reinforces the silos. Service-orientation focuses on refactoring duplicate functionality into shared services, which breaks down application silos.
Obviously you can't refactor your entire environment overnight, so you will be forced to do a fair amount of integration while you are on the path to SOA. But it's important to establish some enterprise-level oversight to shepard the SOA initiative. You shouldn't leave it to individual project teams to make enterprise-wide strategic decisions regarding what services the business needs. The SOA oversight group should conduct a number of enterprise architecture activities ( e.g., application rationalization and business capability mapping) to get a better understanding of the business and its requirements, and it should establish priorities for SOA projects.
AnneOn 9/27/06, Steve Jones <jones.steveg@gmail.com > wrote:Stage 1: Work out what the business services should beToo often I've seen companies go at SOA as a technology solution and either really struggle or fail with aplomb.Once you understand what you want your IT estate to look like in 3-5 years time, the business services it will supply, their heirachy and their owners you can then look both at the technical and integration services required to support this and the appropriate mechanisms for communication between the various different service areas.Doing this creates the big picture and vision for your Enterprise SOA and gives a firm base for the technology questions. It also shouldn't take a long time (normally upto 2 months). The most important element is what you expose, not how you expose it.That said there are a couple of CSFs I've observed (beyond the anti-patterns http://www.infoq.com/articles/ )SOA-anti- patterns Clearly split into different domains, don't try and have one ESB that does everything. In domain elements (often transactional) need to be split from across domain (non-transactional) and at least kept them separated from a modelling perspective but maybe even from a technology perspective too.If you are doing Async, have a big think about using BPEL as a co-ordinator as Java is pretty poor at Async.Steve
On 27/09/06, Brian Mikesell <[EMAIL PROTECTED]com > wrote:I'd like to get some opinions on when web services are most
appropriate in an SOA.
A little background....I've been charged with defining an enterprise
SOA for my company. We're currently defining the best ways to
enable legacy mainframe apps for participation in SOA. We have an
integration architecture in place now for legacy enablement that is
a MOM-based solution.
Our environment is primarily made up of...
J2EE consumers and providers
Mainframe (CICS, IMS) and COM providers
So here's my question: As we're maturing up the SOA stack
(currently at composite services), when do we expose services as web
services vs. jms or rmi interfaces?
My thoughts are:
- Use standards-based solutions where possible (eg. SOAP vs.
proprietary message model)
- For synchronous request/response, non-transactional, use SOAP/http
- For synch request/response, transactional, use rmi interface
(through an esb - app server-based)
- For asynch, use SOAP/jms (j2ee is the strategic direction at my
company)
I would appreciate your thoughts.
Brian
How low will we go? Check out Yahoo! Messengers low PC-to-Phone call rates. __._,_.___
SPONSORED LINKS
| Computer software program | Computer software spy | Computer job |
| Database software | Discount computer software |
Your email settings: Individual Email|Traditional
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
Change settings via the Web (Yahoo! ID required)
Change settings via email: Switch delivery to Daily Digest | Switch to Fully Featured
Visit Your Group | Yahoo! Groups Terms of Use | Unsubscribe
__,_._,___
