SOA concepts and Workflow OO Classes: Hybird Service Enablers?

[Mike Pokraka]

Hi Mike,

Not sure I entirely agree. To your points:

1. This one I don't understand. What exactly do you mean by instance
independent modelling in a workflow context?

2. The key word here is 'may'. Sometimes it's worthwhile to do a little
extra modelling in workflow to keep things consistent, and there's nothing
stopping you from creating a wrapper class/method for translating certain
return codes into temporary exceptions.

3. WHY? This is exactly the reason why a shared code base is a GOOD thing.
Making a functional change implies changing the business logic. The whole
point of SOA is that everything sees the same thing and functions in the
same way.

You may consider a class hierarchy of 'generic' workflow functions (i.e.
can fulfil non-workflow purposes) which can reside at the business object
level and one or more levels of wrapper- or subclasses for specialized
workflow functionality.

Cheers,
Mike


On Tue, March 24, 2009 2:23 pm, Mike Gambier wrote:
>
> Some more thoughts on this...and I think in the end I've answered my own
> questions :)
>
>
>
> After some interesting discussion we've decided to keep our
> Workflow-enabled OO Classes separate from our SOA Business Application
> Objects (effectively above them) for 3 main reasons:
>
>
>
> 1. We will want the capacity to use 'instance-independent' modelling in
> Workflow whereas Services will want to deal with proper valid instances
> with legitimate keys and therefore null instances are not allowed.
>
>
>
> 2. We may want to interpret and handle exceptions (Temporary, System and
> Application) in a Workflow framework in a different way than Services do,
> particularly the handling of Temporary Exceptions and the use of
> CX_BO_TEMPORARY with SWWERRE.
>
>
>
> 3. We will need to allow Workflow functional changes to be made without
> risking the availability of the the business logic to the service layer.
> This should build in a certain amount of resilience and keep the code
> streams apart a bit more wherever possible.
>
>
>
> By keeping these two layers separate it also allows us to consider heavier
> instantiation of Workflow-enabled objects with the possibility of building
> in the implicit relationships with Parents/Children/Siblings whilst at the
> same time keeping the Service-based operations as light as possible.
>
>
>
> Services by their nature are supposed to be more short-lived in terms of
> their LUW (akin to a new variety of BAPI call) so a light instance is
> better and the performance gains of buffering much less important. Whereas
> for Workflow the LUW could be extended considerably and the benefits of
> keeping static data held in memory could pay dividends across the system
> as a whole.
>
>
>
> At least that's the current plan...
>
>
>
> Mike GT
>
>
>
>
> From: madgambler at hotmail.com
> To: sap-wug at mit.edu
> Subject: SOA concepts and Workflow OO Classes: Hybird Service Enablers?
> Date: Tue, 24 Mar 2009 09:13:37 +0000
>
>
>
> Fellow WUGgers,
>
> We're considering launching ourselves into the SOA age over here and are
> starting to build the various layers inside SAP to cope with such
> delightfully exotic things as proxies, service classes, GDT mappers and
> application objects to suppor processing XML/SOAP interfaces. Woo :)
>
> All neato stuff but it occurs to me that the innermost layer of our SOA
> framework could be quite powerful if it was also 'Workflow-enabed'. By
> that I mean our SOA Application Objects could support both services and
> Workflows if they became proper encapsulations of Business Logic that are
> open to all calls, both internal and external.
>
> At the same time I'm also trying to convince people that some of the
> richness of the 'old' BOR framework should be kept in our new SOA
> Application Objects. For example, the ability for objects to 'know' about
> each other within a logical relationship (Parent/Child/Sibling). Has
> anyone any tips in this area?
>
> My current leanings are to abstract the relationships so that common
> 'GetRelationships' or 'GetParents' or 'GetSiblings' or 'GetChildren'
> methods could be modelled and possibly implemented on all of our
> Application Objects and become the OO equivalents of instance virtual
> attributes that could always be accessible if not actually implemented for
> every object.
>
> We obviously want to avoid very heavy instantion and buffering of our
> Application Objects so I expect a lot of the attributes they possess are
> likely to be hidden behind accessor Public Methods and hit the databse on
> demand only. But even the concept of a unified 'Key' is quite a challenge
> in OO to support if we want to move away from an 'old' SWO_TYPEID string.
> Has anyone thought up a way of even doing that without having to resort to
> a TYPE ANY?
>
> Being a novice to the 'new' OO representation of Business Objects my only
> other intention at the moment is to consider adding IF_WORKFLOW as a
> common interface on the Superclass for our Business Objects to inherit as
> standard. But perhaps there are other things I need to consider too?
>
> Do we have any 'standard' OO Business Objects to examine and plunder?
>
> Regards,
>
> Mike GT
>
>
>
>
>
> Windows Live just got better. Find out more!
> _________________________________________________________________
> View your Twitter and Flickr updates from one place – Learn more!
> http://clk.atdmt.com/UKM/go/137984870/direct/01/_______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>