Hi all,

I’m new to WM and I’m from an SOA background.
First of all I’d like to say that WM looks great and that it seems to have anticipated SCA by many years!

I have a question though regarding WM service architectures for very large systems.

In large systems we are often concerned to prevent the development of “service spaghetti” which can arise when many services call each other almost at random.

Implementing our functionality as services doesn’t mean that we have automatically reduced the dependencies in the system unless the calling patterns between the services have been designed so as to reduce that dependency.

Usually this means two things:

• Layering services with orchestrations (“flows”) at the top, enterprise-level compositions in the middle and low-level technical services at the bottom.
• Preventing direct services calls between different business domains (or “business capabilities”).

So, in order to weigh up the suitablity of WM to the task I have in mind, my question is:

• does WM have a way to prevent certain types of services from calling certain other types of services?

If it does then we can enforce some of the calling rules necessary to create a structured service architecture in WM.

cheers,

Craig

Hi Craig,

The short answer is no. Unless you are talking about simply locking things down with ACLs but I have a feeling that’s not where you are going with this. I think you are on the right track with your thinking. I have certainly seen a fair share of spaghetti webMethods IS implementations.

I agree with you about flow services calling other flow services outside of specific domain, that is the road to spaghetti. Care has to be taken in the design patterns you use and the granularity of your flow services and also the packages that reside in.

As a general rule for me (you will probably get a lot different opinions on this), the less a flow service does the better. The less a package does the better. Interaction with those services, that is interaction that crosses the package boundary should be done via either a messaging construct or a services construct and if designed properly both.

You know from your SOA background that finer grain services are easier to compose into higher level composite services and also orchestrate for business processes. They promote reuse and agility. The more a service does the less of that you are going to get. All of that same thought applies to designing services in webMethods IS land.

Unfortunately for you webMethods IS flow implementation makes it extremely easy for developers to wire up the flows and create a real mess. That’s where your patterns and the establishment of design and code reviews comes in. I think they are an absolute must. This part of your governance process and if done correctly will prevent anonymous service usage.

I guess you could also look at programatic solutions using things like ws-policy(although I don’t think IS supports that) but I personally am not a big fan of that concept. The more complex your service contract becomes the more reuse and agility go down in my opinion.

my two cents

Hi griffima,

Thanks for that quick reply.
Actually neither Oracle nor IBM have a way of enforcing that either so I guess we’ll just have to do it the old-fashioned way of telling people not to do it.

I have another question. A harder one.
It looks like we might have to scale this baby up to 2-3 million xml transactions per hour. Do you know if anyone has ever done that on WM gear?

I’ll throw these out for consideration/discussion:

• SOA has many different defintions. What definition do you use?

• The more reuse that exists, the less agile a system becomes.

• Is reuse the goal or is it segmentation of the solution space to match the business domain? (IMO, the reuse aspect of SOA is overblown.)

• Consider an IS service to be a single operation within a larger service concept (e.g. IS service != the SOA concept of a service). An IS package might encompass a single SOA concept of a service (e.g. flight reservations) with multiple public operations implemented as IS services (e.g. check available flights, make reservation, cancel reservation, make payment, etc.). IS services that are considered to be internal implementation details of the service should never be called from outside the package. Folder naming conventions can help with this.

• Should IS be considered as hosting the service? Or does it host just the implementation of the service interface while the service implementation is elsewhere? The combination of the two comprise the service.

• What’s the driver behind “Preventing direct services calls between different business domains?” What would you use as the intermediary? Why? (Honest questions.)

• How overloaded is the term “service” within the solution space? If everything is called a service, what sort of confusion and miscommunication is introduced? One possibility–only the top level constructs are referred to as services. Everything else is a component. E.g. service interface component, service implementation component, data access component, shared library components, etc. Make it clear that web service != service. And IS service != service.

• One way to help keep the layers clean is to over-communicate the architecture. Drive it home over and over how services (not IS services) are to be constructed. How they are to interact. Which services exist and what their interfaces are. The role of IS, Broker, etc.

• Regarding the role of wM tools, I’ve been starting to lean towards this view–never view the middle pieces as independent components. IS, Broker, etc. are always acting on behalf of something else. For example, if IS host the web services for a particular service then those IS components are considered to be part of the service, not separate/independent from it. Another example, if a service consumer needs help creating a message needed to call a particular service and uses IS to do so, that component is part of the consumer. In other words, components hosted within IS/Broker are always part of a consumer or a provider.

Thoughts?

I’m familiar with some large installations but alas I’ve no idea what their transaction rates were.

One used lots of Brokers on lots of Broker Servers connected via territories. IS usage was minimal at the time.

On the forums here it has been stated/implied that some have 100s of instances of IS. I cannot remember who though. Perhaps they’re still participating and can chime in?

I think you can get there, depending on the components and how you segment things. Load-balanced IS clusters (do you feel you need the clustering that IS provides?). DB servers with HA options. Are you planning to use Broker? Designer/PE? Workflow?

You might consider a services engagement with wM PS or another vendor. For large installations it can be good to have help.

Rob,
You make some really good points. I think the one on reuse can use a little more discussion. It definitely becomes a hot topic when discussing SOA.

From my experience I have seen a fair amount of reuse achieved with services but with some caveats.

-The amount of reuse goes down proportionately with amount of complexity embedded in the service ie business rules.

-Composite services usually have very little reuse potential

-Medium grain services (As opposed to coarse grain and fine grain) have the biggest potential for both value added and reuse.

-Size of organization involved and corresponding governance capability also have a large impact on reuse capability, ie the larger the org the more difficult it becomes although not impossible.

To me a trip back to some of the issues with OO programming come into play. Objects doing a lot more than what they were suppose to be doing caused issues. The more it did the less reusable it became and its agility went down as well. You can paddle the boat and fly the rocket ship in the same class?:eek:

When designing services, choosing the right granularity of the service is extremely important and will ultimately have a large impact on how agile and how reusable it becomes. I think reuse is an important goal of a SOA style architecture but with the understanding of the caevats that come with it.